From jguichar@cisco.com Sat Feb 1 09:23:44 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA931A05B3 for ; Sat, 1 Feb 2014 09:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLPCKxp8WWqD for ; Sat, 1 Feb 2014 09:23:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 861481A05A6 for ; Sat, 1 Feb 2014 09:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5532; q=dns/txt; s=iport; t=1391275420; x=1392485020; h=from:to:subject:date:message-id:mime-version; bh=LcJrhCQ03NZgJl/7D5ry6FXVzDxNKc31wCoTnqeZ9IQ=; b=RyLqXV3GJrjGG7rXOmBjTstwSKMnn5NbOEY5EZRYs9U4ShwjhVNlzehF 0G5/hCU7g59iJzyaSaG0KRZij5WVaAXBp/a4+xZUbPjNamEAgjgJLhySe /BeC3/S/v7dzVLOvGTBLGZZIww9jcySHVRYhLtheN2d52z5PRqb2ZkcIm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAM8s7VKtJXG+/2dsb2JhbABZgkhEgQ++aRZ0gixuHQEaZhcQBIgYnFywMBeONYUTBJgqkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208,217";a="301199522" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 01 Feb 2014 17:23:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s11HNdok028232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Feb 2014 17:23:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Sat, 1 Feb 2014 11:23:39 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: SFC WG Agenda: London Thread-Index: AQHPH3JY7vfIB63+W06bsptZEKAjcQ== Date: Sat, 1 Feb 2014 17:23:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.183] Content-Type: multipart/alternative; boundary="_000_CF1297C714E2Bjguicharciscocom_" MIME-Version: 1.0 Subject: [sfc] SFC WG Agenda: London 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, 01 Feb 2014 17:23:45 -0000 --_000_CF1297C714E2Bjguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, It's time to start putting together an agenda for the SFC meeting in London= . We've requested one 2.5 hour slot . Because face-to-face time is precious= , we intend to focus on: - WG chartered items for which we have WG-adopted IDs, or IDs that appear h= eaded for WG adoption. - Specific topics where feedback is needed, and mailing list discussions ha= ve not converged. We also do not intend to give agenda time to everyone who has a draft - the= WG sessions do not have time for that, nor is it necessarily an effective = use of time. We also do not intend to give agenda time for drafts for which= little or no mailing list interest has been generated. For the upcoming session, we expect to focus on: 1) Problem satement (hopefully not much time needed -- are there any actual= open issues?). 2) Use cases. 3) Architecture. If you have a draft (or plan to submit one) and would like to present (or m= ore specifically, would like the working group to do something with your dr= aft), please: 1) Let us know now (even if the draft is not published yet), so we can star= t planning; 2) Indicate which WG deliverable the draft relates to; and 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Thanks! Thomas & Jim --_000_CF1297C714E2Bjguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <542BDF8622150147B4CD77A257186247@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

It's time to start putting together an agenda for the SFC meeting = in London. We've requested o= ne 2.5 hour slot . Because face-to-face time is precious, we intend to f= ocus on:

- WG chartered items for which we have WG= -adopted IDs, or IDs that appear headed for WG adoption.

- Specific topics where feedback is neede= d, and mailing list discussions have not converged.

We also do not intend to give agenda time= to everyone who has a draft - the WG sessions do not have time for that, n= or is it necessarily an effective use of time. We also do not intend to giv= e agenda time for drafts for which little or no mailing list interest has been generated.

For the upcoming session, we expect to fo= cus on:

1) Problem satement (hopefully not much t= ime needed -- are there any actual open issues?).

2) Use cases.

3) Architecture.

If you have a draft (or plan to submit on= e) and would like to present (or more specifically, would like the working = group to do something with your draft), please:

1) Let us know now (even if the draft is = not published yet), so we can start planning;

2) Indicate which WG deliverable the draf= t relates to; and

3) Indicate what you want the WG to do wi= th your draft. E.g., do you want this to become "THE" WG document= for a particular deliverable? Or, is there content in the document you bel= ieve should be added to another document? etc. Please do not just respond "I want it to become a WG document". = It would be better to explain in what context, and how your draft relates t= o other drafts that have been submitted.

Thanks!

Thomas & Jim
--_000_CF1297C714E2Bjguicharciscocom_-- From ramk@Brocade.com Sat Feb 1 14:00:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5591A3BDF for ; Sat, 1 Feb 2014 14:00:06 -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 ey6HSO75x6sJ for ; Sat, 1 Feb 2014 14:00:05 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1671AC3DA for ; Sat, 1 Feb 2014 14:00:05 -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 s11LSOwq000471; Sat, 1 Feb 2014 13:59:00 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1hqvp81eqk-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 01 Feb 2014 13:59:00 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 1 Feb 2014 13:58:13 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Sat, 1 Feb 2014 13:58:12 -0800 From: ramki Krishnan To: "sfc@ietf.org" Date: Sat, 1 Feb 2014 13:58:11 -0800 Thread-Topic: SFC use cases around long-lived flows Thread-Index: Ac8fmHi9L0MfdJFMSn+zYLGVyxiqng== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C00142E11BHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-01_02:2014-01-31,2014-02-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402010154 Cc: "draft-krishnan-sfc-long-lived-flow-use-cases@tools.ietf.org" Subject: [sfc] SFC use cases around long-lived flows 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, 01 Feb 2014 22:00:07 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C00142E11BHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, This document captures distinct use cases around long-lived flows. We are l= ooking forward to your comments. https://datatracker.ietf.org/doc/draft-krishnan-sfc-long-lived-flow-use-cas= es/ Thanks, Ramki on behalf of the co-authors --_000_C7634EB63EFD984A978DFB46EA5174F2C00142E11BHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,=

 <= /p>

This document captures distinct use cases ar= ound long-lived flows. We are looking forward to your comments.<= /span>

 

https://datatracker.ietf.o= rg/doc/draft-krishnan-sfc-long-lived-flow-use-cases/<= /span>

 

Thanks,

Ramki on behalf of the co-authors

= --_000_C7634EB63EFD984A978DFB46EA5174F2C00142E11BHQ1EXCH01corp_-- From diego@tid.es Mon Feb 3 01:35:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0D1A019B; Mon, 3 Feb 2014 01:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 4-l-ws8Vl__a; Mon, 3 Feb 2014 01:35:02 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAE11A0195; Mon, 3 Feb 2014 01:34:48 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0E005UQYLQHG@tid.hi.inet>; Mon, 03 Feb 2014 10:34:38 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 5B.83.05896.DA26FE25; Mon, 03 Feb 2014 10:34:37 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N0E005UKYLOHG@tid.hi.inet>; Mon, 03 Feb 2014 10:34:36 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Mon, 03 Feb 2014 10:34:35 +0100 Date: Mon, 03 Feb 2014 09:34:34 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "sdn@irtf.org" , "sfc@ietf.org" , "alto@ietf.org ALTO" , "nvo3@ietf.org" , "i2rs@ietf.org" , "vnfpool@ietf.org" , "actn@ietf.org" , "aeon@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_HfLKwcgNbqq2wZiLKCL3SA)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: IEEE ComMag Guest Editor Guidelines Thread-index: Ac8egGwW/UaQXH0JRXGruhkG36AXpA== X-AuditID: 0a5f4e69-b7f778e000001708-52-52ef62adea3a X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsXCFe9nqLsu6X2QwScHiy09F9gsDtyqtni4 fS+rxboZH1gsns6XtHjyYCu7xYxL/1kc2D2WLPnJFMAYxWWTkpqTWZZapG+XwJXxbOIU1oJt a6QqJu+YwNrA2HFZsouRk0NCwETi0c5H7BC2mMSFe+vZuhi5OIQEtjFK3F/eAOU8ZZT4M/0V I4Qzk1Fi6bJlLCAtLAKqEl1bJrGC2GxA9qPm32CjhAUMJVr39EKNVZD4c+4xC0iziMB0JokV Te/AmnkFLCWWrFzJDGELSvyYfA8sziwQKnHk8l4oW1yiufUmmM0oICvxbv58sGUiQAtaLj+G svUkzn2YzgaxTETi4cXTULaoxMvH/8BqhAS8JVoWb2GdwCgyC8m6WUjWzUKyDsKOlfh5aRYT hK0ncWPqFDYIW1ti2cLXzBC2rsSMf4eg6s0kVsycx4SpJl7iSPdWqBofic4dfUBxLiD7BqNE +9LDTDDNt6cshFqgKDGl+yH7Aka+VYxixUlFmekZJbmJmTnpBkZ6GZl6mXmpJZsYIekicwfj 8p0qhxgFOBiVeHg/nn0XJMSaWFZcmXuIUQVo0KMNqy8wSrHk5eelKonwHkh4HyTEm5JYWZVa lB9fVJqTWnyIkYmDU6qBMaTiYNKEvNybKrvb+x7c0Fc+5nbteOdiq2mmce+6LhxsUXr77zbr tjKFOOGz9jy/4gx6p71jWz3F77SJWd8dBpl7ItJX5EsZFTazLjy1xrQmsn5aj2bPJ4nZvpn5 Ca/qqlsdkrfJryrxnHSiqL/nqVVe5VIzI1Fue6aC2JMujdqzZxizXHZRYinOSDTUYi4qTgQA FtIaBAEDAAA= References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C29D15A@SBS2008.eict.local> Subject: [sfc] Fwd: IEEE ComMag Guest Editor Guidelines X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:35:05 -0000 --Boundary_(ID_HfLKwcgNbqq2wZiLKCL3SA) Content-type: multipart/alternative; boundary="Boundary_(ID_wzWpo4LwzlhD2arHSmCpDg)" --Boundary_(ID_wzWpo4LwzlhD2arHSmCpDg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, With all due apologies for possible multiple copies of this reaching you... You have the CFP as well at http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfpcommag0215.htm= l > > -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_wzWpo4LwzlhD2arHSmCpDg) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi,

With all due apologies for possible multiple copies of this reaching you...=

You have the CFP as well at
http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfp= commag0215.html

>
>


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_wzWpo4LwzlhD2arHSmCpDg)-- --Boundary_(ID_HfLKwcgNbqq2wZiLKCL3SA) Content-id: Content-type: application/pdf; name="IEEE ComMag CFP--Network and Service Virtualization.pdf" Content-transfer-encoding: base64 Content-disposition: attachment; filename="IEEE ComMag CFP--Network and Service Virtualization.pdf"; size=312856; creation-date="Mon, 03 Feb 2014 09:34:34 GMT"; modification-date="Mon, 03 Feb 2014 09:34:34 GMT" Content-description: IEEE ComMag CFP--Network and Service Virtualization.pdf JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu ZyhkZS1ERSkgL1N0cnVjdFRyZWVSb290IDIzIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDIvS2lkc1sgMyAwIFIgMTgg MCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291 cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA3IDAgUi9GMyA5IDAgUi9GNCAxNCAwIFI+Pi9YT2Jq ZWN0PDwvSW1hZ2UxNiAxNiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgNCAwIFIvR3Jv dXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1 Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDQ0MDQ+Pg0Kc3RyZWFtDQp4nKVc3W/jNhJ/D5D/gY/2IdGKEvVVFAV6u81hD/3Y66Z7D917 UGQ5Eeo4PklOmv71NzMkJVLOyE6uRbdOPENS8/mb4WjFu0/i22/f/fT+4wcRvvux3N6KRb29/O3z 8rvvxN8/vBd/vz4/e3clhZRBqMT1+vxMihD+lSKJkqBQIgtz/N/1/flZKG7xj3+cn/2+EMv/iOt/ np/9APzih5/eC+HsJLmd7NpRkgcyE2meBnFOa/++eP/9Ml78uLw0f4irX5YyXPwqlvni0/JSLb7/ 9AN8/PWzs7G7ZBxnQRj7S84eMuLFEYkonIpDJnEQRiJNokBFZv2f6/7poYVj/yHK7TJdrMTyMlp8 hk91+9hUtfjStD38tC83DZz9r3KZLPrmYcs8glJREGX+FrOPEL9Oo1GRBWki0igKspNEpI7pMQuD PFIigYVVala8vqtJDM0Wn7ZFJT4sL5PFCuS0h/8qkMDyMl1sl1ItBHzMFmuxLBYdUa2XMlr0T2gB JX5sa0ZYsiiCOPO3vmRooxCeOPZp8Tj1Gg6pFvVKbOsejvAESqJTtH/Q6W/hS/F1gYf5vJTx4gPo 8mf4/deloAMiM66D7E/wneFdSrkQ6z2u4D/sI35scKW235fACGYRL/6CVUqiU0AX2x1xo6sv8J3Z 7W6JInn5ARNZBEnuP2DH0UZxUPikgiG16s2jQBrSctPXLQiM00qYBInHQIIUJUhXPOET3qEkSFCb uis3KAywl2xxj1+CRGVCQqhbMqIejSlfPJXPIF5u00ilQV54u6I2aROWByLQhOcRT0DaqZ84rqwI sszjuuBIgUZJj5Q9S66CIvbFPJjWboMCo5/FmmypvRBbOmWPZuHYLNlds10DW1t2fbsHnqqH79Ht 2prbXqk8SHwt1yA+EodW1J7iFi5PP5ORNlvR3xntzVtPmgapDWdrsvK2v6vQuR9gXdL76G2ruipX dcDaFywWRf6a1xxtJpHIo0Unqsmd1toPu57srEODqXedoIBA4SB3RYtGqO0DPBf9FTwXLPXAdbnk pOIgLvyjlBDaUGHlpq3LFSr5mfIet0SRBmHmL9GXGF3/4PQaFkEx2dQImmGAyKBin4E1GkQHiU+7 w4hWQtrrbSxECwbXZZbIMjAQdwlxGQYSPlbgVuzGYKZF7nGFxAGR6Q51QhujxaM93c0oxdpnIgNp Df9+MPoWDZS1bYie0ZRX56++RnvS8Z4zTJBznvrM/V1JgXL7ALLrefNXQXrA2aIlm8eGbfVzc5kw DOLYX4ANS5A188SnLcUOU1Zd1XBMElaNMRzNeLeD87cPlBgrbv84lJS1T9k/DmMK0S4t2K9Mh0wS LxrYCQR9V7YrONBTSXCDgwwxYMN88vAcZIgLMMXJ5jdozR2hBUIpiBgIv5jQW+Ozb8ir7xEDbvuO gkvZnhQn4yTIErNVW0PcV2y+L+IgUxOWCg5284x5ttOgykFS+gCsUSWIbL3FOLHINEd47dEascDO lLAQIeCm7VYHRxQHhc6aQyRREpJRuItCBgC+67umE1qeiA6exYAgarI6jDiC0qBO9lr9K8xXEIZs FNoRniiRodf6QtGICnWDKahDPaUGqfQWa42opFnNRLAkP01yKg+xjvJojaDwNLSRuMHcwnq/NRQo TqBMGGEsPWTdCZ2FLLzqNUYlhGU2EigehFTr/QbNS2yaNVlG9YxQYUOPrMOY6Maz6cRXmYAIv61a lGVd9oTzyeV1wCu3K5ShMQW0YXO6ZytLcIqApM9l7RhkqjL/IcesraNyuRE7jR/wOWtYG5Nv38Dv OelD9Ya5xl3VYJE5MHVEEaEKsuIAsaHkYN1HEo6VWnYAH5RFDz6uQmARWW1qk+TcRkJFmvinwLy3 M7mvLVEZsxkfUfB0CXa7NAySzKdFW6oHs+ubltD6AL41erzBkE0f/0Q5QKbrKYKGGJ0yF2Ex3tpB fEcd6SiCEU5bHtoZnKBpj+hJ5VAqSsdhmg5zFe2GJQhXymSBzH1mDuxLhFqTjdgcLiOsvDzasiNz AxSKYa6nKOb44hiT6OFbFLBoCWh0tc551Z0YLXBF0tXi2gzmhYI1eQm/1ulqvX4Y/ArDIIdfoURI JmfetAi3ALs+s2xQ2EAS9djIHkkJFRX4OjQFLMyMMBqwgj1oWSQntixUGiM4ti0LSDNriGd7m6nh SIMV7+iwrDoBIUAO8NZ7ajZsJJJpcUCPO7QI/MYSdDWEvBISVT4GiKqhVGvUv651KN5W9EtTILKA Kg9U4m/Nqk6GCP482qpsW4xbNbuBCrHM8ZhYgAUlUTbZYIxa+tG3xuTdODFT7EBk95Y7UuxEQSZP EwYWO1Hs05Lx4gH5mD8flNCl/NbD0dxAsLfpdVFTkGgoqaL9zLWHZJ4Esb9jBxZvOlN8hYQZRmY+ Y0kQhXzDFO9wTIw8VL6bSIUAjTQIsaaZR78x7FFM9iC9TxPy2CMwKIPw28apfYwubAcEv8EuSIVu rVj4q7IEayrnAFiGhlEkqaxkWxEG0Ll8uhClVmHd+qhp3hbiGHvX+uGv9kutlbF3OJ90XOZjScel fc/SAsafrEvW1WwtSraNUS4kpliiOwtoiWZKy+eK3TmLJk9kRPp1eUHm1ARLjQD4BhFU5oBSvMND BMXIxYatKFZYaHo8bCs5zoMo8WmdsIVBeIdFcLSoKIt3GsitbburFRWBGg1Yt9QTt4gdLbiD5L1p RrRDyV03hh7g6zVnjDILCnmaLSgAwSr2aTu9kbFZqNTgOW6o1vUj0BE7hlOk2ZwT27Y4ob9mXLfs 9A0AfNVQ2IvGTdmyMdRqczdlu7EhXX14tHzUCynqubRUhoYWj+0QcyHerfZUpbeiGWq4nS15Wtsj IFyG5egA6Ac8B8vq/N3t6goTXSA+4YI7yrIdwTROizHgjsnTE7QuV2iJbU3cLKKzGgsjRGgmv9/R nQQWbfX2dpn4VYhzaCrgDP7UlWAL+BM/lW1dzmUTJf0tR8zK+htd3XhM3a5cmn5rb4GBBmkdXSTt qzt758AjWnACFJ+3ru8ECMC1SEgAs2giLiShGXc5vpOrCKq4tGyHIQzRST3auqPM1zY7bBVOIIKt wGe1jo2wzCbbHUebAk6d0Or2no5390N7ZE4wEswUsqu3Chu7IQ5DxeXRPjW6Z4HQFoLDvjMByTzu 6nkLB8HMUFHQ7Llmc6QSvGNx1j6l2RwBuA8Lj0snJPIDdBG20Qqijgr/WdicksUYnDzaafFWNb3O BDy0j2N/CS4WIrQHxHWSShCdqcljcPE4hlCUT85gYRDqpuIxoMqCeCKAhqUtgnxyep0lsGFQbmd2 yTMsIj1Ozu/iIsLrDf9ZTDsr0fmYSmkIMZTJ2as1iX7rq4V8lKGHCiM+TTMqTbCj5dFWLMSFYOeT mohBWWxrbuYdEHIkfmQS9WWFPx8/XNpDPMBiULBRn5czOymTQE62OcnqpFJ4heRxcoqRCbhzOtll 01C9ZzEaV3tBmJmIgT1RHlGwdGlLpyWBSa5sEXZABN6UWNVQ/aPxIU4g1BuAl0rbJtdTiYo0iORp J4qKHNOvR/txa3q8Jes9kFwzOZUsRMzeNotjcINbvEl6pIaU6O8IOjfbCgAE4QuAnpv6EUHIZmgN rkVJKKnR6u3R5fWzN9tjJpsk2M+wif6RAFa5EV2P3ogYjpqlf8EfB2X3DbZm6PwAiA6ungasilfJ 6aKs+mZEEX2jcZi5mdiU+npwZSp43eAUP1/Btl8IYR4FRHFeYEfMeZ4TiysVJgj7XcbQZD9ATPjE dxqJk6n9cE2jTB/hNBfiI36rf3MFP13jj79x4yUhTRN48uYSXyIlerlLes3mYqtIRZdFU/h4Td2G DVrRT8NsTnlrykV79UCquNJ9/z12L+mLCwD02BC2iHtAuroTCxUZXizAp6cGgEiHmHPYWNsNDzPx aivhDj32dZtW1DRikHojFwPOYYuAnFKau/xhiYGgXN/R8kMgVrqRwgEXc9AKPQ2DChvcQro69Lj4 0aCMDMOl7QZHo0moqhk7wmwkhqidTZbhIp1EXJHzxzvoHqcndo8jHD6ztfM1ObFTgJhY1WhkUIBd QRDIzYUcqafa7I0N6MB+g4kYM6+5tAM9bccLLvodNgWUAdwU+CBA9jYwfjMzWaQS/7izAsj4icL4 hYnCPNfiyKiyo/W/DcMs/84/zrsr9QJzgVMQPvOB8bw8yCjDFLGPx4njcofwwpRDKP4pKMCuzN7U kaYf4Yd9qrJeaHx9QxkHS16aAdLmSk3G4YLUbw4397ZCtcMBOhrpOy7bBeE8nCo/VkgHGszfpsEk Q0N5owYd5ldq0OX8gGJ5tvigHDoqM3cvKsdpMG8VFibqqVqP9kScmMuDsz6wtFmQ+aQt4QTMQl3f lhgPRhB0pFyPUoWdqJN2xoIzTHzancb3ZH4vQJvZzgir1AOLK95mcUoOOev1Fucwv9LiXM5fdoAB +2a4QiC72wAEov4bXrvpyRAT0LfkvQdjPzbG6CugFwcmzP0OqWNfYs/QqAPjjjUHRh2pDNKYf+LD 4fuZOf85fUTJ/xHDHeZX6sPl/GAv+Elev+xYXwZhJPObunAhnGyjERKTE+gudsi9j2b+R6Y0kZy/ 3NVmO9Tgk+nMQQ91x745Ma+7cMzvr9ddyICD47pzOakqXJu544TyIR9RM9Kfy+6Mz7ygF11+TRqf zq1E4Q5M6+sX3aTEBe7tqCItt6XpGA6tZzhjOyuRkbagMOnSsjdicUrtJI94Q6+M4DER+OlSpbsQ +lWXj93F3ACSiqlh5q23tk9rfMiNUZyBqgLbLCc9rwJzUROdrwc/YUdwjKnIgm55TZtKtyjgnDe2 uQ5gdtea7hpeP+HNwgC4LjQYnkV3zmCfFuXQMBmdedq3PmoOoLU89s/+dckSpwjUPOJ5X595AWnG 1yVOTadv9HWX+XW+7nH+qIuUW+qA8n3/2OdiZ0pjGmr2aLsKBxeHecPh7s29NvUaltZCMj83zyVl Cil63M7cteKUorDtgmGAHZ1pwza9kxQHhFnBHqp95qWtObUDDLAvbb1e7Q7zK9Xucn7BwZTpm0v6 5Sl3QGcYhfbVNr7sUbH5UiXYmZw97kibYWfSox2TAA3S6ghCyLvD3O2qlUaI56/0VIGDHexhDjXL vi43r1lFjfw3atZhfqVmXc6P9xhxj1Wo2LTFdsafNrTW7XjvPVyF+FPBY42zwvsT+36GngemWUSB rxL8CdxmRZxlY70N85Wcf+qRNsbemEe7Bmxgor9YNR31UdrmBl/RXMZD48n0Zs04v7FiY7zH8lwc 4uyMyXMb6jQeDCbZV7Oo6bCfecMxwbaVtySLiIsC045HO2+s7KDkvLFKNbxe+3pjdZhfaawu5+e+ tDOktvu61jF/buYy8xdpLFylW2MzJCYTflQrimO8QPYWOZj5dvIMjeCaNz5fKPzsO2Nc7KFePSuw Q3WynctZdRZ5EIfqjep0mV+nTo/zc13RfF7TU+9H416CeuQl5lZlTtLDdD1EjzX1kU/prEVZgkiW fYpDGb+tOZpH9KrY22TsMr9Oxh7n9zhT2D8s42Fi0291ji8Mee+/HCDo8R1uSKdOiOcuniMcjsz8 s9iOKtfyynCoy+O4wHvBzXKMpM4oKNvEkuhA3jL7pTPUjcnHvYzjbvDxDjOfLFR3/dDJ1/WJbVno 2V2KTIOHO+/FUDQYjJSu+zyy+dwCBQaahHN/vx42HmaHxdjT1veQ4xidPYUzo4vNSJpITNzhNYio 400tdy8c4Rikd6R558mNv/z3/AzvK+mfFAJqWsAa+FcIgDdGIlNBlIu2Pj/799/E9vwM39tJaU+o xSKlRBZh4Yt/KQVopYJ93328L29rmYoPD+JfZuP/AYFLW7sNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1 IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FC Q0RFRStDYWxpYnJpL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA2IDAg Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMjQzL1dpZHRocyAxMjUgMCBSPj4NCmVuZG9iag0KNiAw IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FsaWJyaS9GbGFn cyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAv QXZnV2lkdGggNTIxL01heFdpZHRoIDE3NDMvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3Rl bVYgNTIvRm9udEJCb3hbIC01MDMgLTI1MCAxMjQwIDc1MF0gL0ZvbnRGaWxlMiAxMjYgMCBSPj4N CmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMi9C YXNlRm9udC9BQkNERUUrQ2FsaWJyaSxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250 RGVzY3JpcHRvciA4IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dpZHRocyAxMjcgMCBS Pj4NCmVuZG9iag0KOCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNE RUUrQ2FsaWJyaSxCb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50 IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MzYvTWF4V2lkdGggMTc1OS9Gb250V2VpZ2h0 IDcwMC9YSGVpZ2h0IDI1MC9TdGVtViA1My9Gb250QkJveFsgLTUxOSAtMjUwIDEyNDAgNzUwXSAv Rm9udEZpbGUyIDEyOCAwIFI+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlw ZS9UeXBlMC9CYXNlRm9udC9TeW1ib2wvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9u dHMgMTAgMCBSL1RvVW5pY29kZSAxMjkgMCBSPj4NCmVuZG9iag0KMTAgMCBvYmoNClsgMTEgMCBS XSANCmVuZG9iag0KMTEgMCBvYmoNCjw8L0Jhc2VGb250L1N5bWJvbC9TdWJ0eXBlL0NJREZvbnRU eXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZv IDEyIDAgUi9Gb250RGVzY3JpcHRvciAxMyAwIFIvVyAxMzEgMCBSPj4NCmVuZG9iag0KMTIgMCBv YmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+ Pg0KZW5kb2JqDQoxMyAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9TeW1i b2wvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgMTAwNS9EZXNjZW50IC0yMTYvQ2FwSGVp Z2h0IDY5My9BdmdXaWR0aCA2MDAvTWF4V2lkdGggMTExMy9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0 IDI1MC9TdGVtViA2MC9Gb250QkJveFsgMCAtMjE2IDExMTMgNjkzXSAvRm9udEZpbGUyIDEzMCAw IFI+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFt ZS9GNC9CYXNlRm9udC9BcmlhbC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0 b3IgMTUgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHMgMTMyIDAgUj4+DQplbmRv YmoNCjE1IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FyaWFsL0ZsYWdz IDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDkwNS9EZXNjZW50IC0yMTAvQ2FwSGVpZ2h0IDcyOC9B dmdXaWR0aCA0NDEvTWF4V2lkdGggMjY2NS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFk aW5nIDMzL1N0ZW1WIDQ0L0ZvbnRCQm94WyAtNjY1IC0yMTAgMjAwMCA3MjhdID4+DQplbmRvYmoN CjE2IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA5NDUvSGVpZ2h0 IDEzMC9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUg ZmFsc2UvU01hc2sgMTcgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA5OTY+Pg0Kc3Ry ZWFtDQp4nO3d+XYTV74v8HsheQHLeQF07gNgnxewnBfAf51z71r3XpQzT91298m53SedjtQ5SToj IhBmY4EhjMGGMBsQ82wEwQzGxgLPsuTSPHjA91fa5a2tUknaGhCy+f7Wd3nJ5SpJtqpKH23v2vvy /373MuX/vHuF5/+quUpZm841q5AP1Fxn+RstNyh/K+Tv1Nxk+Xstt/5ByD++e5vnn1jeuUP558X8 yzt3ef5VSy/Lv2m59yshv37HzdKazn1K22J+o+YBy2/T+eXfhXz4zkOW/9DSR/l/GXn0u8X8Xs1j lv/U8uSjzPzhnacsH2vpp/xRyCdqnrHYtAzYWVaq+dPKQTGfqnlO+a90hj5bzOdaPCxfaHnxZyFf rnzJ85WWYcrXQr5ZOcLybTqjlO8Ws27lGI9DzThlfUYmvl/MBjWTLBu1eH/IzKaVUzyb1fgoWzKz daV/6wo127RMU7YvZscKRUy7mgBlZzrBjsU4tYRYdmkJU3YvpnNFRMweNVHKXqOkfhQxTKdBwjy7 c2dX+onp49QnKKYjZ8S/hj7tWpTs7DDONMv23Em9Rn7DbNWFXlz1JVazJW82a3uIQTbp4+X5IV/4 bmmQDRmZEPN9zox/rz8cMuJIZ0yXdcYZZfkud1JH6IhhvjHIMMvXefNV+hShz5f6vOD5c77wk5JB Ps/IkJjPcub5ZxknQ30+TWdQlz8ZZ4DFLuadjNjS52p9PtGnX8wfc4a/QRjkDxl5ostHxuFvScb5 fTqPsvM7g/T9Tv9WqM9/aHlomA/1+YXl3/Pmt2oe5MpvMnKfpy1fRCEY5Nfp3BPzq5zp/VXaJPr8 a0bu6vIvxrnD8s858k/p3Nbybjr/aJBbPP+QI3+v5aZh/k6fG2L+1jgch8b5IJ1r2bEa5Ko1A6Us p//Xu/+j7r//t8rVZZAYJAaJQWKQGCQGiUFikBgkXlIkrriKQWKQGCQGiUFikBgkBolBYpB4yZG4 sioGiUFikBgkBolBYpAYJAaJQeKlSOIKqhgkBolBYpAYJAaJQWKQGCQGiZcoiVUV/88KqBgkBolB YpAYJAaJQWKQGCQGiZcuiUmt5asYJAaJQWKQGCQGiUFikBgkBomXNInLVzFIDBKDxCAxSAwSg8Qg MUgMEi91ElNOlaFikBgkBolBYpAYJAaJQWKQGCReBiS+UoaKQWKQGCQGiUFikBgkBolBYpB4eZC4 ZBWDxCAxSAwSg8QgMUgMEoPEIPGyIXFpKgaJQWKQGCQGiUFikBgkBolB4uVE4hJUDBKDxCAxSAwS g8QgMUgMEoPEy4zExaoYJAaJQWKQGCQGiUFikBgkBomXH4mLUjFIDBKDxCAxSAwSg8QgMUgMEi9L Eqsq/mspFYPEIDFIDBKDxCAxSAwSg8Qg8XIlMeFWRsUgMUgMEoPEIDFIDBKDxCAxSLyMSSyjYpAY JAaJQWKQGCQGiUFikBgkXt4kLqhikBgkBolBYpAYJAaJQWKQGCRe9iTOr2KQGCQGiUFikBgkBolB YpAYJH4bSJxHxSAxSAwSg8QgMUgMEoPEIDFI/JaQmHLSSMUgMUgMEoPEIDFIDBKDxCAxSPz2kPiy kYpBYpAYJAaJQWKQGCQGiUFikPitIrGq4r/KUPGbIvHdtveefPf+kPOD0Z/tE+fXh/pdYhYyK9zv Cj/LiNflGD9ppzz7vpkCEoPEIDFIDBKDxCAxSAwSg8TyJCYAiyquJokffvqXLw60Tbu752LKQqUr 6fcQlSdO2Qc2NIPEIDFIDBKDxCAxSAwSg8QgcX4SiyquAondv/+LkWP2hM9TcQbnKiK3/5ZzaEcL SAwSg8QgMUgMEoPEIDFIDBLnIjFX8Wsl8Z1fvzd1zVk1CWdX0u95+aO1WBKP7LfOTGcAPjro8mxt 9l9xzMUVvpDWiT53sbAl83GFzkXjh618CavYkItlRtHu1nuybXhnc/Bexh8nMe6OeVyUxISbLYk8 6QKJQWKQGCQGiUFikBgkBolfH4mZil8fiQd3fjAXVRZqoCIDrsefmottJY6PaS71nrXzo378WBtb SOgVW4kHvjITd2khPyPNL+J5uL1ZbCX2XbCrC3c2szNh+HE3W83vsoutxKPOZlo4fdEGEoPEIDFI DBKDxCAxSAwSv1YSp1NpEnvfaONwds3FlP5vGosicWRQa+l98kk9P+q9PXa2cHh3i67jxOTxtumr Dn5GYqslxt3ZHSdIywOf17MzYWxIe5TBL+p1HSciT7rH97eAxCAxSAwSg8QgMUgMEoPES5HE3qu1 5WFWTMXyJGZbxcfc4lGv3NF+tWdfmnUkfrG9eeqcnZ2OBr82s9UCvc5sEhOD+ZmQdaWYVTzZfYmn L9pGnRaQGCQGiUFikBgkBolBYpB4yZF45Kj9jYhXppLTnr6P6mVIPLCukW3iv+IQj3rWm2IuroiX 1w1936i7vG5kTwvbfPJEGyfxs8/qn39rFi+vG/i8nq0WedwtkvjllkZcXgcSg8QgMUgMEoPEIDFI vERJ/MD+l2/EuvI1edouQ+KRA1a2/ugBq3jUs4VqR+JFEj+114f7unUk9p3XPhe8ZB2J/6D1Ih5u bxZJPLyzma2mdiReJPGIs3n6oh0kBolBYpAYJAaJQWKQGCReoiQOPr1YfeUWVXMxRW0oLkRi3kFi 0NHID3nPVk2wUz12RmLycKive/qqQ0diPuIEH4RtdG/LfFx59lm9SGL/BU3OIx3NjMQvtzQmxt1q F2KQGCQGiUFikBgkBolBYpB4CZL40VfvV0qtoX7X5AXH2Ak7i3K/OzbirsidUw3vsxYkcXxU6yAh jkvMh5vgw6+xb8cOWXUk5sNNRIWx1+irblxiPtyEOvzakIu+sm89680gMUgMEoPEIDFIDBKDxCDx UiRxRa6qe3moTXvdxZ0ktf88/qKxIjAO/tJdkMRszcigSyQxbzr2bGumDHe2hPpU0+r6EovX1r1s bx5ub/aeaCMkE4B1JGZUJgmPdDRTJrusdFsdjwJTdYDEIDFIDBKDxCAxSAwSL00Slz8K8cuDbenX PYvElPsf1if95c6CNxdT8pN4aLPWQUIdkVggMZu/g74+EmavoyW62evGD2v9kOkG7zjhO2/3XbCL JB76TpNz8J6Tz1434myOeVwgMUgMEoPEIDFIDBKDxCDxUiTxA1u5F9aRVNVXOS+JaafydFrLfCCq J/9lzkNikjBb7cWuFk7iJ59oo0OE+rpFEkefu3Qknr7mYGsObWwUSazO2SGQeOxHbVQK76k2kcR+ lx0kBolBYpAYJAaJQWKQGCReiiT27Gsrk6mhfpcMie9/WF/mA1ENbmrOQ+LQQ62L7+NP6jmJ9dfW CYOw6Uicvrbuo3c4icVxiY2vrcsalxgkBolBYpAYJAaJQWKQGCReWiQeLns44onzDhkSU8rvUTzW 3ZaHxLyDxEN2jGfOW+fZ1pxN4qENjWOHrYzEbDVtcucsEivXHbp56/r5+VMg8WS3dXhLA0gMEr/l JPbvNAWPWTJy1BLIjHKwASQGiUFikBgkBolrhMTBJ+UOvzZ63C5J4vAzV5mPNXnGnovETz/XuviG +rpFErMr6ajSZwmBxIkxN6mYTjX0la3mO2/PJvHo3pbw4252DmSjUqgz2WWR2OMwzyoetBIvPxLP PLAV3DmT920gMQ8ZuOBfbGbUBRKDxCAxSAwSg8RvIYnHT5bbIp2HxLwjse+Kg5P4ySf1c4vjqj21 1YskHvjKTB6eUTzsVDN1Ttt8+ppDR2LvCbVvycRPVnGSjsS4W0fiEWczaTnkdoLEIDFIDBKDxCAx SAwSg8Qg8esjcfBhdzaJH31cP7LfOhdT2Dpk4JED1v4vzIOORj782kKqR8RUj53iv+pg8zsvpMZb 6/9T/UhnCx+RmG6QitWBJs7bw4+6+fKhb83kYT4E8UJqxAm/y04hBs8q2ngak91WkBgkBolBYpAY JAaJQWKQGCR+fSSODLgMSfx8c/MQyxYtjz+pJxJ7tjansy0jL1IZ+MpMJH6xvZnycoeQ1LjEYvo/ VpuI0+lQw8YlHnFqGXU2P/+yHiQGiZcNiWN3C//irMjAIDFIDBKDxCAxSAwSv0ESi1N18ANZHJeY xbAvsW72unRyjzihJXWqxIgTIDEvkBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQ GCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJlx+Jo0dWxc82xcSc0YfWAYkx VQdIDBKDxCAxSAwSg8R01n3+Zf34/pbpi7bATUfM44ovJvK0a/qSzXvU+nKD2ZDEo+0N/p7WwGVb /IWLJXjb4TtuHV5nqiyJJzaZfIcsWg5b/Kn49jYUJLF/f4PSZeFZuiSOHapL9DTxxHuaMHtdxUm8 PCZ0pkMjcNYavmmjhC610reTm00VIfH4DybfQQtlYrsZJAaJQWKQGCQGiYsteRIPOBpHD1i9PXbl jjM66FLzXEuor3vqnH3skHXo+8aCJB5ub5Z5Yn6Xnc6rU6fb+DjGeYq4O9ZpYSR+8a1JuWybDXjy /da/OEc3m7NJPOFsSLx06TOsT6TXwd6CQ9dtc8F8D5QccdH7/uRWEyfx5DZTsMc6M2I87WDieVfo vNWQxIFDDWILYehYk5qfhRzXoiNx8MCq8ImmCOWkkFNNUZ7TasI/1jESs29jpzPbbM82xXl6mqIH 6xiJk9fXzk8bzypOy5N3WqNdq143iSPHVsevrE26bclH6+YmXCyzL7sSbhslen5N5OhqkJiT2L/b HDzZEr1ti913zIy6dIncslHoA1pBEtOePH3EouWnnGEk9naYY4+cuX7TWa87fMM2sdlUFIm9nQ10 ACaHXfMJxfhoGnaFex2+7haQGCQGiUFikBgkLlgFSTy0pZkMPCfhUlYk2ECv88X25vJJHHLnfA81 rPB953inRYbQ6vNMKL4TVh2JJ/cV7q5JRe/C5OEZrzEFs+tVQiEGE4lDl1tf5Xj7FmvW51b/A55J 4pkx2cm7dSSO35MyGDGYkVhmZVJx/MTqV5EhmZVnnqwjQutInLi2lvM1V2idPCSOX11L7n2VVGSe A60286yDeFwmienDhS6hI6sLkjh4ZPXsmItlPiz1R1tI7Qb0orOU35fY32kmBs+F8n2C0xV9QAue s+YiMUlY5k6IxIGzVslHJBjLkFg5Y83/UVRXdLATnsc2mkBikBgkBolBYpA4V+Uh8cC6xsigLMOy K/rc9XJHc8kkjnlKf2j5Us61lkZieQ+nt8rRMmxYRLjweWvNkjhxfa2kRVkRnmMnVlfq8jrCsDws dUUbRk81yZOY0JvoWzc7XuCPT38N4m7i4brw2TXZJA4dbyrt2fIqh8S+dlPiSXGfLsVSP9AxGJdE 4kCPrIdZ0ZGlNRcbedh3yFIUhsVSPwV3t4DEIDFIDBKDxCCxYeUi8cj+4t7IcpXvvL00Elet/Kyt uBgSV60CRy21SWLJ9uGMTZJK9MiqMkkc3lc3N1GBz0rJvnX5SRzsrEvcs5UGb/pN4702ZVddLZBY OdhQ1IeXnPc84vJuM5VAYpl/i+gfi6k4y8PKmQqclKIPnSAxSAwSg8QgMUicXYYkrpSHWQV6nbVM 4vmEMrLeVJskJsz42k01SOLSijRbDonJw7n6LZdQyWcduUgcOdFUcis0L7qH4JHVb5bElfIwq9kp t6hiSRKXVpF7jtfhYVY6FYPEIDFIDBKDxCDxghGJX3S0lHmf2TV+2FqzJKYKXrXVJompondsy4bE VPGzTSWTOL+HiaCRY6vZiBPhw6tmBjoKP5mbrdkejl1eW8Tvk7eIo0zFb4TE9GGqgh5mlXjeVR0S U01sSjcUT+1pqOydBy60gsQgMUgMEoPEy4nEnk5r+JkrXwa0RHJk6pJDJPGjj+tnpgt31Qv1dYuD sNG3+defjyuD35hLIPGs4ol5XImJ4toGZwOe+AtXclJ2q9mgp2ZJrDYULyMSzw52lEZiup1/5bkJ lzgIG/06Be9fJeueutfkYf4Qyq66N0Jimf7DcyHP1A4TH4EtfKW14CbBHmt1SKycsXISJ4crfGXB fEIZ32YGiUFikBgkBomXDYn5/paxZ/I9Wdi977cKx0LqYNEOH+GwouNurLtN5hl6e+wiiafOFW6s DvQ6iyWx32XnU3VMnS78Zq1tdbaVT9Xh75HdamyruSgS01uqctrq7WyYaDfH+mSvXSKBkCh8TrN/ X0PieZfkVsGjltok8fyka+YXG0W+NZL3nSiOxPvqCj5ECSSmStyzcQ+HDq6qeLMqVbzXFti3Kn7X Rondtc1Kv46Jp87YHRtLsSSe7jTLPAStLw5KrHQVfgjah4sl8auEEr3n8B+2hG/KDkC3wEafWLyk Tmb9aJ9z/AfT6HcrJ7abZa5+5d0nQGKQGCQGiUFikDibxPFRqZbVEkg8H1eKIvGs4tHNXkdLCm4V f+HSzV6Xf4BiXoThokjsO2gRZ6+TvAp+ymkWp+qQHBErcrW1Bkk8O9jBp+pI9Mi2gpZG4sTtwh9t SiPxfHiIkzj5rHBfC3FDyTWJ2dWf0Dn2wCHzECWQmCpwvKUoEhOG+VQd8irmJJb5yEkHoDh7nb9b qvfX2AYTSAwSg8QgMUgMEmeT+OlnUi1LCyWRWP299rbIk1i54dCRWGaYYuWyTUfi8AOpJtyiSJzx /pt61470FhZIcsSlm70uckuKB6yRsNZIHOtaJc7jLDkGRWkklrmqrjQSU4UOrlKn89tTJ7PynN8d PtHE/rChI6vpW5mt1JHZqkviWZ/UEyuNxFG3Q57Es1Nucfa6yS0mma0WBBLLfN5ks+eIEzrLPMT0 KStIDBKDxCAxSAwSZ5NY/sK60kjsO28vdvY6kcTTFwtbIpvEgctSAimKxMlhl47EMv/bzSZx8JzU RfS1SWJxQmfK/KTU0yuBxJF9clgtlcTRc2skexGrfY/3rxL/tqRimYeI99qqTGLJhyiNxKRceRLT bi+SmCL53DiJZVYOXbfpSJxrSjux4s+6QGKQGCQGiUFikDibxJNnZMevKI3EsSEXSCySWFIgbzmJ Y2ekcFsyiVl34pkXhbt2J/s7sqdypoUFN5zxdFWTxIGjsl0aSiMxVdVILDnWRDaJExJX5M0FPSAx SAwSg8QgMUicTWLfZan+hwsgMUhcRRLHXWsk77kcEhecn44q0rMmm8S0sOCGs2OuZUZi7zZTdUgs eW1ddscJGRJTgcQgMUgMEoPEIHE2ieWnbwaJQeKqkbjg8Gv8nsshscyavBdxsX0nqkzi4CnZHlAl k1g5YqmpVmJ1ULXUcBOcxJJXvILEIDFIDBKDxCBx9UlMBRKDxEuXxEq73sO1SeLoHdmHqH0SS/Yl XmDTQO8wF3V5HdXkrgaQGCQGiUFikBgkBol5gcQgccEyJHHsRuEB4kDickgcH5AdwXshNTrxxHaz PImnDlhAYpAYJAaJQWKQGCTmBRIvMxKHfqyLnmrKlchJLWwENgpfouaElnBmskkcOrJaZnYPkLgc Ekt2JxaLYDx9ykrcLZjRDSaQGCQGiUFikBgkBol5gcTLjMRaOnJGnMdZn3YtSnaEPywhWXK2O5C4 HBKXPKGzOp/ddvPItyvT+cYgIDFIDBKDxCAxSAwS8wKJQWJJEgd210UvrZWcpIMVSFwmiSfbzTLj DBtW6LptbKMJJAaJQWKQGCQGiUFimYcDiUHi/CQOHlgVu9E64ymiXysvkLhMElOmj8kOo5Fdc0HP 1AELSAwSg8QgMUgMEoPEBQskBokNSUwSTvStmw8PyTyHXAUSl09iinJGarbHnHfY6wCJQWKQGCQG iUFikDh/gcQgsY7EkRNNMvN34PK6/FVBErO24pJ7UCykBmob22ACiUFikBgkBolBYpA4V4HEIDFP 6MCq/BieDw8l+zuil9YGdtfJsBkkrhSJKd49DSRbyTvJrmwVg8QgMUgMEoPEIDFIzAskBolZoufW 5Gn4JQzr5rADifNXxUlMR9z4JlOkV3b2+ezSqRgkBolBYpAYJAaJQWJeIDFIzDyc/1EIwLqhiUHi /PU6SKzmu5XezobSBmejSgy7QGKQGCQGiUFikBgkzi6QeJmROHx4VfRUU1EkDh1cVbBjMEjMqhZI zKKcts4FPZL3KVbomg0kBolBYpAYJAaJQWJdgcTLjMTyEzpTMRJL4RYkTlXtkLhkGM8nFNZ9AiQG iUFikBgkBolBYl4g8VtO4nD3apk1QWJWVSPxxCYTHVwGOZiR0mDMGopBYpAYJAaJQeJlQOL+9VK8 LFggMUj8lpM4+axDZk2QmFXVSCxzZFFltBifkoXxfEIBiUFikBgkBolBYrFAYpD4bSZx5GST5GQc IDGrWibx6LdqJFU8dcACEoPEIDFIDBKDxLxAYpD4bSZx7PJayTVBYla1T+KE3GAUwWs2kBgkBolB YpAYJOZVHRInxt0gMUhcgyROyP2JFkDixVo2JI4+dILEIDFIDBKDxCAxL3ZYBR92S65fGoljQy6Q GCSuQRLPvOiSXHNJkDhwVFa2JZOYduDqkHiy3SyzcskkptVAYpAYJAaJQWKQmBc7rCbPyPZ/KI3E wV4nSAwSF0vi2Bkp3JZDYhnW8jV1JJ7zF55ceJmR+FVCqRqJKTIrZ5NYctJnkBgkBolBYpC4lkn8 bEvLGyHxyH6r5Pqlkdh7og0kBomLJXH0Z6nh0d4UiaW2qi6Jfe0myYcojcQzI65qkljmQjlvZ4OO xJKPAhKDxCAxSAwS1zKJn3zX/EZI/PQzqf9RLpRKYs/GRpC4CiRWdtctJxJTJO+59L7Efesk19SR ONJTYAJobavqkpgy65NqIy2NxOHLrdUkcXygcLcWPjQxI/HYRtkPBbi8DiQGiUFikBgkFosdVnTc SXYn9l9xiCT2X3UU3IRdWwcSV4HE4bNriv3P/kJtk3j2ZWEU6Ul8Xgqr6oZ+t/yIE7Ry+EQTj+Tf tjQS05olkzh8Xuo/PrNT7hJI7HOaq0ni4MXWgitHeh0iif3dLZKPMn3KChKDxCAxSAwSg8S8OImf b5a6w7m4Eh10RZ9rkdlk/CcrSFwdEpPTAosNxbEbhTnBqpZJHL8g5duZgY6E28YiOc7wQmoEtsjJ IpqUSyiRxOEzslZ/lVRCp1tIwqy5uCgS+9pN8yGpgXlJxbQVy5zEJvHHTrYDV43EMlfYzQU9Ioll GpZZjW4wgcQgMUgMEoPEIDEvTmKK73LhJt9iKzHmfrJ4HgOJSyNx4qlTZmVes+MuMpX8+rVM4vCu FbSh5BMrquivFNi5gvI67jz9KAKJp511JdxDsSSe2rQyeEq2pbS4Z5JqIq4miSlJieEjAq5Wdkj6 DsheXRi+68DsdSAxSAwSg8QgsVgiiSnxUal/B0vWfFwZ2tgIEpdJ4vAF2YsfS6saJ3Hk2OqihC9T dIfBPXWMxJITOpdWIokpSY9sGyavEkhMkew+IV/BHuvk4g5cTRJLjk4cH+iK9sl+cpzxusc2mEBi kBgkBolBYpBYLB2JH31cr9wprk0yV2ke/ugdkLhMElMk/xWuK4KfTC+CGicxPbH4Vdkev1LPxO8O d69mHqaU1neC7iTeW/gX0ZE48JPUGBpilUbiyqo46nZwD1eZxJRIbyX/e0UentzVQB4GiUFikBgk BolBYrF0JFbzoTom21xMKeduE2NuzcMgcSVIHDjUILO+rqKX1soMMlb7JA6l2orlOwnnu+e+dbx9 mEd+3AlWrM926Ehh3+pITIlcLI73JZOYohxsoOVFPZyuXiWUwIkW0cPVJ3EFVRy+62DtwyAxSAwS g8QgMUgsFrnXkMR0qD7+Y/340baZ6aIbJwnDY4etGacmkLhsEjMVy7cVk4RDXauVdqkZ1pYEiSnh fXW0vOROFDPPOsKHVgU7Vug8XGz3iWR/B7+GseDK2SRmKpb/LcohMUvwVEtiqOgOG4ThyC2bd7uJ dtc3TmJ2oMn0KzasGa87dM02vs3MMQwSg8QgMUgMEoPEYkUGXLlIrCZ1FA84GsePtYX6uuNjObsZ E4PDfd2Tx9uGNjTSqUZ/alo8jz37rJ5UrGWnkA41IyzOZo/DrCOxZ715dJdljGf3YjrTGd5o1pF4 5AfzxB7LxF4tkz8aZ2S9id7dxraag1dtwWv6hFiua1FOW3Uknmw30zt4Rm6mE0kl2GPVkdi3y0ze oERv584dW/Boxvi0ar9i19rkUFcuUM2Hhwhs4RNN2jhsy4vEPLELa2YGOuYlhkGbG3cl+9ZFz68J 7a0jDLMYkpgSPbcmf0M0G4dNHOYuemltvNeWJ6TfbBJTlH2rEk87ZGBcPom9qUy1m0LnrbH7DlqT uGt4J7Scfkq7pdoyvHFlOjVAYgodcRPtZv/RFjoSI70OEnJ2EqmEex20TuBC69QBy9hG08i3K3UY BolBYpAYJAaJXyuJh4/KToucq2qQxA/ZMZ554Hu2NVOe2urZ2UM7sSyeanKRmJ/f+j/OPBmmTpXa +XPxvCqSeEB3xk6dzNUzvHDaT79BLL6DaG8ri+81Ge9K4hvZ4hscvfdlvBXyt85v01Gnx8oksRaH mnHHSp0BJr5fTCaJWcSBYdWIkmEDam1eqSOxb+tK/9YVFDJV6OcmLcfVKLvqdLPXEYkpgfYM+HEZ BhcH8mWD+qYbY3et0DhKSSE2nT1qdCROJ/WjiGGEO4keWRU/2xQTc0YfWicPibWknnb4xzoivZjw 4VXq79WRM7lIrKZ9RbhrdeKeLfmsgz5NsCT61sVutIaOrNbNXscyzbI9d4xIrGXritCxpui11thd mz53tNCL7t9pYgOypXPUEsiMcrAhP4nV/KDP9IEGpcvi322m2xkG1iWTxBNivs+Z8e/1h0NGHOmM 6WLkYUZiNd/lTuoIHTEMSAwSg8QgMUhcRRJ79rWVadTR4/ZqknjqkqM0EqfPEiDxGyIxZ5UqLq6v pUBinjDP7twpRGIxQTGlkphFyY6Rh8sncWboxVVfYjVb8maztocYpBgSiwGJQWKQGCQGiUHiSpH4 0Vfvl2lU33VnNUk81t0GEoPEIDFIDBKDxCAxSAwSg8QVJPGNv3m3TKPOxZR7v6mXIbGnswIjLA1u agaJQWKQGCQGiUFikBgkBolB4sqSuPwr7BR3twyJ/TcrMHowP6xAYpAYJAaJQWKQGCQGiUFikLhS JB5s/6B8qSr3u+/9tj4PiR//ubH8Rwk+7AaJQWKQGCQGiUFikBgkBolB4oqT+Pa/vTcXVcr36lxM mTzvGNja8uiLRraH0I3+9c2eTqv/RmVmlxveZwWJQWKQGCQGiUFikBgkBolB4oqTmP4II2UPxVaF InL3fVQPEoPEIPFyJbGv3TTdaZYk8dQOk9JlUQdk29/Adk5+Iw+JffsaQGKQGCQGiUFikDgXiW// 6r2Er+hJ36pck6ft4mEFEoPEIHGNkDh6rZVP4RE8pp+rhU/bMetzB45a8pA49sCReOIsSGL/bnP8 ifNVQoned6hzx9x3zE65E8+7KPlJPOU001b0NQ+JY4/Uf2nRHSZHXCxzQe3cqBxrEUk8tbchci89 a3Ok1zGxyaSb03k+NcNIxnQ53630H22Z8aqTtiSHXb4DFpHEgQut/OHoRmJxIg/6lu4KJAaJQWKQ GCR+3SSmPPq63NHYXmvFR93q4QMSg8Qgce2RmF7i2F1tgr/ItVbdDkASZj+a3mPO00o83WleSLG5 4FQdxFoi69QOU3q33G6aC3nij535SRx7rHJXOd6Sh8QEUf9hCz8cvB1mNnEeUdmwlZjhlvRr2EpM yxdSuNU1DvsOWrSFWa3Eoes2tsnYBhNvHCYqE4xBYpAYJAaJQeIqkJgyuLMC19m9jpqLKf3fNILE IDFIXLMkjv/imBlTGzPZ7HU89G1yqGuBWTdvx4mZUW2W7TwkZh5WW3p3mHR9icOXWyO3bHlIzOd0 jty05SKx/ydL4KxVPBzI3gupRuNcHSfYffoOWfKQmIqgqyOxtiSLxOHUJtE+p9hfgngcvusAiUFi kBgkBomrQ+LaVHHawyAxSAwS1yqJSbxhlzrwOMGYv/TTe83kYVIxLVd7ROQmcfBUS+yBg7UnB7ot uUjMgBo6Z82+vM6/vyF/X+LkiCt0uZU2pxuSfYmjqX4RJHBvh9mQxFN7G9hpStdlgic57FLOqH+W +YQy/oOJH4nkYf/RFkMSs2bnwIVW7uHxbWb+FSQGiUFikBgkrg6J6Q/16Ov3KzIARUUq6feQh+/z wwckBolB4lolMeszTDf4S08eDhxqYK3H4QvWXCT2tZvUrdpNrD05crXVkMQk4YUUUFkTcVEjToRS bci+fQ3sHmRIHDirTS2k/NyS6/K64EXV2ITYXJfX0Y9G16U7V/AjkaisCTmLxOxBJ3c38C4Tvu4W XF4HEoPEIDFIXH0SU+78+r3xnvVvQMCZNXXR8fA/69nBAhKDxCBxzZKYMBz/xeHvMLEjl19VF3/g oBtsYeBgQy4SR2/biMG0C9GNhVR7siGJ40/UnsCJ513FDsLm3WaanXJPbjPR/qydW3JcYcdJ7Nvb wLoQR+858ow4wa7Fo6+GHvYdsqgMXqd2k2CPO7HDzI5ElcpGI05MHdDWDF23ha7Z2IV1rH0YJAaJ QWKQGCSuPonZX8/9+78YOWav/kgUSb+HMPz4U7N2LIDEIDFIXNskjt21hV1Wrt/pvWZ2VZ1/pylw KNUwm1RyDcI2vcc8H/KwXSjQrbUzG5J4LqSei8JXWvkS3y5z/LFzZtTFEr3vMCQxrRPssU4sdp9Y yH2FHSPx5BYT66FBK+cfhI2NDqGcsRqSOHixlX7EBmFLpnAb7XPSbW9nA7uRTWJ2bR2BmWxMiT/r oofAIGwgMUgMEoPEb5bE/A/7+Nv3J86tjw67X6uEw89c3ouOgY3NtHvfbxWOBZAYJAaJa5vEyaGu 6R/NfHCJ4DFL5ForG3qCvqq2HOrKRWK1s/EDB2GYEj6v9VUwJDH7kdJl0bUSM75mjMAmkNi/T23v nT5iYWEkznWFHSMxa/ulrcjGeUg8udPMnhLdMCRxfKBrot3MSDyxQ1vZd9CinLYGXK2GJKZNFlJN xHxcYlIxSAwSg8QgMUhcIyQWXwLi8YuDbaM/20P9FynJ4tuQk34P6VcFsMsxftL+fHvLk68a1T1Z 2L1BYpAYJF5CJJ4PedhUHXzQCX6RXeKpky0xJHHgqEVt3b1t42HjGyv8CjthZ2M9GbJJzFqPAyda DEk8M+KK3LLxkJwXcl9hRyQOXWplZypxKDZDEk8fa1lIXTeXa6oO1pGYT9XBRp9IDruifU5vZ4Mh idk4xlMHLJzE6m2QGCQGiUFikLj2SHxLfMm0VzP1Kqde9Acfm586min9i3F/WH+X71qL+1vGnsn3 ZJAYJAaJlyCJlR/VYSUYidngEgvChB3zKa+q3xqRmH6qDlYs7EVsKLYwv8JO2NmYZvlwE4zEvl1a 66t3uymbxMEeqzpY8Yb07HVsKLZcV9j5ftRGkAjftIkHhW9vg3enWUdiNk9HfLDLkMST7eb4QJdI 4vEfTEy8GcMUCyQe3679LmMbTbrZ6/gAFCAxSAwSg8Qg8ZIgsRpxJ1nchUBikBgkXq4kjrissbs2 RmLWTSLx1MkHYdN6CxhN6By9Y9NGZhP2InaFXZxfYSfsbEqXZSHr8rpgahiKuZAn+/I67zYT0dfn NIskznOF3eRWE2twTgx2iUcE61qc3UrMxpEI37AZklg5Yw3dsOkmdGZdhZPDLkMST5+yMjDrJnQm D4eu2UBikBgkBolBYpAYJAaJQeLaJPF0h2nO547/4mAkDh6zvEoq7PI63mtC7dVwqMGX1WWC1kwO delIzMZhI5r6O83Z4xKzcdiIzdo4bNu16+AyLqxjO+o2Uzw1V51/X4NIYjYOm2F3YtbNmBSt/Nzi P2xhCV1qpSUakgUSs9GGF9hwE1kknthkIjCz4SZEElNIvBnTdggkZuNLqJ8gulvY5XV0gy2c3NUA EoPEIDFIDBKDxCAxSAwS1yaJY3dtLOxiOsIwn9A5fMEau2PjCR61iB6O3rGxhM9bxSZiMYYTOvt3 m+lHbIiJxPOuyC1bxgwdixH7D/ucZt5rQl1yU8v0Txa+t085zbQknCNav+JFD9O34Rs2MToSs4Wh G7bAxVYdif1HW9IdiQUSq03B120ZuZYO+hKDxCAxSAwSg8QgMUgMEtcsiflUHayVOF9yTV2X2UrM kmv2Ol3kp+oQO07kmqcje/a6/JfXZSTHVB3ZrcT6ZE3Vkc43BgGJQWKQGCQGiUFikBgkBolBYpAY JAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgk BolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQG iUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJ QWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolB YpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJQWKQGCQGiUFikBgkBolBYpAYJAaJ3wYS/3/j0MuB DQplbmRzdHJlYW0NCmVuZG9iag0KMTcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt YWdlL1dpZHRoIDk0NS9IZWlnaHQgMTMwL0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAw IDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCAyODc+Pg0Kc3RyZWFtDQp4nO3TyRGDMBQFQYdE/kkRAt5tQPqg23O5uiOYyywL 8Fvm6VJJpwGN+th0GdAqj02HAR3VsekuoKc4Np0FdPWPTVcBfd1j01FAoXdsugmodI5NJwGl9th0 EVBrjk0HAQf2x6Z7gCO7Y9M5wKHtseka4Njm2HQMcGJ9bLoFOLM6Np0CnPoemy4Bzn2OTYcAA97H pjuAEa9j0xnAkOex6QpgzOPYdAQw6H5sugEYdTs2nQAMm6d0ATBuTgcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/Ikrs1rDkg0KZW5kc3RyZWFtDQplbmRvYmoNCjE4IDAgb2Jq DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMyA5IDAgUi9G NCAxNCAwIFIvRjEgNSAwIFIvRjUgMjAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0lt YWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNTk1LjMyIDg0MS45Ml0gL0NvbnRlbnRzIDE5 IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi cy9TL1N0cnVjdFBhcmVudHMgMT4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDM4OTI+Pg0Kc3RyZWFtDQp4nL1cX3PbNhJ/94y/A6YPPerOhgmS4J9Mp5PU dlznml4aq9eH3D3QNG2xlmUdScVNv/Z9gdtdkBQpEqJEMTedOrYFYBe//b8AzM4+sO++O3t/fn3B zLOfwsUDM+LF6a83k++/Zz9cnLMfpsdHZ29tJgQ3HTa9Pz4SzIT/BPN97lsO81yTW2z6dHxksgf8 cnV89Ok70/T87//Npu+Ojy5hBbWK07FKYHPfra/yyWCTzYmiY6IwXaDfmPgxDucbc6vRlstFk8yp dmjAZWNknkyEMJ4mp44Rs8mpbYSLiWMALWEbX/DnPImySWCwcHE3kQa7C3OcEGoIWLbNLbETL5bt cuk1hkbxIk+TiAE94kjx8gBf4vJX8WIiLCNnE894npxK4559BraSNF8R2wl8/RPH37EEJ9+nYZan KxgS5as01rDiSIc7llZQ7PL9OWM1bRLDtMlxuFDL769D67l76lBt4vkMMUrDKI/TBFEKlfQJyMXE NhD4AtVoleX0kwTcXSNOQTksI/4DVWI5EYBwmsSLKJ4Is8VQJeEAuJJa3luwWsNgtXxuWkNxrU3e E9j6zH2QTfBnpZeoyiv4Kcp1CDqC216TFk5IYxIH2ccdLr+I84lvvMD/RCV9ZPBtKS0bhYW0SGDd lGzX43agx6MlLFsvLAl+hgduAzXPVMIyTe66yqVyGz7k0nThq+cIlj50/PIjulzjBvaJBn47OQV9 e0oy3Bh9SZ5hewt2RR/gkGRyGgAm6DIAiDmgjV5jgsM1GIM8HVnnrGfnjn7nXfpS7Nz1ZGEFtVhi vEmBU3Cx8zgj75vN0LZIhijnOfnc2xilma9yJdskhDnkoFmC5kf6tQjzTsV4we2j9IFMjhTiBWqg gGVDRRHNnDz9PGYRuVWpXO2S1pvFuFaW3MKv5zEqNctL58vAoyK1O1wvTrPKKyMreZbcxaj3+SzW eYgSGxlwt9S6bBlHCQQgYPgL7h4W9Ix7VF9GG5ihPiOlMCXgOCHxBmWPW8GPFU5ZFUeQnQxiBnxL C9Hn83kF9QsDF4dsXl9eAtKXhOF5ZcDoAKt1EO0kIvu21vadoYTeU/zEcBWiDwCYAZW/ZMT6A8ag BMUZz9UHmeLnmQREY3pAAjdqlQqqZLMM8R/g5RkpKz+jzxFsv7lG4Y9KCfm1mEuARahcabJEbDg7 R0Or9GIeI9YqY3goJnTtrgIpZcu0whtFrBzkZ2WdmF+s8rXocFoG2liqMjJ5q+QOBBVmpTBIzUPU yVf4YR+K4OA8v0AACSqrwD3R9DPY7Rkuj770hayHR2oXhVlklV5EXAnvYSKKSQRZU2dAH8A4zkrg wiW6plTni6TFwek1mNTmT1Jyz2uOzVa3Jd0EzSLLStXQeH1TcjfYjZ5t+jywm2O7Rc91K0iPmxsc b/W0UudpN4VqQtZZ+o/rnCUZWfBnSly+gGaw5AmFsqw0MM1D1B1U4po7Wzyjrsc4oXI1YU5rgXJi ACX9Ay9xiRPPy6B+kIMovHBaqQ4OxzHzL/TRnJy3kinl3hl7QpcYUiI8owxMaRq4w3Deo//S9yDx KfNtoOcSPdg0qQmGiZN1HUC2tfa6uOkFOlqiRwap8zdegBl1g5pycuhG7tl9UqpOGmcbIYvohbeI AMWbjLMPtL+lCjM0nOJfvHgABPMZy2ak5uuQuajAz2k3yPofkPy4WBk48M8JrizxIxPEbZLneIHf K+3A/AHIvsEo1IuoZ0FNpbZYhCSKPDnulGI3sBs1pJspeyGRAz/36FvAQWKIQFBB4pATKre+Th83 I9ktZeFKewqzd0FDlCSbgksrNFaFbs2aglVqjZCiap9aRPB9oQZCFvEAY0EJ6DmWaiGF0D58pMuD oADoX8Ysz5evwBbII56VhhNxZHEzABUEI8xlFzmFI0oMePRcTqy73abX1XhNyHOF12RK62FhB9Ju jk1iVKX4XxNC6fYLsEYOZA0jQh+Hd/PKwLkOINsNuBc01ydNn8chRRlt3uSYggvRnHkTK3OJlHp8 o5tqO9zf2NTbGK0tpRIa/KVmoufwYEOcWv48jztuc6xV2pnQTQoc7GM0Jknt2ACz9cbYs1b51lWI SIgVgV+fuU8hsluJWGo+VG+ynfP/jEpBtlev14r+yg3JPaW8KInWMeef2NlI81WIFkcOoigzKQUh H/ENqWQI6pmhaTtrn43+oQwhkBJUUZD8fZFm5ZTKP6wj5Bd9GPe5a9d31xPG3UGlohSgDnJvCV0/ LZH9Z4IrnJz6BngO12AX8D1Am0+2V4PC9Uk91sR7NucNalo4gccDeXBrsbbMnu2Lxsy3K0AI6iFQ og+YERRJKkWuG/zstsz9N7JKFZkuysiEyvYKsydtyw+EZtdps1MTGBSQDUafjHerhS6fsCQohWzM NGmOlpS0sXPS2KbO8VhQfpqiOVbneCzXwZjQGHvCLDDdwrd5hqNth1ktMltVyx+mWr6ofOL+ClWb vKdC1WeSRkAZn210wX5G9VFpWXJfJMl2LS/aqjxmgLVKg85NvCzK/vgJFZdSUn1xpcS8bYtrMQsS c32sVn1UStEYS+nlrmrhtEhtVYtgmFq4kgdD28/1yXuqRX3mWwxiKGgoU95XSf9GcunV/MkrDIla ffAItzqBC0zwKV3cRR1s7tnbt7Ye63JLNscKFKyS8xbFMDdm9WZBlt9mS6s6ftBia/vBxbBzMMcJ Kpe1v+7UJu+pO/WZH0ql6KqQMI25oMhFRTGVQNt8ifBdbHM3COyUBFuWSz5k257WY31s5jTGWmXF qRW/I/EArTFJG4sgKKKq6Jhpi3/LwdWWTMyxLO54e2diV6sYzDeDtMuitItdYtsCS+skr1I0bR4G e4M8rEa6Y2//OT4C1XeARdt2uSspwXAs5mMr32FpfHz021/ZAkbXQeg8Ztp5qd6s3zHXlUUt6/97 jflfjo/GoOdy6WvpqUYrhsaQ2hEf1OlpnjxWrQhyvEk2OmMCPKvl6hhjTXptJe08WRpPPjb4JdlK vY0fVdnOiq74NTr2qeqLYBVfO0hG/DYOk0fCzSed1zDYi1vnudSIuMEU0a5mL6/Pp1QoXFUXCdBD /zg+OpZCp5uNXnQ6e8kjouPS/E22fohTilWY9JywKwpMab3VJaTxZXyoHJtDTaXhqReqznp9RKgk 3RFpKRK16MMEG2ebsXskWExkQEf/kVPVu1CN+0dqjRce8jU1npMoRz2n88a7jd73SAwGAQZ0DYO9 cutsRYwoNzvAA6cetn5Zx2YrkFi01+hC8b89NneWvDsvpd+CbQrKlLtD0nmYh5WZQmWCwk6psZat WkI+mBVPYAN2aHTsrP7GQ0gTfNRZAKUTRV/oYwxlVhaHaTSjo5i0ba8HswTlh+UNjYdWZ60zIlKa eJgmUZYVXVmsSwCo8tSY0PoaOEHJKHQMnX4FenSOu1skHoVewGWgo3c+r3pIK7oOMDZ5R0hSw//X dh3h4bGQht4UTTCaYeNEXWOpdo/nekncTucP5sejuyMDEy+rs+Yc0Qy7k5ybnEwwepytL/wgUpR3 nbCbF4TxLl58FacFfn1g7mXpitOx0Nox9yrOhEK80uGqlEddv03WZ8nZ6jVdsKB8Sfk8dZmgfmFm dGV0fe7tmCH90moTYB9P2LUUSFqaTMTqqUK3r9SfS+F9LLu1gbe6lHIwOUk9OA25dmg4lFzALf3u +NjksGXua8m9K11kGOFJaNJWxgPJC+HjKbeGvLZ+GUwOCmBfS+43Or+lNCNfzsD2Gu8FxmHAtXff b9u19fQnDrUoYXF/M59mJjdNaanjxY/fjq5/DgRGDelPxjWjg4yE7j3GUV7dLsJjMKd9BYCOEt5g Pl2cs6o+tnq4gNfsiysCWJ/QFCpC1aW7h4kzvsLhgaXt6bbXK++ejsuB8ragVnbaAVadPK7yLKpd 2KOcaR4/1m83s+tFUfDhrz4XF+iax5U/kfe4xepfyUg9fimuYXekWocCDgZmBrqt9QLe07c5FHCf po/a4RrsiVSDS8NSL1A9jZJDgfIsPKjuzbHu0yT/82vEJOnreBg94AtL4KUwDbnfK2upQjBoB2WT L7F6wlELV6/x/DdWLxEeq7dHeAGbbkuOb2wCj+c0rPfqkK5TNZIOSTrZ3bvXViOr8mp9gtvTSNq+ Un+h0Z0kqIgYPxRuFzxs4VrplVLbGg5lRkq8ozYwY7F7OkiHQtQdVzcOosAQpioPgJpfFCnE/Fk9 vIA0gp7uMLq0+8dy/aSFXHD9eiBnU0g16BTwmqHZ0c1ZdnWOqcX0H3R38NdFQpfiR5aCFAEXQ9MI u6d/cKAQNLF2Wvihe0Tqv2VCkEQhu/4bAnYxuqa6DrYNBoZ+u6dtcChI3XFWNYXxQD9N7vBOPbuh Jy6JtqsyHB1qAQ+M97aulh8JnR3j/R36vcI8X9NLiwQzeK5v2Q1mLKArGbuFtnaXRPj00qeIXa7H dTHE7inpti7UHwMdAKHd5NFepBhKTV2j0FAjadFF6oTdUA6j+q1FaoLf5M8jcyQcgYW+hqNebe+p uw4Uik01YavdSq9E1bXglKGHLF+PlA/4068AUuDr+OkFqadWOhAkQbO7Lv5PpxSvf6b3ky/0tpVC 9eO6UNU29+klG2ZM9Dhqr4p04H4sx8JwpNlPL8g9ddaBIJuwStu7TQnTx/JRMxroCXsX4ivWsB2X DtRBy8dXKBpOeuHpKSEOg0fgbfN2JtGKStkMrNanl1PqYnb5qJE/Vpql/N9rnEMXLPGCD8e2k3o8 i8+xsEz7fTm2+tkOtwLdVnqLoRpVCJ/b4lhPLbR1of78oNuP36BKko6m5DYz7UniUPK2Spq6yatG 2SL8E18NajOQoaRhJGazwyKY01N3HSiO7ojxhg6wLCNKQnppSH9igMqlFB8b3sdZVlpGO5QdyBhM k2JoKHN6CqQD0ep2/ZdzbGij7uKbY/pzEt9SPQkYnVePM7EaWFWvi9X7X6pUyyfOlEzhD7EaQaeN 1Mu+wJxhGabFI+3ib/9oS9OBm5TwK3Tgw+Kb01N1HYh8d1T5lRKtz3SpJM3wRbhV9ADWf2KmvO4b 5mk4umn79PpPw93J6E4ssPFtg4bcB4zqtEkIVSfsKo3xiXfU7hUexoQj6VHgwDjv9JSfh6nJznH+ Dpw9tljRIKlMR9z4A+A1tj9zhM1tLWeasN1AbNif2BEencduI0ik/gcWiQ2JDQplbmRzdHJlYW0N CmVuZG9iag0KMjAgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjUv QmFzZUZvbnQvQUJDREVFK0NhbWJyaWEsQm9sZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9u dERlc2NyaXB0b3IgMjEgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMTcvV2lkdGhzIDEzMyAw IFI+Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9B QkNERUUrQ2FtYnJpYSxCb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDk1MC9EZXNj ZW50IC0yMjIvQ2FwSGVpZ2h0IDc3OC9BdmdXaWR0aCA2MDAvTWF4V2lkdGggMjQ4Mi9Gb250V2Vp Z2h0IDcwMC9YSGVpZ2h0IDI1MC9TdGVtViA2MC9Gb250QkJveFsgLTExMTAgLTIyMiAxMzczIDc3 OF0gL0ZvbnRGaWxlMiAxMzQgMCBSPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8L0F1dGhvcihLb3N0 YXMgUGVudGlrb3VzaXMpL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAE8AZgBmAGkA YwBlACAAVwBvAHIAZAAgADIAMAAwADcpL0NyZWF0aW9uRGF0ZShEOjIwMTQwMTMxMTQzOTIzKzAx JzAwJykgL01vZERhdGUoRDoyMDE0MDEzMTE0MzkyMyswMScwMCcpIC9Qcm9kdWNlcij+/wBNAGkA YwByAG8AcwBvAGYAdACuACAATwBmAGYAaQBjAGUAIABXAG8AcgBkACAAMgAwADAANyk+Pg0KZW5k b2JqDQoyOSAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiAxMDEvRmlyc3QgODEyL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTQ5MT4+DQpzdHJlYW0NCnicnVlNb9s4EL0X6H/gcfck8ZsEigLdJkWL fiBIAuyh6MFNtIlRxypcB2j31+8bcZymXVJj+xBTovhmhjPvkRJjouqV7ZXXymqle6OsUTqjsco4 q6xTJjtlPa7wF5TN9Keci8om5QFwWnmPnl4F7RQwIWrljIomKGBishitEoGiSoC7oLIHLsNfj96E NngKQWtjYBNthG2rtIFjDNUmkxOlLQZ7p7TrnfIRbUB/UNrrqBCD9hH9sBcwJYvnIUUVgE8aYcF+ ClnBFSaIftjJicJVpsckQkCb0d8ro+EsJGUM5gCIMTGriH6L7GB2xiZMzFGGkoqUKeQoAu8RbPTK hB79wAcYjbAfMa8EfMQPTJmE4KJBm71KsJdhBCZtj7gSEtxjHEK3GmVICS06U0ZtkMWMqRlUKKEs VBQqFsWRqVrI01QuZBymrcd8qGABScUjG3vYw7gIYxn2EiWzh8HcI1u9pvL2Ew1cj5RpDHc95qCR b6c1QAktIkfFUONIYyNqbsgMHsEwLogeRCPd4yIR2oMJIAiicYF4Btsu4E4TY+JUeQxJGKc1DCeq JUqK6VgiBS4CDc4gBz0yRFh6ZFB+TY+INwZ3YAwuItkhBhmygzEOjxKGOCRTI1jvUX3U1gd4IUhE tqk/UdVQewrMJGI0CACOGGT72bPujEC9Ou8uurPu8sfXobvYbu6vtqer4a57+1H1n1R3dqMsjXn+ /OmTPSB6FvJqeXO/GboXq+0fb05PT9XL8e7ufn212C7H9Tf1fnGz+He5Hv6sGk6HB2MOh9jDIe5w iD8cEmoQ6KRA3v01Xv+owWIVFnewN9UcZHpcA4L0gr9qlQR/WK1a/ozkLx/jzzb9OcmfrmpCcuib DoPosKooyWFsOhQZo6uqkRw2KeNFyuiq5gSHvskZL3JGVxUrOWySxsukqepdctgkjZdJU18tBIdN 0niZNMesM75Jmoel8F11fZrC4cWI1wiWLguKac7kY0pwoTh9PKma96Cl6fIioNOvuH52usH8dPg7 UqbQUR5926PIIXOUx9j0OF/TknNOBEc3b+a1mdm/DwO5Y0D+GFCogqLdcxv/HWdmixFdM4vR77mR H+ixXbcYJY/5KI+p7THvu5kf5jL1R3K8lJlzzwnhKI/hkq6vCWm3ltTfz+uyFkB1VQmguqoEUF1V AqiuKgFUl1TaSfHypFr7UrtUtpBUSpjKZpOmStIHbaugWc9GVJecAKqrZh5k6rwXQHW6CaAG3eaz nMt+nYtectkTckl9bi8xaafby/Nq7diObtcnzc6lrgIBVFeBAKqrQADVVSCA6ioQQA2ixvmiFnnQ +UxpNbeGW8tte9eik5e5uOpaEFC2LgYJVVeDhKrLQUI1iDefbzrTKgmN3CZuuRC6vVAJSso7S+33 SzrmmptSXRYSqq4LCVUXhoSqK0NC1aVBp3aztdJMfu249dxyDXX7vVrrWbHahijmUa4hCgHVEIWA aohCQNVFIWea2W94GTK8DBlehoxtZlpQBVNjF/j8K93l4vNqqO5SvOmxaHV7txJOJRsfNbud92K4 2tZ3hMmxLemxJTu2zMyW2GwhqS0ctYWi5Vufvw/pvw1TU5IdS2csxsrrNf2jYGp2eedlnyN9FNnl ZhjOx3HbnY+r4f3iqypDu7PFZlhPT+mMm3qmXXCXr4enH4bv27fDD2XY9CvYWo/boftAP6fr6583 lxj6efxekvN6WFwPm3JNmN31m/VquR4ubhcUIXW8WMPCdIbN95vt8p8FLqa7v8fNl8/j+KU7Ga/u 7xDT1PPtdhi2FOS2e7+42oyP7l/e4vfR/clysRpvHnVcrJbXw6OxxQ+G3WwWd3zGznP9cH/37SMy YnjFptP/hzT/r9h7VLkUtJzY8kEqH2/yoSMfBfIBHR+b8WEWHzHxwQ+T65OiSMrhCJ9Y8DHCPItK eOWLkz8D+dPsgVr7vqzv8cJ54OvLvrvvviv/vuvWTx09ffIfn584cg0KZW5kc3RyZWFtDQplbmRv YmoNCjEyNSAwIG9iag0KWyAyMjYgMCA0MDEgMCAwIDAgNjgyIDIyMSAzMDMgMzAzIDAgNDk4IDI1 MCAzMDYgMjUyIDM4NiA1MDcgNTA3IDUwNyAwIDUwNyA1MDcgMCAwIDAgMCAyNjggMCAwIDAgMCAw IDg5NCA1NzkgNTQ0IDUzMyA2MTUgNDg4IDQ1OSA2MzEgNjIzIDI1MiAzMTkgNTIwIDQyMCA4NTUg NjQ2IDY2MiA1MTcgMCA1NDMgNDU5IDQ4NyA2NDIgNTY3IDg5MCAwIDAgMCAwIDAgMCAwIDAgMCA0 NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAyMzkgNDU1IDIzMCA3OTkgNTI1IDUy NyA1MjUgMCAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5NSAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1 MjddIA0KZW5kb2JqDQoxMjYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTMx MDYvTGVuZ3RoMSAxOTU5NjA+Pg0Kc3RyZWFtDQp4nOx7B2BUVdr2OffOZCZTMjPJTMpMkplkyARI IEAooUgGUuglZSAJBBISmopAKCLN2DWKuoq9YS8gTAbQIBZU7N217NpdXdfdBRfrukiS7zn3nRMC ui5++32///5/zuS5z3PeU+457z3n3HdIYJwx5sJFx6YXV0wY98rafjOZ8omOMffKkrHFle+5Bi9k 7NMgY0kHSsZOLvrykXe3M/Ye8kY2rrik9E9PfsOY8qGTMfWLcdOnVSxuHHk2Y0dyGb/RMq4iNFZV +/yDKdcWMFb6zrSKvEH/eO/tzxnjv8Nd6xqW1C97u/nNjYz1wf10gxtWr/SFb9j/OmM1jYzpUxcs W7jku++mWBjrh/ax7oX1K5axVObH/QegvX3hqWcs8N/yh48Zm9vMWMmcRfPrGw98MOgj9D8b5UMX wWC934Ayvhn5XouWrFwTY/Ugr6C/wPOnzG86beLLRZsYexL9mbecurShftrhsXDGHegjfeqS+jXL MoZlxaB9G9r7TqtfMj/lvuXrGHv5Vcaso5ctXbGy08POx3jsonxZ0/xlp+xQOnDrStzOzoRv9W3l oYKEaXNto75lKUYm0t6/rn9R8Avv7Dznh8PtF8ceMDyAbCxTGCW0i2EdjO83bfnh8OEtsQe0nrol XaGw2ALsPKZnhXh2CrOzPDafMcfluK+CUlWXwy9HqVF/nT4fXaYTq6+y8xU8O8WmVxRFpyq6j5jS GWTbOum+jE2p8PkYnq/PTmMw3KwEfIzfIsrUB/VxYqboPe7oaPgrGNGt4rn8sqSrYdt0xaz+J8sO sG3d8+rnx+b/WVLvZ9v0FjbrR/0dOdpe0Z1YX1rdTcygte9NbdTan24b8zbu2/eny/STWcOJ3k+7 V+bRfnRVx/nhfjbup9qonzHbMffMZPed8P1aWKYhnZ30S8bYk3qSSOqbbPYvbaMbzK5T57GaE6xb d8z9fmC1J9JOWc6yfum4/k8mdT8bciL1hK+k5m/hvP8Fif+l882u+91+TD/X/VT9mEZ2Xff7/Wgs BfTMJP+r1L0v5flj+1UzWNmJ9KFsZxknUu9/ImG8m0+0rnoTy9S3/fgZqqezPuotLPNH9j6s+t8d 3/9GUmb82iPoST2pJ/Wk/zeTcgM3nWhd3sn6am16sb2Knl3zPzkONen475CUlBWs5Jf0oyxh5wFr /2dG9ePE97OL1SHsYv2qozZD9v/W3f7/Sfi+Ph7YDjRF8wOA+b/2uP6TknqElf7aY+hJPakn9aSe 1JN6Uk/qST2pJ/WkntSTelJP6kk9qSf1pJ70i5IaRSr9loQPQg5KTWc6nghDJvNpf2XHmBW6DxvE hrARbDqbyZaxtWwLu5/tYl/77J2dWm9W1A6wHDYYdYKsnNWzpmPq8M5vo7d9WE2TQ+hsUJ7io9kl n8yL/qYmHXfqralB6GP2cb9zUdWJ6jXqterV6kb1TN1JakhtUqvUU9UD6kH1C/UGjNbB4lkyZhRg 2SyX5WEso9hoVsxK2CSMu4bNYY1sEVvBVnKF27idu3k6782n8xpeyxfzU/lSvoqv5hv4RfwSfjm/ nu/m+/jj/Gn+DH+RxfAD2ii+/NFvlTi8RH/HqLCfT/zoPKJTis6GsePng7JD6pddU5/ZzQ3/eqas +1x/Yhj/Yvao8eP5/zcTP/ME6331372DltR/q/XxqWcH/MQOCI5rnDundvasmuqqUGVFedn0aVOn TJ40ccL4caUlxUVjxwQLR580auSI4QXDhg7J698vt3cgq5c/05vsdNhtVrMp1miI0etUhbPcEn9p nS8cqAvrAv7x4/uJvL8ehvpuhrqwD6bSY+uEfXVaNd+xNYOoueC4mkGqGeyqye2+UWxUv1xfid8X fqnY72vjNWVV0JuK/dW+8EFNT9G0LqBlrMhkZKCFryR5UbEvzOt8JeHS1YtaSuqK0V+r2VTkL5pv 6pfLWk1mSDNUuLd/WSvvPZprQuldMqJVYUaruG1YzSqpbwxPL6sqKfZkZFRrNlak9RWOKQobtL58 i8WY2cW+1tx9LZe02dm8uhxLo7+xfnZVWK1Hoxa1pKXlgrAjJ9zHXxzus/bTZEx5fjjXX1wSzvGj s0nlXTfgYX2W3e9r+ZZh8P6DB4611EctMVn2b5mQYopdbkK51Axjwwgxv4wMMZaL24JsHjLh5rIq yvvYPE+EBfNyqsNKnSjZJ0tcIVHSLEu6mtf5M8SjKqmL/qxelBxunufrlwvvaz9Z+EG5L6wG6uY1 LBJcP7/FX1xMfqusCgeLIYL10bmWtA7IQ/36OkxisXBDWVU4z78s7PSPpQow+MQzWFxRpTWJNgs7 i8KsriHaKpxXUizG5StpqSumAYq+/GVVe1h+50etg32enfnY49ViHOHEIjyUQElLVeOCsLfO04j1 ucBX5ckIB6vhvmp/1fxq8ZT89nCfj3C7DO2OWivM7bjasrKYuSHL6KtSPGq1eFow+Epx8Y8dhQI7 HpeWFU907ChfFfcwWQ13idYQ6ph+kFGzisaLIlU0LRrvyajOoPQzQ/JEx6TPChu79WWHoWtMdJ9/ OjSqLQbUx1cyv7jbAI/pVB8dYLS3nx6nInwRvTFaGMXjHC+L1CzsXNgUdKOZxFNM9oXZdF+Vf76/ 2o81FJxeJeYmfK0930kV/kllNVXa046ukspjclReQLkwy0CxzChFWIOlOR75WLX8OC3flR1/XPEE WexrMfonVbSIzv3RDpkPOwiTjglMqL+4IH4wtmYpTjd/ab3fZ/eVttS3dTbPa2kNBluWldQtGiH6 8E9obPFXVI3yaGMtr9rgWStuFc8m8UmVY/vl4uwZ2+rnF5a1BvmFFTVVe+yM+S6srIooXCmqG1vd 2gtlVXt8jAU1qyKswigyPpERPZUjY9Tqe/YEGWvWSnWaQcs3tHGm2YzSxllDm0I2u7QpsOnIFtRs IuEhJS+Ci3HclvgaxeNZX72opa5abC6WiEeJHx7m/tEsrPhHt3IlxhI2+eePDZv9Y4W9UNgLyR4j 7AYsDJ7I4RxxJrXU+XFOYUFVMQ+npaiKLn1tnZ2VVRkveQ5WZ2CpzQZqqsKxOTj79VkTUW+cQB3M 48LNDfViHCxUJdoasiY0VGPZyg5RZUI4Fj3ERntAjVKtjViOaNSAZ4MHqLVvRibcXB2uzhE3rVpc rS1ne5iN94/AY6c+9QFxo7zqlnj/IG1vYiuYsi4QFIuxsYoqsniQxc2qyUkGC0be4EdRQ50P3tax hgosdTpLTR6yzMeRqAvM12DyRAuZmJaaZbaawrH90SF+hDb3F1tSn2WorqbBa7kLohVwb3vYjBEF urky2gDeQdEEMRb8XIChiqqPi27K2li5fw1OFjForScDisPWrAn1OPypvRkWf4FsbBRnhDnax36y GsTMLfC7mlXZ1nm3/4yMbqlfrl+8HMTCZJ49WNisuuV4Q3hWTr9c4/FWq2ZuaTFaf7oB+cto7WJh 9JXgrcFYJFb1tSnn7opN5hMhzpHibCnOkqJZijOl2CjFBinWS7FOirVSnCHFGilOl2K1FKukWCnF CimWS7FMiqVSnCbFEilOleIUKU6WYrEUi6RYKMUCKeZL0ShFgxTzpKiXok6KuVLMkaJWitlSzJKi RopqKaqkmCnFDClCUlRKUSFFuRRlUkyXYpoUU6WYIsVkKSZJMVGKCVKMl2KcFKVSlEhRLEWRFGOl GCNFUIpCKUZLcZIUo6QYKcUIKYZLUSDFMCmGSjFEisFS5EsxSIqBUgyQIk+K/lL0kyJXihwp+krR R4reUmRLEZAiS4peUvilyJQiQwqfFF4p0qVIkyJVCo8UbilSpEiWIkmKRClcUjilSJAiXgqHFHYp bFLESWGVwiKFWQqTFLFSGKUwSBEjhV4KnRSqFIoUXAoWFbxTig4p2qU4IsUPUhyW4h9SfC/F36X4 TopvpfhGiq+l+EqKL6U4JMXfpPhCioNSHJDir1L8RYo/S/G5FH+S4jMp/ijFp1J8IsUfpPhYio+k +FCKD6R4X4r3pHhXinek+L0Uv5PibSnekuJNKd6Q4rdSvC7Fa1K8KsUrUrwsxUtSvCjFC1I8L8Vz UjwrxTNSPC3FU1Lsl+JJKZ6Q4nEp9knxmBSPSvGIFA9LsVeKh6TYI0WbFA9K8YAUu6XYJcVOKSJS tEoRlmKHFNuluF+KbVJsleI+Ke6V4h4p7pbiLinulOIOKW6X4jYpbpViixS3SHGzFDdJcaMUN0hx vRTXSXGtFNdIcbUUV0mxWYorpbhCit9IcbkUl0lxqRSbpLhEioulaJHiIikulOICKc6X4jwpZNjD ZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDZdjDm6SQ8Q+X 8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X 8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+X8Q+XYQ+XYQ+XYQ+X0Q6X0Q6X0Q6X0Q6X 0Q6X0Q6X0Q6X0Q6X0Q4v2ikEouZI+mgvYuZIugt0NuXOiqSPADVT7kyijZF0C2gD5dYTrSNaS3RG JG0MaE0krQh0OtFqolVUtpJyK4iayLg8kjYWtIxoKdFpVGUJ0alEp0RSS0AnEy0mWkS0kGhBJLUY NJ9yjUQNRPOI6onqiOYSzaF2tZSbTTSLqIaomqiKaCbRDKIQUSVRBVE5URnRdKJpRFOJphBNJppE NDHimQCaQDQ+4pkIGkdUGvFMApVEPJNBxURFRGOpbAy1CxIVUrvRRCcRjaKaI4lGUPPhRAVEw4iG Eg2hzgYT5VMvg4gGEg2gzvKI+lO7fkS5RDlEfYn6EPUmyqauA0RZ1GcvIj9RJnWdQeSjdl6idKI0 olQiD5E74p4KSiFKjringZKIEsnoInKSMYEonshBZXYiGxnjiKxEFiozE5mIYqnMSGQgiomkTAfp IyllIB2RSkaFcpyIacQ7iTq0KrydckeIfiA6TGX/oNz3RH8n+o7o20hyJeibSHIF6GvKfUX0JdEh Kvsb5b4gOkh0gMr+SvQXMv6Z6HOiPxF9RlX+SLlPKfcJ5f5A9DHRR1T2IdEHZHyf6D2id4neoSq/ p9zviN6OJM0EvRVJmgF6k+gNMv6W6HWi14hepSqvEL1MxpeIXiR6geh5qvIc0bNkfIboaaKniPYT PUk1n6Dc40T7iB6jskeJHiHjw0R7iR4i2kPURjUfpNwDRLuJdhHtjCQWgiKRxFmgVqIw0Q6i7UT3 E20j2kp0XyQR5zW/l3q5h+huKruL6E6iO4huJ7qN6FaiLUS3UGc3Uy83Ed1IZTcQXU90HdG11OAa yl1NdBXRZiq7knq5gug3VHY50WVElxJtIrqEal5MuRaii4guJLqA6PyIqx50XsQ1D3Qu0TkR1wLQ 2URnRVwhUHPEhcOYnxlxDQVtJNpAzddTu3VEayOuRtAZ1HwN0elEq4lWEa0kWkFdN1Hz5UTLIq4G 0FLq7DSquYToVKJTiE4mWkztFhEtpJEtoObziRqpZgPRPKJ6ojqiuURzaNK1NLLZRLNo0jXUdTXd qIpoJg13Bt0oRL1UElUQlROVRZxB0PSIU9xhWsQplvfUiPMc0JSIsx9oMlWZRDQx4kRcwCdQbjzR ODKWRpwbQSUR5wWg4ojzTFBRxNkMGhuJLwWNIQoSFRKNjsTj/c5PotyoiKMaNJJoRMQhlsZwooKI YxxoWMRRBRoacdSAhlDZYKL8iCMXNIhqDow4xMQGRBxib+YR9afm/egOuUQ51Flfoj7UWW+ibKIA UVbEIbzUi8hPfWZSnxnUmY968RKlU7s0olQiD5GbKCVirwUlR+xzQEkR+1xQIpGLyEmUQBRPDRzU wE5GG1EckZXIQjXNVNNExlgiI5GBKIZq6qmmjowqkULEiViw0zbPK9Bha/C22xq9R6B/AA4D/4Dt e9j+DnwHfAt8A/vXwFco+xL5Q8DfgC+Ag7AfAP6Ksr8g/2fgc+BPwGdxC71/jFvk/RT4BPgD8DFs H4E/BD4A3kf+PfC7wDvA74HfWU/xvm0d6H0L/Kb1VO8b1oD3t8Dr0K9Zc7yvAq8AL6P8JdhetC7x vgD9PPRz0M9aT/Y+Y13sfdq6yPuUdaF3P9o+if6eAB4Hgp37cH0MeBR4xLLc+7ClybvXssL7kGWl dw/QBjwI+wPAbpTtQtlO2CJAKxAGdpjP8G43r/Xeb17v3Wbe4N1q3ui9D7gXuAe4G7gLuNPcz3sH +HbgNrS5FbzFfIr3FuiboW8CboS+AX1dj76uQ1/XwnYNcDVwFbAZuBK4Au1+g/4uN031Xmaa5r3U tNC7yXSn9xLT3d7z1CzvuWqB9xxe4D071Bw6a2tz6MzQhtDGrRtC5g3cvMGzYdKGdRu2bnh3QzA+ xrQ+tDa0buva0Bmh00Nrtp4eekg5ny1QzguOCq3euiqkW+VctXKV+s0qvnUVL17FB6ziCltlX+Vb pVpWhppCK7Y2hVjT9KbmpnCTbmS46aMmhTVxU1vnvp1NnvRScHB9k9Veujy0NLRs69LQaQuWhE7G ABcXLAwt2rowtKCgMTR/a2OooWBeqL6gLjS3oDY0Z2ttaHZBTWjW1ppQdUFVaCbqzyioDIW2VoYq CspC5VvLQtMKpoamwj6lYFJo8tZJoYkF40MTto4PjSsoDZVg8izVnupLVe1iAFNTMRLm4WMHeIKe jzyHPDrmCXv2edR4m9vrVvrYUnjRtBS+NOXMlMtSVFvyK8lKMLlPbqkt6ZWkD5P+lqRLCCb16V/K Eu2JvkTVJeaWOKWyVOPCYuKBQ7S5Tkn0B0ptLm5zeV1KidfFmeMjxyGH6nrM/opdsdm4zdZpU4I2 VLfFeeMUcemMU4NxA4eV2qxeqyIunVY1MWiFRfSYbZleWWoze81KqNA8zawEzYVFpUFzvwGlTOU+ zhm3g1SjGAV3eUuxr3cmcj3H+7y1siInZ1KbkZVPChunzwrzC8NZFeIaLKsJx1wYZqGaWVWtnF9a 3cqVosqwU/zGVsuft2kTG5s2KZxWURXeklY9KdwMERSiE4KltSaysdU5c1asWpGTs3IOLnNWrMzR fpDjq0QuRxjFz4qVyIvPKi3Pcn42UTXQ3BVIK6Vx5c+3+r898V97AP/5qZWJPzIY06mcyxqVc4Cz gbOAZuBMYCOwAVgPrAPWAmcAa4DTgdXAKmAlsAJYDiwDlgKnAUuAU4FTgJOBxcAiYCGwAJgPNAIN wDygHqgD5gJzgFpgNjALqAGqgSpgJjADCAGVQAVQDpQB04FpwFRgCjAZmARMBCYA44FxQClQAhQD RcBYYAwQBAqB0cBJwChgJDACGA4UAMOAocAQYDCQDwwCBgIDgDygP9APyAVygL5AH6A3kA0EgCyg F+AHMoEMwAd4gXQgDUgFPIAbSAGSgSQgEXABTiABiAccgB2wAXGAFbAAZsAExAJGwADEAHpAN6YT VxVQAA4w1shh4x1AO3AE+AE4DPwD+B74O/Ad8C3wDfA18BXwJXAI+BvwBXAQOAD8FfgL8Gfgc+BP wGfAH4FPgU+APwAfAx8BHwIfAO8D7wHvAu8Avwd+B7wNvAW8CbwB/BZ4HXgNeBV4BXgZeAl4EXgB eB54DngWeAZ4GngK2A88CTwBPA7sAx4DHgUeAR4G9gIPAXuANuBB4AFgN7AL2AlEgFYgDOwAtgP3 A9uArcB9wL3APcDdwF3AncAdwO3AbcCtwBbgFuBm4CbgRuAG4HrgOuBa4BrgauAqYDNwJXAF8Bvg cuAy4FJgE3AJcDHQAlwEXAhcAJwPnMcaxzRz7H+O/c+x/zn2P8f+59j/HPufY/9z7H+O/c+x/zn2 P8f+59j/HPufY/9z7H+O/c+bAJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcA xxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnDsf479z7H/ OfY+x97n2Psce59j73PsfY69z7H3OfY+x97/tc/h//BU/WsP4D88Jc+dw5jhZsY6rjzmr7ens5PZ CtaMz/lsE7uSPcbeZfPYOVDXsS3sLnYvC7PH2XPs7X/3z9e7p44z9EuYRX2QxbAExjoPdx7suAto 08d1s1yJXILOd9TSae/84jjbFx1Xdto72mLimUlra1Veh/Vr3t55GO9X5DuHirxyAbRNa/Gl4eaO HR13H+eDMlbDZrHZrJbVsXrMX/w9+mJ45hR2KlvCTtNyp6FsIa4LkJuLWjhLNH201lK2DGhiK9kq thqfZdArojlRtlzLr2Kn47OGncHWsnVsPdsQvZ6uWdajZK2WXwNsZGfiyZzFztaUZLKcw85l5+Gp XcAuZBf9bO6iLtXCLmaX4Dlfyi77p3rTMbnL8fkNuwLrYTO7il3NrsW6uIHdeJz1Gs1+PbuZ3YI1 I8quguUWTYnSh9nTbDfbznawBzRfNsBr5BHplwWaD5fBB+sxw3O6jZj8d3qXtzZi7mJuLdGZroH9 7G4tVkf9KGqeg5rUCz0H0cuG4zxxOeZA+uiMKHeVNv+j1u5e+Tmr9MeN3Txzg5YT6njrP9NXs5uw A2/FVXhVqNugSd2i6e72m7vqbtHyt7M72J14FndrSjJZ7oK+m92DvX0f28q24XNUd1fE29n92pML s1YWYTvZLjzJB9iDrE2z/1zZT9l3Ru2RLsse9hDbixXyKNuHk+YJfKTlEdgei1r3azbKP8GeRF7U otzT7BmcUM+zF9iL7BX2FHIva9dnkXuVvc5+y97mVqjX2J9xbWev6j9lcWwMY/qH4Ocb2Rx89DiV Vqiv4xRRmYENZ1PYVDbrYWbF6z6RjeC7d7uKi439DI/iVa4wH4IBI+O8KGjTKdYH3e5C/4NDYjap jgltvN+uQsMmhLmF7R+0v5zX/sHB+OF5B3ne+x9/8LH9y5cdw/PyP37j44EDuCPDocEZpxgMzhh/ Zn9lSHZgaH7+oNHKkMEBf2acotkGDx02Ws0flK6oTmkZrYg8V18/UqNOa49RNvoLZ+Tr0902pzVG r6Qmx/cblWWvmJU1qn+aQTXEqHqjofewsZmTTi3JfMfgSHMlpsUbjfFpia40h6H9XX3c4a/0cT8U 6U79YbMaM3J2YS/1WpNR0cXEtKUnp/QdmTFhhi3BrjMn2B2JRkO8w9K7eHb7+a5U0Ueqy0V9tU+B W/ydh3Ub9U6WyQLspj2sV+fnuyx2PtnfFhWBts5Du8wQZilMEEG3UFl2cbVqV4t2DfbmWaI418yn 9PIHsr6xmC3JmWl+k5Un6izMYrcoO/yP+V/xq36L3xKfVh4f0odYYWFh/PDheXm1tY6k4Q5IR779 4CBHPjyeU0uvQpaTk5WYGKO5PFvNUONUf2YgMHQYJz8nGfxqhm6VkduzvN6shFjd0vbPTlZNCf7U tCwbN/KIzpqSne7r647TreMf8idOSvTE6VSDJZaP7Hgu1hqr08d5EnURc5xRVY0286b2deJ/gm0T /4ELqyud5bAC9mzQ7U228yleu01crLgkW3DxYa7id8TB3m5XEOWuIMpdLnOuqJwrKueKyrmicq6o nPsQvhOyzn27oVkgH57eiZrgQzttUbZq/N1Oi8af7zQLVuxB6xbzPrNidmd/M3CgoZf2r9Jlg9u4 udVQyQoPFmrrdjjPq/1Yc9qgN3JIwJyTM5w0nOqM0/kzMgNDHIOH5mfAey6xntNVPri/4vc7xGJO OCp13FswrWH5hI7tSX36JPHAys0NgxJzxvQdMrukd0e7u6BmYmR/UfnQlKlZ404pe/nwyKqiAF9x 0sLy0X1d3mzd2dne3Mq1U/pXjiuINw0pP03heZOHpHbU+kdOa39/RNUob0dB6rByxll95yGdRZ+O XTxvZyobmRP1Sk7UK+ADwivgL4RXcqJeyXkU37HjWDLPYxkswHMjCRW6vbwvG8IG8P6tsTOwpd84 KMDzaPr2t/YPHJDljIvpti1jXNFtKjawy5muiHmLZaWzKHqjMzh33YSNL1w2peLq184sOLmm1GPU qzqj2Rg3aNryaTM2NQ4b0nD5rCkrygbbDKYY9UF7cnycs0+2p/KOL2+69ciO2S5fX09cgjvemZoQ m52XXXL+4+vXPXLmmEBeIMaRjh0oVtllWGXxzMtOD6YVZvAEsXISxMpJcGLOCfGYcEIyZpuwV6wc 5ibfuKO+cUdXjDu6YtxR37j34nt/LHxjicSVedp4oFVPq0T64g25ImrFiXbMkjB0WwCXzbjz0F0d X2iPP+uez28q2z146X3n72hdf1/TcOX6e364s5we9MzbP79u8e5zJx5xjG5+XPwfVcxMXY+Z5bLV re7s6BPNjo46Ozrq7Oios6Ojzm5THMHY2ARfgg+Dd7dxY9DaHOD7AvzVAA8EYlLEL2isZdmg1piu VV+7vAnTytOOEXt09WvPWfnRSvdnOI6T6nqdyWpsv1LMUFlgtBr1elw6YnjEiKNBFws9VeFGq0k3 Lt4Tb6TZGuM9zniPw9hxcqw9NSHebTd0DDQ6PNq8Ow+rlZh3NpvdakiIzjshOu+E6LwTovNOiM47 AfPebU1j6WkGTG1nQkJKTBvvvTOzLEUckNE3Ut5+x/Cu2fEfTUa+beR01UpMzNAB7xkweE0HjU6f OznTacRUSzXr/oRUzGK8we5xJXgcse1/NFgNej0uuu1ilmliRrM6v9Ct0ftYIbstmJaaaksWKzRZ rNBkcbYlmyxCYRbJ4ulZ2WPZ3JcdzK7LVrNt0fnbovO3RXeyLbqTbdH528Rfh+cN5oOT27hpV2bm 8LzRe7kJ73gT7xMZXuFs47mteTPE88ZudpA7oufcG7W1+7sOuqhfjtnNQ4c5xCoQu13zlkOcgEf3 v063Rme0GCwFc86pOeW+1YUla++dP2rdkI43HA5dLN4RN5gT403xI2bPaxx49YHbZ9Tee/DyiWfP L3GbdHMS0hKMgf6BqS2PLl2/79zitDR+RmYvuNFotKfGdyS4A2mZyZbabYc2X384XO/293Fn0vrQ Tcc7N4+17SocyP2WqIssURdZokvEEl0ilqiLLMK5qUm9zML7ZuF9s/C+WXjfLM4Hs3hHJLGgCy+W YIK42B18MguinCWJX1qgQPADKEvqW44XSG7Qts/CX7Vwy7FvY2yog4Ucb403hFujS+7oxqrN6lpq 3VcdnZou2KTUTTc6M5LdPqexfSdUilh5RmdmckqG06hM0dYilBvex5KzGJXR7U9IrXtHqvbDSozU 0f3Fq+A/F5v+YGHStKQdSSqLupBFXciiLmRRF7KoC9lDOBNNnfsehCdM9nJtuphm10GY9aPJ8Co5 7lhXRlJK99EeHaEYlaHzC/4pRtWbVe3B6/3Eh5OG4Tj4lLQ4f3nsXj4IX5OT8e7SR99d2PQ53d7c YnQxMpzU4s6jI/00tXhpeeqw/plmg15R8YYypvj7ezMH+Ow0hYRYXjqluWZgrM1hsThS4hMRS9ri bY7+ZWPUm8V8xC6Inl/fYyb5bF7QMVBs6wFideUJlWGKetoUnZopOjVTdGqm6NRMYrFaXNnlGSa7 p9x+NM4rlK8frCNcyeOBQDb/iYUUDe9czhgD54mJ6vcGZ6bHn5to6Oh1/Griz8fYkzLcbl+CwRrf UcFfdhhSxVEeYzcpF7Sf0XWoHV1VjyuFsRaDTg+D1Z3U3tl+vTsh+taahNm72fg9zEWTdUUn64pO 1hWdrCs6WZf4Hxss1lbuauM50dcSz3tJPrdu76GuLSKO50l4t8S270/q0zWJV0UwOsnpSYjFW2a7 HOoPt8Y6UqMrPyYHb5ZRbFvQXjd62WjFOmBAUl6eqX9ysrvtBMMC8WDSew20WEziHDGJc8QkzhGT OEdM4kmbxLJEhBpMEWu019Ayc3KSNS95YP8Yb+8yb0geE4XxCNfzMVEZZyJmt3cpx/CT8vLzRRTf bVf5uYjcEcNz/zFvKy2I5/nieWv+ickxOr0pSRkJRqUjXzW70pyudKdZ6RjHcWakJOMh53oW+Qb0 So7lp+v5+Wa3N5CyxOZJsBzdnAt/2GwwGVQdgjJ8Tbquy35X314Wd2/PkZnqXel9U8yxCWmu6Jm8 Ue9gJ7HzdmbbbM6oMzW2Rdmq8SHhTGfUmU7Nmemm/v0HCWcOSraJCyoOsluEQpVBooqdpReUm/rb snUp4o0uVojmPuG8H/kuLz+6ZMhT2Bv+xETXT/grXU3KD3RbVbqNVpfbOsyd7fe7Ohb5xqQqimJM 8CYne+ONue7ytGxvmoOPSBs6aGAyR0CT4E1J9MUbxznxvdCcNihb+Wj4hpHjr5545Ouu3XJf70xT Uh9v+7ODG+pq86ZtnaY8im9NiIlwUIj/idt5UPe5PgNHVjZbH3Q7hQ+cYkE5ReDqFIGrM5nclB+M 9bEBrBnfq9Kjzk2PrtT0aEiQHg0J0qPOTd+L4N7EUhAA2Cr8YmfpZxwbwNYedzJ2fdHW4tdu0bzu 84lXfrD5ijcvLp64+YPNl72xqWR39qxrly27dm6fQM01Tcuvn9NbufqmI61zZ9713ZbrDu+YO+PO r/+LvS8Nj6O6Eq1bVb1vVb3vi3pXq9Xad6tLtqxdtrxKNpbwIjAQ402yDbbBgA15hM0QYJ4J70GW CWSYAMabgORhf8/BjyQmkIBJMkDI5LE5MQxMPpYYdb9zqqolWZYnmffNj5nvk4596vZVd9W9555z 7tmu+gcbf3zHgqV3Pr9+6/E7epfe8yO01UEzngL581JJ6rqDEaU8EaU8EaUsckpZ5JTyRJTIAg7e h+TxIXl8nN5AenzoDfqw9Jjio2D1HFIq9TBN3SHbIv0Uo09iEO5Cuy883dhjp5jszClhxw+v+6bG EnKhVil2E1tx79XX9iSPNPYPljzyrQXr2yLMN9c8vLEpVzohF7DUKkd21fX9C6+pMo5/mWhfR0kz ZnUw4xqqlbpX8HOlfK0aRl2Ls6gVZ1GLs6rFVa6FVT6WRB84meWRFNDiZdLwMml4mTS8TBoeS5K9 pRzY+Uc3C0QQHHOAAkdCixyykhGte3RqL/Jp62UpEUMCpcxFJLE7/Izs2josdjupisVjsYJTo1Na I353yKpjd9jSzUsbRwrEAifHUt7i7h5ZEA/PXVUfrEonrKNGdW68tc+Vrbz38dZ1cwOgZGCz1ICI l1f1Z8Pjv5kgIpjMCsZQt3zTvJb1CxusxlTTgvLcHyI+5taeqx0qZa4n1NgH2qY9f45ZB3LTSb3/ LNWS/+CwiSM9LTKJWmTStci6pkUmVcsYXSKkKgSLlfRUCGAxRCoiFXqPEz/rQQXu4ThE8BEPLofn Oboctfghj2hwHD/kkq9W6XrUhMahvvR5EqdqwcyOCTo+WEtqBZ2e9PBYD6PFVi1fy9ubwCc50uJR JJfYx0hSlkNYgnM8elyp1CB3jkNWnbQWzdIvpgkoe4HpUjVhykx3wZXMunk7vj3Ysqm/0aEDs0Rt rOzb0lU3OC9SsfjqjVctrmy8+t6lqf7eJouSpRmlTqXLtA421PRVuSuWXLPxmiWV5GuX3b2uwh4s ckYDdp9ZVZQI+2v7KmsXNJZXNi/dsnDRnuVpkytg0fFOixk8c2/Y5yubG61Z0FRROWfJFlgjE8j6 G8D5RdQVx5wCejk8Uu0wmnF/s+DjRsrnjx9Bzlea0aHzybJdAWbnJyJxfpLiTqYm3LlJw7qgzkRT 4Q3RDb2/YPVAS3ZTmX2ikyp6cef/5wQjrlXzXotFCvSh5fAPoKmvB6smRR0QfKvTJIhSG0QpDiLr BHHvDyLX4JlTgZ/qQwCnUXZ5wnZ5wnZ5wnZ5wnZ5wvbnaA7ta/Q0sDBN0MAttLHF3GLPJN+IjoWs wVOTLDJILjYArdONXPb6+TeNbfva0ze2So6sRV2yZFtn97ZFKZE0IbBx397+7E1zm68/uoMJF8jx 1acrb1uRLhm4pZ9xTLXZi0C7XQVUiVAbBV8EFVsiQtx4jblJwkFiBlLiIiVO4hqThVRsoNpzFnqw IZixy+V0OWPRwGKnwix5Fub6LG8mkiDgDKnBQTI4OJgaTEVFM4jFzb2mZorxU2G3K1X0Mdboivvs ISevVzG5FWpiThR5Q2YNS0YIuZpRg+oKRAyM2o8BSwIWrE7NPiOGNNUG7fkX2Cz2Y0gT5zgHbMZ3 YI5N1PpDsSZSMZb/QpiHgh0FFlRjI5EhUU7siZIiJzaSRcQZxEa6nKTLSDpC0mFSu7h4cbhMx0x1 FMGCycLKwQ+GamWITth4TKE1fZoXTlixl+W8SX8g5TWyuU/ovzBGdzIYKvGamNw/KAkfCwYiFhVN woRYGY016veGrBqGJGniY5SWsM8f5ogiZuTRLuGNzKtfZQpt9gmHG6li1J0/yTboTOjimHTnX2Qb tdBWGN0O3ONWgTbOMj8Ff0egnhaCprmBuZm5jE7jqNIDa1ehfFShaFRxuN5VY+RzwUjF4yaK6CmU IKpB1tQNspXYIEtDQ4FHGsZotWDlHT+hqrgquvF4FaGqSFVVaUvxGPEIpleKSFER6ztb2jXnTX0v S2UKUS0x0DG4ZWiwYPKcTA0N1ssRrgrYAIfAtsaoOFiB1crJmGZltWz/yD2sKDsqSbnaMSDCZDmv xx0wNt67qH1kUbp59PGrd9vLF9TPWdNZrleDiafyzF1+ZdWa/7Y09r27WofnBlb0tWya49TrwUbR r8y2RduubOnZ3BVtq+qr9vjCPjXnMrl87rDPUrLsxqUnHelssm3J3Fag7gGg7uuKLVQx2tZHQPi1 oRpZa9TIWqRGphe+FulVM0a+EDy2FBqQqSDGfZH+KdRZKU4MB9NaQUPZtDXVIVZRNkYUR2Ndnjau px6aBxW9opYBEjrqJ+zrSZpN6Jm47WKFIzFnwXxU8Xa7aFC9Xrlu/2Cqs60trjZ7bGAwK1WWoNMF 1nOiu6MjsfaO/sSTtqrlQrBZmB9v3T2veaDWRd7f9vy+Nj7WkNwIOodlQeco6tSSm60efzdZF+YW 7H162/xbhueYi+dW5A4s6W9atwskdiVQLMi8RFVTtx/0iju2FEp4Rw4hfHAY3bIZAqofXRhIzZ+V Aqy0TjBkjMToej8gaA0dgcgYoQ9bupg/luN+pjF0lJeMEeVBTS9GHFLnRDQRXDs5EUqdFjJXStu1 cmrAnAnSCpWrqXsgs+bBK6pbthxYkVrUWu3UKGmzwRRvWtawY09IGGyqX55N6dE5+w7v4g2uqM8s 7Dq07dYXdjZy7iKn0eI0xwOhROjYk/17B1KRVFht8aGcrga6PKy4lopR9dQdQiDbSHSeepTOety9 6tH6qUfuqEdmqX+efElRVEaiWkYmVkYmVkaW2IxMrAwylNYSatPVxz2ssRiL+p1dIOrsIWOvogc3 bJGdstNi5yI/Tbi3U0UQzM8JrmJisanOSC3zsIr3WjEd137gsnV39icq1t57+cK9gsoaQJ7SfH/e Da1Z4CDgqJbQHKEt7iow0I7e5b17D64dfX5f+/x5tK7gp43PB95Zu1toveUK4KV55UitQaDWAdBq +JcEnxSKMzXZmk01jAWlyRLEQLQlVIK2YglSS0pRifoNeOHLI62p76VoTL4cQWmrYmXmY2UeE1/r xKuk4FikXyhUcuomdj9LH2fJKyxhWW/mzViX8+xq42YjbdSc9YoMNjg1Yi8J5VspidnEPJUooMpw aApb2S5kPtoWrxEJqmIOxF3jz/jbNi8ShjszepVOydCMSlezfIuw6bGtDU1bHl13zQOr099nrt8x Z1VzEbjD8VD3dctLbW6byugyGywmvc7ltDTvHNs5+uzN81tHvjVgueX+0p4ranHnjOb/Qt+muA52 zuFn7BwKoCh4HllreQrayiOrM4/MTB48vlhWHB3LvyKYMQIb1Z6raXfHzpV1BHu4DtGrqUAvNnWy 8hNJxipPTotb2+S411SvJizHsCsLcWv6Ntj7lSqbP+mJVgWNL6l1GoXZ9JIaVJMzaFHv4ThUNXvC Hdd2hedG9GATmCwOo0Kj0zgrFzWsVfFuSyT41R/RfMCEFmMLRixuXjU49PXlSYNJb/FgFrQ6903m dub/UM3UAupy6hXBZk63o5S1q2HK7UHOQnraK7NgVSAJsrJ8wfWdo/irrGohNAWDyUx6FnpYUxlT qVIh93AivY4LBmikK1Uej6oyzSKNhSok8gA+YiDIwccGiqOCDq5RU5mKqev6rX7JBzbb6jrmw6aO 4uDc39R1Xfab4EI5EZSVUgNnJNWfqjyNxHWAAYYmGA+d3OkU/EsVEFIdaGy3S1tBLK4EfWZ3yJ5j gedqYXutqhGxJNngXJKq2MR2ignTWDxuZORXzO0W081hb8XgTQtq13nMjpaaP87bvLi06mvf33Lt gbUlXKg8WJ6piAYiVatu7km2BwjH87ncFYNl7RnHFZeVd2QcSy5f9GEw6dTs2959RbOHGQ0HIv2Z BdctKfHZzaX+cCmtpUNzVjQ2b15WHhVWVIWa6ypdrp6SOatj0cG5vTuXpjXqUO6TVeuDdZ2JFVcG ajvGhxqytNqVTiZsLfN8Zc3I3wfAw3kUduYK6vrD2SpSPJmKkhl7So5KzlnBtuzwSwkHMfUgZh1E taHD32mlXIO/2AUOvfJYuivS5uoR1afoyE/EsqXNuP7CgLu4m6hmiAJLpqONeVRtlvZcZ2lnWfPu VngphgILW3H7/s6Vu3pCrgI/06beodbIwLLxOwo9U/ff7s45V96+BjXlrfm/kEWKDGWjQtSdx7Lh heFNYcYu23IXeDgW8frONE9I8nyep7dQXsp2qQCxTFIbkOmoNoA1AniQ77CL6xTpc+ZcStaG8s4y czbCgtsuMiNwIWmeTgBLSWNDCv9PkIDZV4jrk7KG4mQ9/IcZ51/PfZMMw4wjVBl126GFFVi1IRoL cP0Uxx0tKHYs58AJRPFvGqT0lPy+KYkMaV4TGQ3QfYLW5aIqSnGOpTDHQ4lApxV20oMKUUphpnxl ZcGelWYLc1VcECCwX+j1XTDtRX5huD2YdoI7xKg0KmXYEcr4jQWlhzQoTjU2FpuGdy1NqbUG3mzA 7KzCmu7oZJ64mBySHOwGOaiiHhD02RqSLCflgpn0gnn0iji5cnn7K8fZ68WruP2VP0/HqSJKL9Pg 0nk7EA23PZ2mkCSSiNiLdIpEp7eNL4iHuR7EA4wtsO7FPaHinQIXTLDB35Qi2a22FLk9YadJmds3 nT/IUrXZVeR0Fdk0BlPuObLRoBNDWYzKoCGf5gwXi8lXvyTbtQYNA5uqRu/kcs/lorxN1h2kGWhm owQxB7dJzMHNnOSa5BHyxWEt1ybOWGaAmXNuF3G26+KhyaNQvAI2Th91VvCYMT8l1knERG82Lrqy mxeTtotz7VKEbUpO/uyEfvP77RiL9ldI+RAxMyImRUQ1pwX+PtaHMZG+5otLF6TbXlTi8Dz5ApQs R5TPdHeB8a0UDC1dzW3pus50j2vK+k8NbdfLcU6+vpD+Q20pHuj6t1TmpXSoTXa/ZWZRvCKpUova WtJaWj8yH6XHEbKo7CXzSutHJzSr0ux12H2cqueezroVrWVcelF3e6R/e2dgUseG66fp2It7mH1g mDCMRqfesWyhO9OSKG8ttoDy7SnsQbCCFdT9gklaQUTydjR9lS5ROYHOol/HcYVdSUyNT8mKky+O yRsTbkuCNt1V7Ip0FkiPVsNklpW7gNp/w/Zk+2vb0wQR/673r2xPFxAKCLQadyf0Bt8GCmGO5XHB m02ShJkkeYxNxfQkpiYxFSkWoyEz5FXemTGvgsa6P6Ml2ikJm+CFCZvnaC3Gjo+ZqN7NsEwuPMls 6gqD5yi71+ghyiTLTKRhBgs/fy0fw7zdMPLDrZv+fmNN/cg/jsC19klP8zULO69uDXmy1yzsuKY1 SN7d+Oxt3XNvPLwVrl1w3d15y9r6qstv6e26ZU191dAt+bxEG8VOOkZuAF9PRT4lfRTS7EDufuZ1 oBnGHG7CmEOoZoY8taSVJhPWaNzYpHCDGHgQI+tS5GHGeEMnt/CS8YaZwg0z8M6lww33DSVaW4TI FCay2jxmVbKnd1F67Tcw3FAphhva4q075zWvqHWTD7f/aG87V1QVzjUXdCT7IfASwwBXXV/cnLT1 7Htq2/ybh5ssyXnluYeWDDQN75a1KP2YGP9ad3hzNYmZZBJNlubIpDLJNDQhqcxTwsNIM8oNFIwK mlRXzGQLdtp6KFmpidtaasLim+rmzCROIkmU9GO0UqNWO3wRm6usuiE8XZiiLQ31PkMo4tOzDGHW 2v28RqNRW0t7asefvlic9ta0xk2MWqvVGMUKrUX5c/TLMONO6mVBn+nOdi/s3tP9VLdiSgrmMzn1 IkpSCwZhLNNSM2JKhrwpBKQ8jJiBQaUjp2HQEUTJ8jxHPhOT6Vrc/PWCaBDAyxjcL6t/Sk/rS9+q 1f6R7+NX85t5Rkq3/BPmWrrsH0isNZFokdMsgxg4n5JmmbQY/71pFvrlyqFbFpT1zy+za1lMo6Sy y+uKWys8caFv2SIhnly8a3GkoyFpUzFgA2iVmqKazkyxkLQlhMXLlghxYpy/Adbb4bJGAhawsjxB jzlcE41VJQJFqeblTdVrOkv0ZhunN9k53sWp7C67JVzmjVcngkXFTUtxLUL5j+lr2R9SDdSqw0mK D6dlmqfltUjLa5GWtVta5so0MqHeYUifC3f4DOccHeVoY6ok5XQa2a5SjtGcPikFsNiZ3egLnW17 IehAX6vmgslSR9uw4LvRZMZcyw0Fc+R9jJCaTe/XtjsiXqtaoVGwl/mKOKNGGe0eWUAbJT/6TCFV fkbytHPawcs1Wo3C6MR534/RLOZHsPPdJwRgv9PFkYPiyEFxzEDERXsjzomGBfnyqCRpAZkqAZkq cP1ClE1sHBJLkWVhDcg8GkCLXGNJd8Z1ClcnmB+KyZDW1HKcCZaaMaQ1LSVTUzsZ3HpYZfbZHD5e 2fuguMGprJIl7sh0lDXvmq+yBkByzZqJfW/HsgVN629fSxcVpHP8zwsvnxcdWEZvK/TIuRlmF9Cn hPrDs1Q4D7oZzbmAmLGIBohfaviJXZ6nTb5aJ4088WqeyDTn/0WoxTQ17J08iXMkoSBFCeiYU0Qi RSSEzWyIREIkKPYGSSRI4iayPURCGMrR8LaOUBCkNoQZHw2wYgjjaPgKVyKE99djiVSiM6Rzd+ok BSgmu1JYwT4o7o8p6R/mgeTadsyZpMQzBRPFMZMbp8PiqLXIhwl2EZqhc6dZgzvh9ydcRjb3MqvA Mg6HL2zRsDmWOU9rLSGPw8+rmEdYjVav+uoHmApi1UYt0683axjwfGhAmnG3Xk+/p9GrGVqtQ2pX gyW9D6g9n3r7Waod1NMcmFodhniSdaQWr9FSEguRWJDEAiTmJzEfiXtJgiVJhjQ0ksYG0pgmTfjt GDbSy8lOMl4FLbArF4Q7cCa5G6+CHjcS7Da1dIrvQ2JmuYXcJm4Px3KC2d7BVXZGOxv2l5AS/F0J ak3OYu9YX7KjhJ4PvY4eDRL5daTk4Mls9jRQUqL3ZMJNSrlJPxKhlRN0ZuKqKRmqGUg+panYxypy nzMGR8IfKHbpmR/T9FOMwZ30B+LwKvelggUb2uEtMquZ39D0KVpjBrYPmNX0GzQ5Q2ssIbfTh8ui spomF4W+S6MZH5lcIpNVpdHBCoE/Nu7WaGCFDKB4sVjNWXhFq7W4XkmQjm5Yrwx127NUORCGxyg2 6o1S1BiNpcQJ/HgUs1ZO4pB1g73QZSca5NZi9M7wM00UqQuTGh3RBdGIxlXR6crLkp1hHe/r5CcM ZSmfmZnIZSLzSvybitqtheMZk6czJvN+Fksh2UeYeWpLPOAP23Tsr99gdbYiry/KEw1x5j5XE0s8 6AtbtezpV1gtH/D4omZak/uyxGjRK8AHVZErct+CC6PQW4zkGHnMaDGwjFKryh0kC5VY7aWzmnJD qD3AAtwN9IlQi5+lPDDXapR8D0l6iFN0EZ0kZqwx0nENceOW3OAmrjoknIsEOl1aS6e2m11Idcuu GeY4U5LQovCGGGmqtRasW4xVTeQ2LWLswm5V0ZXXKcsr3EGeVu7WcEzuBTUX8fuLrBoFIcwXSr4o 6I3wytwRjlforUZSz5q1zCqb06hg1CbDeCl9xqJTwD5hhpmsAIP2DeYYlaIan6U4mIkdc80xsfYm A7+v0rRqaE2UB9P8kKvDFBdNdBg4hpgrwFY4PYh1lhMliGI8k1xQDi0WyRBs0m8o1Ub1+BmbB/mR 3JXbw1mwRpFmdbxehX25beT7aoNG2Wbx8CpvqMhot7s4+ppQ1AyvlUY7HzQ6HW5u/EEV5xG/x4o5 Rn6p2EnZKDvlEQxawbZH8TsFrbiJs3dQ2bfdpwdJxo1h2AJ7qArMoyJ+JecocnrDRlp9RG3gPVa7 W8eo7lIsA4FhVQZe8yFoOFh9TneMook2/xl5UzEET0pSxiOKqKeXa4Ple+vlKdVhTGwioDTtYNaP VXgwymtW8URtC3s9YZvaqHElAoEkSJ4zGQgkXBqyrWBXM8/pzXqFUs/rz9eHUh6dzpMKhdIunc6V hhUpzr1NRqh3KA+lfUbn8FLca6elUiVpcsg3E88dURod/O0Kg8Vl4R1awt6qc0bcrohDd0+gqjTt elmlVYsKgFhu8gQ5pZILIlWfz39O7mIeEH1Cz0HKOkbvOqb1h8GjNQFVT2dPo/FTcXFZHD992nfh HIMJnGMiiHOc/poJBktwfiXBojRe0+OJkNQBE4ZNxJ1GbfR3MJ6NMGMd5TiIxTHHj2IRjIYBtQFD SZ3A6U+J4G3MNDeV4v9r2zOl8+E/3oPk3me0iv8F66c+yCmoTKa8zCGTS45xqR5nDVafzRUys0p6 kDVY/DYwxljFJwYT8oPFoNxlMGmAWlYD3G8+OUyX0nMoE2U8TKl051gKi+nkiH9IGovI86VmPjdk hh/yHeBsBfky7g/EYn4l74a73Jp7jPyr4g4qTBUJNgZVK4NGPSOKH2ML6G6lshmgtlTkpAQr0uyY OKhWyojSJo2efHz54OWXKYjR5zK7LXqmZnGdN1C/uJJoOK/d4eVoxdqXcivOvJFb+TM9r1PQSrXi yld//daWLW/+5pfrWaUSGR3ptBNG9D6MKERVPkuZJZvHLNvMeD2CIzOLBV460SuTRpiqmKjDmhCx GnN1FR2XZcJhN5P3vXWLahi9xW12+wxEsWpoaIilOa/D5uXV9PpttGvLW79+9UqFWkkrQCH8lDz2 xhny2EsaTgujU7KncwthfHcwV5J6xTZYR80zCq4dOGCqABbiAaRIZXKazS6jyqG1hRzOkE1DmNsK 8kV+IYYlNRjlo/GO9EPiHUXJ9sTa8bbZ0xUz3vjCHruN3gtqxGx2mpQOrRWfZNWQ3Ncv6CuLTX80 tnLlF/ZxHMWCI/eRIqDoopZSV4nnlTOCtnOkyn+da6XKtHGMMEcW9CaTpvoxojzS2jv8J1Nb4YSS GB0oL7MgQ0h8UTl59M7RzFRPeiNSHxjZYlpKsk+keiFiFWN4heoOppBQLmXgDWSDX1jfmaiPcsWD 9101cPOyVGzp3sGivv7LSsAi16u4gMsesIIlUu5Pz8sEtFqzDtZRH3Rby4Rl9cWDV4/My25Z3VMN hp0pkA50rmvy2Erbyqs7M/bRcOuV85IL2gVP1frVK6IV85Lm3O/Jstp1g/0lNQM988PNW/orY23r 5jSuXXVZRXLFyv6EZ35vXzKiNWhYWmUyuOo2rB9KRMr8elrtdLn8Jq3aGG4qLWpIOuzJ5oVrGdpT N6ctlZwvCBFfddLpSTeNJ6qWZ8O8L+lIr1m7pjSYzQrMrfj9fHmD8jpFKbVZPDF/zaEte53RMXKt UF6qd6brqF3OZc5lVNu60d8HEoHyGz/iV37U19et0u8t3RJR8AGAoTkfbdi3qPvjIVAI2dfOiR40 rE0FX585J547RRf7xEnsPsG9egYc79/zWGxKZA9SXotCWY2jVtr+YSdC35GVF+eCuggpgR0RbUyl aE2KFQGsnC+sJcrr+Fjzyh29ybaaqCrR3TE/lJpbGXFqjcG6JVt7go01FW6e9cZAXhT0Cq5sXnJu RZFdm9n6wv7tY3cOzy+2qypvfO3bndv7a8BHV9CEVenr19yy4Pnc+Hc7dIG6FXt++Lu7vvfxwz3j P4r1VYJ/H7ZrqrPOirps7PxXDGm9+7YdKystkfpooj7C8aGypo7i1KbtW1bUmoJloQGjkVWBiVXV vyTZNrh+Q0X//9jRXrVidO/tezbHN43d1sVbeJXJwRvNJr3WajUOfO+9u6u+fuCR//71KxoW7v/F caE12bJ4+aJAVx8fro8zi0GiO8D3PSXWjaeos4JrWkAzWghoptHij5ro3tVpMiVUifF5K/rJViyg tuLBWuvzNGxEVFAKEQRldRiU4/pB2VmG6we4M4Ffh98vImi0WJIuUIx4plmDdSHahVqaEr098VgE PJsSK2GxoaW06RIP/klI0xKs1y6Uo0/W+IF1yP1+cGocOSVajpeOirJToqIscypz7dM373zsylTZ hqdv2gXXp42eVFNv2bJr5tj9LVd01C2bA3sz/Y0HPju4pv8Hnz96/+fi9R/XPLR9Wa2r784fbbj3 Zzc1ROYNbb0VNPGTYH09onBQpdS7QiTiJxEfiXhJ2EMibhJxETSBHSQp0t6Mdn+ZmI9HcpcRCklL JeWYS1ImaFKOPiRlgiZlxyKJBe5GvxM/5NQh1vHo60mF368dgnvych3TlP7jciE4kB4+8ShPeIt5 jGQPhRcnuTGiks7RVGTHT4sRL/w5jaUShapZpCyVmvTuBmUbt1A2C/aoUvLqaqNy3oMX/ehHlFqD anyVSq9TKjUGNTH+BasiGKVOQ4pZvdlpdgbNyrNg/ylaMaal4twWs5vXML9+QMsa/A7eyemVLzAs C1KmU56/RwOGAlB7K1D7YeDpZup+wZCsISk/SfrQUxaQrA4kq0DsyMV20XiwB0WPjE4frYwCUPUy reufo/dQOok4OvSLdZjN4Ovqg8F6YL7So5V2ZekSDraYRIFCUnwwI6YQMdJ6euIYrEgj0QO+gDjo 1E4rEVRObEcqseD4YYXGpBmvNtpMKkZr0p/vv7re7K3uqxILBMEFY2mF2tm44muNQ3cNltrbb9t0 mq5Um3SKLqymVnF+u9XvcBiIdtV9161NpXobiooSRWqz32ayc0ZbJOysXrVzfvOue57aekZjFj2F MvBof6WwUsXAr+eFBgw3pEm8hETiJBIjUS+JeUhYZNyok0QdJGYnMRuJWUmMIzETiShIhCUpDxG5 2CxxcdruhIY9yMl5eylf/84xzOd7S0u5sfxXgg/eweGycKhcOAzCcahcODT2ODxDHadYiYdZUAyF 8idBi/VPbFkm7ikdIzpBy6ZCHKcNLdZKlb+wGpXnKipkfzklxyLxmM/plFRSV1iZaT/kwqKfiSUj kzxsJ2ESYn5lNd9XOA01flbPGcBm1KrA27L4S/ywyXP38bbct+ncZeQxsjkUy/1LIQBHOCXnd1r8 LoeBMaM3owC796sXw/SH4w3IyVeAdn5QYQROPiEY4rUkXiOmmRiRk49KjFwrc2ut+Gch8BgIlron gPQJ6E1gojthXFixqWJPBVMx88GX5+hK8ZykrGOPiLlxyxgmnbD2xOKswfOp+pKGPwexPlZRssiJ f+qgcPYgMwi7NaZHCXdGTi+cHHztNbEpERepO+ORSSmXF77gYDj4BHKhCfNg200HNzRtWFpjUorn KFXa4varO+ZtXlQaX7R7+ZyBmNcZ8NFz1CatwmrO+cKdZZu+v6mePHrVdzY18C6nUc+7zbyHV7t8 7mDr+q7my7MBvTtKm0JBDQhHJJF7QEFXr/kGULqN2sAcZe1UhrI+Uxzx49F2vdJMZSpPj5+u/LeO BEw7SHhUqTWqc2Nq3muz+nhoaQxaJWg5NelU8z4rmu/QMoBXIVg8Zjw9oMPTA8AKG9RmjwVPtUML nB+FdMoAJRJ/vi0ByVwS3qXXToFfSMB0zwCH2csm4DyCom1GeELxhLIY4LpJUEVVxydBXXcJOIig WSWBtnQKPCAB7EwzwX368CxcEn55KTB8zfD5xWC8WwJTZgZ45j8WuEcuBj4swsMzgzkswo8RLNQU +L1161SwgbNp088A30Wwe2X454vBMfT/BR/NBM6/d91QALfBvXUCXv2PA49yFmbhvxB0zwi7AU56 3vvbwGucAuWXgJ3en/674F999b6/IPjf/M8OgXuCbcH3gu+Fniha/Z8UnpqFWZiFWZiFWZiFWZiF WZiFWZiFWZiFWZiFWZiFWZiF/xog5pMJRekepgg5p6QoteJuiqXM+U8Ax0XcQDkAd+c/BDycXw34 qvw7gEfyjwEezT9NseSh/M8BH8//FvCp/BsUyyyjTIAHKD3grXAfnmLzfwI8nH8F8Ej+fcCj+Q8o niSwH+6A+LiIX8T3w32gzSzL/1/KDCP5CHAD3M0MI8H2MKWlzPDbzykn3PmfATfkzwIehnE64f4f AB7Nf0o54T0vAR6A53rhnWcBm+G3Xrgn4m6Yi5cagmd5CZ1/GzAHT/QSN9zTS/z5fwKcyB8HfIPY 3iPih/CzMFq4JzkhfuoUtmGm71IxeMpdgM0wzpg48hiM7ZuAu8X2UP4PVAye9RJgfFYMnvUnwH54 Ygyegj17RLw//xYVg/FXAR7IZwFvyL9AxWGOnwEeEfEoUCAOI/kD4BMwuzhQ71PAp+BuDTCSt6gG uMO7gAfg6U0wqmcAx2HVmmA8jwAeEvuvgjs0wd3epppEOjTB2H4N2J3/HWCkQxPQ4X3A24BiTWS7 iG8Q+/eI+Hax504R78d7ApV+C/iI2HM8/y3AJ/LfBnwq/wTVBLR6m2qG8ZwFHM+/CriBcgHuzv8K 8HD+GsBX5V8DPJK/FvBo/htUM4zhQ8B452a45zOAT+THAJ/KH6Saget4qhtm/SHgBph1N9znJcDI b91wh7NUN9Dnz4B/DtTrBsq8AngAaNUPn7oacEN+FPAwULVfpHA/UOM1wFz+dcBuGHM/UOMNwAng xn6gALb3iHg/zLSfPCT2n0IM96cBD+TOA96Qvx/w1vz/plaKvLESZn0OcDes/kpYhXcBD4vtEVj9 lTBaeA88603AN+TPAN4j4uP59wCfgHVZCbMGDFKmpYZg/J8AboCRD8F9PgU8IuJR7IdPfQj4RP5j wKeAGkMwks9BiliQ6GEYzxnA8fxPADcAjw3DqF4EPAQUGAbwUsNAB/yePy6P39bnzuP3BPrz+E19 fXn8jsBtefwmwu0ivkHs3yPi28WeO0W8P4/fInhEbB/P4/consjjtyy+mMfvVjyVx29V/Hl+KzUM dCsF3J/fCXggXw14Q/4BwFthDFfBmH8FuAH48ypRP1wF73mTGoH+RwEjbUdgLu8DbgA+H4G5vAt4 CNZ9BEBDjcBc7gbM5Q8Adud/ANiffwhwX/5hwNvyLwPeLuIbYIQjMBfEt4s9d4p4P4x5BOaC7VMg ZSMw8iepERgPrB+M/BjggXwl4A35BwFvBf4fhRF+FzDy/CiMEHFD/nHA3WIbqT0KY3sWMAe8PQpj GwPszx8B3Jf/KeBt+ZOAt4sYxzYqjm0UxoY9d4p4Pzx9FMaG7ePAsaMwwp9RozC2BOCBfAXgrfnH CQ3S9GfAD+XPAYZ3Aj6R/xTwi2LPqfxviQne8zHg/fnPAD+U/3/EfQt8VNW1995z5j2TMCBqoBRO BDEgDZFS5OPloFExIIwolOJVM3kykscwmYQECTmmkQZNMVJLKbUWqdda66e2XrnaWu9E+BIfuRYx aCSoAQUrjRiphNSbcu5/rXNmMgFs6X38vrNc6+x99t5r7/3fa629D4knpyBjnG5h2aq/A9nG6Xb9 I+nD+D+DrGVZBzkWGo5DbtdPQlLbsdx2LNoegmzT/wzZrvfIDLTthPTpb0GO1l+HHKv/O2QGlwb0 PZC1+n7IOpbN+hHImEiBbBF2yDbhhmRtmG895Aq9GjKivwpZJ8bKAHo5AOnD3APo5VPIsRhnQAbE BZC1QCAA/SS3Y4QBRJWLIUvEDXIlI7aSEVvJiK1kxFYyYisZsRLofw/Sp++FHK2/AjlWfwmyVv8d ZB3LZtQvgZ4+yOf0o7IEI3xWVrL+StZfyforWX8l669k/VVcp4rrVHGdKq5TxXWquE4tnp+CbNH7 IVuBai2en4RsB2K1QKZL1nGdOq5Tx3XquE4d16njOpt49Tfx6m/i1d/EK7iJV3ATr/4mXv1NvPpN mPvbkD79MORofjIW2pqwdpSu1T+ArGOJ3Q0yBsybsHYeSFq7JvQbgISVQkaw4s0Yw6eQ2/VPIGNY kWbuvRm9H4Nswzib0ftxuR29fwzpYzka9bej92OQtbCH7eiX5Hb9Q7kdmltkDPUPQ1L9GO3CkGNZ ZmA8MR5zDG0/haxj2QwEYojwbsiY8EK2sGxj2Y51jGH8QcgV+grIiP6mbEEvn0D6oLkFvRyHHMsy Axbbgl4oTb20cC8ttHtCbsdZqoV7aUEvTsg2TrdjRVoYpRb0gjVGL/tlK3rpgvTp+yBH6x2QY/XX IGth+a3QTLIZltMKzXbI5zCeVrR9Wbah7SFIH8bfhrZ/hBwLTNowQjdkgJ/X8vM6lmS9bYxDG4+w jUfYxivYxiNswwjLIFfoNZAReHQ7nSsgfZwejXG2oxeSGVjNdvTyGWQtl9axbMbatWOcVBoDJu10 woFs04/DJ610OsSZ4SLIAv0uyAq9EjKq36kswyrvx75oFV7IEfoByMtYzhIXQCLeQhboxZCroG0F 2oYgo3pYWYHxdEIGoHkF9HRAxvRnIVv0FyHbON0u3MoKzOt+xAWr/gLkLL1LId8n6WM5lmVAf08h 3ydZx7JZf1eJUFSEjLFsxdgidOJVNqBfN2RIXGWda6X/T06Ib1guEfTNP7oKWCp8ak/lnMLfVklV rGZaEROUEWbamlTHhlPwDDNtT3ruEFXKYjPtFJNRYqRdQlX2mGm3ZUeivkcsVz4y014x2TrLTKdY tlnjdVJFiX2A3iv4muZYZaalcDi2m2mLcDiPmWlFjHB+bqatSXVswutSzLQ96blDzHYNM9NOcaGj 3Ey7hM+VY6bdMpCo7xGXu1aaaa+40HWPmU6Ri1zxOqlihvsoRiKtLhNnI23gbKQNnI20gbORtibV MXA20vak5wbORtrA2UgbOBtpA2cjbeBspA2cjbSBs5E2cP6lUMU0kSWugFTFjfxXQSOiHGedclGE c4UqruG/pmr8TdUgnoSQKhOZKJkvSkCqWIpnxThVRdGKcoW4F6J2FWQBal6DdiWok4dnIdQIcb0g uBS6CrhuGXIVeFbGZUb7EEaggoOoF4KGGuTWIhVFXyr/Ddc8pEtQV+UxV6J1Af+N2GLWUm5qjaJG qdkn1VAxx3Lus5D/FizN5QaeaxGeBPlvlEZ4FirfgzxL6teYRz5KprDmUn5SwhqDwMh4Hu+lFHpK GLGwOcoyPCnlXg2dNM9o0gioxzDPJf43bA20jbFTT+VAQOW/3lrMKIT477XS38GNco5mHE2sh4GZ 0YvKYy8z51XO2OZxzcERJ8+IUKvmdsasVyOfyfaQvJqXsbZS1lDDOFSaK5+MN62YMf9CHj/N31iX CFsD3Y0eaa1V6AgnZmOMsdisU4HcOlN7FLMwVqgqsUpBtpEgnpYOmVfcmvMxkiD3n2/2n8kWW8xr RSVn+8Css2a93LSckGlj34KWK+FBX23pUe6zgC2RelmdWIM4NufyvWLTrsOJ2mS5xoqXoX4h284i 1MgXGYzpJNQpYH3Xc9ty1h8FhTGPqaC1TJnsU0P7yzS1T0W6hi2wmEcdhoYaPCXEinjGZKlDtcaf F/Ffbo6wvcT1fYfnYFhJDa9uBY8wynZcwX5ntFZ5DuQDhbyCIe6jkNcwj9vG0bpWLMO855ttI0kl hv8UMCaDPrHW/IvHq76iXyNPdfOxgpWMYUHCxgq4PMwWUpNkV2GeaZlpWYauQpbkKWfOm8oNj8xA K1opsoa8RE/nGlXZWZrPH6NB7fGoqJpxLcrjzh8SX86eezyanDmu2UkI0EyMuRhRNr5PRBIRu4Bj VhnHruBXztTAOTgEU8Pjy01pzMpIV7LlVXLLAvZ/mk1hQg/VLGGv+Vsr9D/lF4M+MZVHQz5gRP5M XquwqP6lOi3rimnqjaH8SHlFeVFUvaY8Ei6PBKOh8rJMdX5Jibo0VLwqWqEuLawojFQVFmReEywJ 5UVCaqhCDaql5QWFkTK1IlhWoaI8VKQWBUtDJTXq2lB0lVpRmRctKVQj5ZVlBaGy4gq1HFWjhaVo WVag5pdHygojFZnqDVG1qDAYrYwUVqiRwmCJGoqij/yKKWpFaRAjyA+GkaYmpZUl0VAYKssqSwsj qFlRGGUFFWo4Uo5x07ChvaSkfK26CgNXQ6XhYH5UDZWpUZoHRoYmakmoDH2VF6l5oWJWbHQULayO onFodWGmak7zsgq1NFhWo+ZXYvLGuKOr0H/hWjUSxFwiIUwbDYOlamWYuoHGYjypCK1D9Wg5JlRF Uwqqa4ORUqMvgjl/VTCCgRVGMpcWFleWBCOJFZgV73o5wMF01G9lXjltCOjRSLCgsDQYWU0zoNEM rl4xsA7T4/xyTLwsVFiRuagyPyNYMUktKFSvj5SXR1dFo+FZU6euXbs2szTeLhPVp0ZrwuXFkWB4 Vc3U/GhReVm0wqxK6aIgul9N9b5TXglIatTKikJ0jgFRsRrEChRGSkPRaGGBmlfDw7p22aL5KI1w ButTUGmsxNpVofxVSW1xD5Xll1QWoCkQKwhVhEvQAWEVjoRQIR+1CsuimWq87/IyLGRGaJJaWJpH jQZVlcUrn3NEXJ1MEctSEY2E8g17SfROZhLXNZsHkBFCLzBZ8okIGXZB+dqykvJgcqcYc9AYKRYe 0wXGlKiMhiujgL0qlF9IdVYVloTPmND5rAWvxNSCwqIgjD8zWBGuTrw3CT1NbBTnuiRq4OQtLhAO Xcf7lsV82xB4+xVygvHzkb9xWa1zvV6JOpZF51s/JYXqK+HzrT9sGNW3Pni+9X0+qm97/nzrDx9O 9e0Hz7f+BRegPu6C3r6sXJ/ePq9hOVykiBFitEjDuXKMmC4mYoe/TCzGqfpWxNZViNSVYo6oF/PE /SJbPIRTwC/FQrFLfFvQv4zvFbeL9xCBj6HmKVEhrSIqh0uLnCiHySukT86To+UNcqxcLjNkUAZk mVwp75K3yUYZkj+UJfJRWS5/LSvlS7JKviprZYeskx/ITfJT2SS/lM0Wm9xu8cnnLGNkzHKZbLFM k62Wa2SbZbFst9wqT1iKlBxLqbLMsk75tqVeWWH5vlJi+YESsfxc2WD5pVJneV7ZamlTfmT5g7LN 8o7yE8tHSo/lP5RPFadyXLlQ6VUuUT5XplrnKnOwvtcNxUjJ+W9g9Gtg9BIweh0YdQKjI8DoBGrq wMgLjEYBo0xg9H+A0fXAaCkwygVGq4FRDTDaCIweBEaPAKNngNFLwKgdGL0DjA4Do0+B0X/IJosT GF0AjMYCo8uB0QxgNB8YLQVGtwGjO4FRJTBaD4zuBUZbgNFPgdHPgdGzwOgFYPQqMHoXGB0CRp8A o1NKj+IDRl8HRpOB0ZXAKBsY3QRMbhuKkf0XSRhdDIwuBUbfBEbzgdESYHQbMFoNjGqA0feA0Q+B 0c+B0a+B0SvA6G1gRD89OSFuh7oCmSpWyTHAaDIwmg+MVgCjAmBUAYzqgNFmYLQdGP0SGD0PjNqA 0X5gdBQYnZSVFqusslwsay3jZZ1lqtxkmQeMbgRG3wFGhcCoAhjVAaP7gNHDwOgJYPQCMPp/wKgd GHUBo4+AUS8wOqVEFJeyQRmm1Cnpylblm8qPlDnKNuVa5SfKLcCoHBjVAqP7gNGPgdEvgNFzwKhl KEbuVUkYjQJGGcDoSmB0HTBaRj8fBEZ0jqkHRg8Aox3A6Glg9BIwegcYHQVGulgJbG6XXwdGU4DR bGCUA4zygdF6YNQIjLYBo0eB0b/Qv7EDo73A6ANg9Bkw+qsssaTKcthJpSUTGM0HRjcCo+8AoxAw qgZGDcCoGRg9DIyeAEa7gNGrwGg/MPoIGPUCo35lGXzn28pwZQXso0SZAIxmAKM5wGgJMMoDRquB URQY3Q+MngRGvwNGrwGjd4HRH4HRKYQfZShGqauTMPoaMLocGM2mn/cCo1uB0WpgtBEYPQKMfg2M WoDRm8DoEDAaEAvlxeLbchowuhoYLQVGecAIb4vy+8CIfnKyGxjtBUaHgBH9dEOXGRavDFi+Llda viFvg52EgEeJ5Q5gFAZGdwOjrcDo58DoGWDUAozeBEbvA6M/AaMvZUxxyBZlpGxVJsk2ZYZsV66T J5SblRzlVmBUAowqgVE9UpuA0UPAaCcw2gWMXgNGbwGjg8DoL0qPNU351JqhHLfOVHqtC5TPrSus c62wGWt0KEYjPkjC6OvAKBMYLQRGq4BRDTC6Fxj9AhjtAUb7gdFRYHRKZEunuFZeCoyuBkZ3AKMw MPo+MHoYGD1NPwkDRp9Ii8Uuh1lGSp9lohxtmS7HWq4DRrcAoyJgtBYYbQJGPwFGiEeWl4FRBzD6 EzD6i6wDFpuUUbJJmSyblZlyO7B4TlkOjAqA0V3AaAsw2gGMfg+MXgdGbwGjI8DoM2D0V6XEalUi 1tHKBquq1Fm/pWy15ig/st6ibLPervzEWguMHgZGTwOjGDB6ExgdB0Y69swU2v+dDvzn82VkZK+v r3fapNPR3dzc29jY2EsZe7hRw9UYdtql09nb2IALJVaU9Goa/tOGZDSuNjNb0x5qyJ7JGTQYoFZO KZ1WzbycinBaVeOKcT+NzTtiO5qbG0mbzazV63RKp3v37n/G9eMfs7Y9ex599MEHm5o4U93AVzUr 4CGTapoCZ5obWZs9t1nzq77mXKdNOO39Zq/xsRkKCIP6+uzsjAyfz+kRTk+D2qDm+HP8N4FUTdXs Nml39DqrGxu5NwcG10h92K3SbgvTYMP83ElVUInrhxv7Na3aacVcs/y9frpQyW6vbm7O1cIGwND0 zCvUxMBHGDN3K7pTUUUCIZqGphFEO5qHAGl3Srt716ubcHGXhi6zd1xhl026HD68V3LOydNoNKCy K9Ju7TbUYBr2sBbL8nU7rMJhNUabxXqo9rZVdpuw2xobAwFVtbuE3dWoNWrLEIEvARllKAk0Oger +f3Uga0bCa3bYpEuq19LGrvQFIuQCgrtUtoVjY5bmsSlaB6bcNmcTp9PJS2aJingdbstaEtZuvx+ zlKCLk1ToFlBgaLAfnbs2OF0YH2zFizIWtrUFHG5pNMzVqSLxdoWbaf2qPYT4YePs0EwMAwNMrk7 GPB+swRjUP1GJisrEGjuh3WwEbFtNoZtmK0d1WFOX+1FMDQHeYSmmR7xv+dFjnN7Ec2+RWvBzHdq D4Jo7YZ6E8Byzcyux4X+Eg70P+VN3r/hTWyfWrI72Q134gJnwp+oILe5lwqswgV/OpdDxZV9hUdZ Bz3KZZUueJTpUi4J64yj+t/zKYoHz8TO8CkOAf5zO5X9bziVfdCp7F/tVMmj/4e9ysM6TK+CN3E+ 7laGX7lMv3KRX7kc0uUiv8rbAsdyu6XTO06o2mL/FtBW/30Ygh9bJ9vNoGshM+haXBJ3LWQGXQuZ uGs5bMJhV9m3VJdLuFxOMRJEyMwXdbyoLrt0OQn4flhdPw3MOedqnsbVc3iY/Q1k0fUoowXr1wzv Gsz1sxaqSe0219eb7ajRaRJD7YIMz+Yzr27uvcFwuMYG0mmPV+x3uaXLG8P1iP8RBmaLvwnkckqX u+WRRx7YtOmee77LuTlX300XOiZ1PJHE1DjXiGDBA6aNOEzIuBzC5TgdH0diwOy7jBQpmA+UCCvC zClcHulKISe813TDKzRyQ4dNOmgpqmGKbrt0O9Hw+T3odc/zVGTs/Y1hLrJardEmFDVFHXbpoK13 QNPWu63CbUv4oh81HY71tOQaKlQP0YlpMJqmP2peRXcNOiRc0m2TbnJeE1K3lO5B7DWHSzq8z4p2 Dl4G8UBM3fFBNcS7hXsOZs1qe54nRVbpMD2U0xRucmk9aXXjM8lifdweEyaYyP3gfw63cHiy/dn+ yRrRcJwmjWIUBgKN7qSqcDLW3+sjd+uFs7rhrG5pcccjM6CwWoTFSo7mkNKB6ZK7ahYpLUin2IXH brUOcVlptXWnKNJtU5N8VuUnlDAuFFmBHrmtZrVKt70Zl9sp3e6Z2dnYEe9t2FjjIZMYpmHt1OvV TeoWdYv/++y7VwnT3Ezn5ZzpvGq/WcZj8veTmTrSMjIWLGgccDrjfgX/JQc2dkQfWarbJdxw4EEX roN5clR2SLeL7ZxcdYDG6Jo335jX/Hk85IF69pC7UUrrOhD32wG2l4Qba1yZ295/991mW2qnc+sz rInt1pfwZdbcEN88GyjrSNQdcHukOyWWG8tF+NvxgPoAvOhelbyJ+yB/Nhza7ZJuzzxzZvFrPoIh q6dZGs6dmDS8u6GhnudBrpbrI9zcDuF2Jtzbl5iHESYYybMd3ClokKkNanynTXJywzOs62HJHrv0 kEMme7nD9HIus57bzT1W4SE3T/i5A2UbyLk0HHfWD1X7dx3dY5Mehtf0dI+UnqS1+UdcnXs+T1+n uVZzDO393/Z1bJYeeKjmkRZP3Nn/q96eauiKezt5OT8adHfT3w0M4e8e9nePS3o8M/GWny0WiCxx k9gk7hH14GrN64WtDItlqX7fdc2bUPcB3w/Upphf5IpxGhur+WZFiNosbqea8H+zlMep+g2XTEtE AM6uxwSrYUcN1RQCnGYI8LiFx02/0k6UDvJrdRom5df8Hof0mP7AUcDjRH5s0JixPziW8u7+jUYc qN/Yz4tOccAMBIN5FhrPfJzI1fwCoIv7DT1arjZOcNGgpelJVnemFbLN+wZjBI+yPrHh11Ovg0EC o0iRnmGxtFjajowdGc0LmhdQ9LzHeY+z3sm9xrQdoGZQo9YAqgfdbYx1jMgfEjXmIz9GmLDwAYYH FM8bYYMHgKXA1LKchLbHITxJgcN3xlyTAxIvBkGP/7R0Xg5aFi+Ip1GPQV/rMyiD5rPD5/f5zXdu RBI4itchvS7D5+nosef5Ie85XGrBNes6Kr1ulvlGQ9EEpTbhtc0cDCdkAc7BeFK//gzl9fVG+E5A lKLo7uSQosa8dul1JsWUBq+U3uTl1Jwe6Ux9IdaqNiQRv/jEOxnyFsRDsDp9Iv7AM1iVYwu/DJmx RTMPtRTCEcER0O1+f78xt5ms1ugBOJBLnPPdKB5ijPc4CiqIMZ7k6ogLxhEZrofg0o8o46Uo45UW b+LsOSTMOKWFXgNFcpxJdQivw2KJRxoz0Nhs3cMMdUnnCr/KzzgVjzQcarzxUON1UKjxuqXXa4Sa bJGBYBOAjVOwuUbMiaWQQTliaVmq7/oFC16BZzQ2Nz7QvDnXCDds1QbGcZg9rqxAs2nEpzlf3QBT slLEOc3BwTty5ITs7AYdUYbLjZCDOkNjjtcjvJ5UkSq+xnSFdoWWG6vDTk6budcpve6B1tbWPQOt u3fvbh3wuvBgnAhruSKWRLl4Mk7wFE+L3XiLjiVdLdpu7bRgWzlN+QF+enrwwWmjHjcfp4X9hu42 s3luLBwbp3HhoE49uYOY14LFHfIAzmNPS1zbwjyR3a3t7Z29nZ3tra27qXdnUovT3lTp9XWP6R7T O2fvlM6SzpJXFrW372lqa9rt3e3l3rtjvbG9sU5QO6gV9HJsd6wl5vVIb8o4scbELE65sTUxYGIg yOAZQyMEB0Sr2M3UKiht5Fo0xmROUSzWXT0m1W5vr/Y6hdelD84k7QwcBq+gdpXgtTT6JqK1NFaV 1tc7THqHt9hb7Ls35jflNxW1F7XP6Jy+Yk51WlZaFr8hrW+12ze0tr5RleKUKW5SevDobrqOHjRe HIu4p6I5XK7gml3M5cWz6T0NA29txVrmzUmxyxT7nNzc3P5c8/JSeR0MqXV9bANabDizi927Uywy xRqLCZGYks+qp9iysoTIGry6UxwyxUWlrVjL3s729lazYdLl8krXsIPdH2e1DiF+mUz0Z7xaFnHa nJLdmyYST7xJtY8eJK10dO/sjvdBb5/Ve2ilvE3VdFyzD853Jis3OwI69MZJ/7iUL4hmgMaAXKn4 j8wrP614W8G26c/M6U3LTcvFS4DLubuoaE7anKKi3d5zt00DZQkexIA3LS0LSz6gWAF7Vm4sxWJJ SXIHAGpTpMWGccU0bDguG6EsCGjafZAb7hCpDrvd64WmNEKZqsakVdpwWDOU0gPTH3Nzs/ghp8yL ym2JdbBh/Z3tdKV4ZErKPGGMvUjMETNjJXAcChH5sTm5qXC64Y7utJlZacUlJT1wu/bO9nc73whz SPHD7cl9zCWJr4rXPbO6M+4POj9Y3wpjxASAg84OlirGiosA1UR0eh3cS9fsgohrb6AlWm9Hk9b1 LnrP8Jmx0Mc/uXaLnZYVQsmviZSIkcWRwtViVkkwWiYWoUTevPRqFdALXeefk9hFCt4tjJwUgFFc yM+NJxa8cwzDOC4Syg2BwAIxYemSG1WRdcvShSoOGEYd+l0Dn7iYcwp6GJ7QjrMVzhujzBwimrhA jBZfyw9XhMWjLJ9g+QzLXSxfZPny6sJImXiF5RssO1geYNnN8ijLHvpVGHGCpLSzHM0yk+XVLJez vLN0delquYHlRpabWW5l+TDLx1g+lfiNgb8n5XlKJ5BUgIEdCMM5gMv/v2cWrEPKP3wne6TfSaXf oqwXW8RO8RvxstgnDosT0iJcPFOnOdseQb8PrqDdSDi6pJ8/yVnGvXGjcf9pf1Ib2NvxnUPy0jsw NJ86cWh++Iih+Qu2D81fenpoPuOM8smjh+anIxRZkvNfJJXbhbx+ztD8Ivqqths2nSEC9Dv0aFMP qLIsAVFnedTyjtih/FT5qeiwRq2PiP22t+yNUnHf7A7KF9zfwzvIK16f91rLNd5bvQ9balIKUu60 /D6lLqXJsifVkuq07Es9lXrK8q6QWh9hY387Zdc5aS/oQMpHSXTMpL3noC9SL0lQBmgWKBt0J9O2 Myllb+rO1H/xbTVpRxI9QUSn2HOQe3ggQfcOfzBBfQaNGHMOygRNH7k9iR41iEvOoJG/GflKgt64 sBt0lOgi67loROZFIy7KuPjeJHqQ6eVz0t6Lv4xT2si00QnKNinnnBRgWm7eh5JmSqrXytSRIKP1 +2m9oyaPKhj18KjHic7UPuqpc5GhfdTzow6b9MUgUS+jvuS+NOKvLxo/K0GLxi9NUIFJd4K08XfS n5ed4L8089Ls8XdCZl768sRXLnub6YuMlaDwpImgKZMOT+oHH550evIrlz9MNOnw5S9efuzyY1Os U1KnjJzyW1BH5jxQIHPl1IdMeukK7ZsTv/nH6VtmTAfNuzLtypVXVs/8jUkvzmyd2TFrMmjmrI2z D861MzXPfZlpYN6MeU+atGvuAPJPzuvlXO9Vlqss8568aop/s//F+ZnXrgC9f/2quc1Gbdx7jVo3 zKN6NyzKuSQnK2dezuMLJzIFFt7JVL1w48KHIKsXvgbqXrRukbbo/RvDoK2Lc1ErsPiNxW8sfA3y IKVAhxf3LP5yicb02JJ2pveX9IDfX9IXsC7pQ3lPYGXgYODwTVHQlqUq6j22pM8oWbpuSd/Sj5Ye XxZY3rpixW0jbhtz28Ria/HK4s7iL+P3VVNAvynzlV0Srg7Xh2Phw+GecN8a65ppa7LXFK0Jr1m3 pnHN1jVPrtm1Zs+afZFwZEvk8ciJClExomJBRV7FixVvR6dH86IPVS6vbKx8qfKLKnvVlKrrqp6s Oro2e+2X1WOqr6vOrY5UP1T9VHVnzSU1/1Szq6az5st13nUXrZu57up1BeseW9d51+S7su+6/a5t dz1x18G7+tb7169b/2KtvdZfG6l9pra1dmDD6A2rNjy2oaduVl113VNa4Cti1a4z49HQaKNVDRLF Ef5nFJOMCPIVvpdzpscN9RPD0s8ZdeKRJ4mGxg6tdZAoOmgdg2TEBYqhvifSWi9+EHH4wLxeRE2O wXxHvB0eQHzdlrrTtzVlbyJmou7wvvEF1DZlV+q2wdhpoITonM3x16h1SerOOHr0lGIx1z1A5Vzf RBB6d6V8hEi+Ey0OsLa9GN1W3A8wDe4Ox87YFbKT9oHBnWAnjfus6P/EWdHfbcb8eznec5RnPWid mo30tngkxHo8bq4XYpMRf4z4Zq4jYiIiIK1aQSI6xlcUMS4tRztMLQbXePxS7bB2GNqo1hcoC4w6 PH7p2TaBONiRFFHPEWeT4+rZMdWM3K1sTUYUXRSPnxTX8QS9aj2jHseTpWmBGdMXv3GR1djH+I49 6+IvL+yGVY2I7z7xXWXEmIusgzuQYZW0t3FtK9VA25cvGkEl9IRq0fMRY1L2xi01bfSIMdgBR1B7 ShtPB/fR5J2UxsK7prlvJu2cI6DhzH3ywSG7415zZxwZHz3KvzR6p/4XBi7sTsvGeIagT6gRxlip JI+NY2x4IqFpWMr4AuCdQ6tJSKQFRm7n9X6c1ibJq2eNegpzje+wHYZWrSdN03oMoh7oPn4prQql DEuju9ZzaeaEaQYbO9yEabwrJRHtcMbuxvvjf5F4T02is2vwTptE5o6boLNb0E77jxHvxedNiR37 K+hMpIgS+/hXEO/s50182jhPOhMdPqMk0dn48dklicjujZX+x+hszX9/dOdHBs50dkndOdeec8nc gZQDdOphauYndjrpcK455xI6A5llIJygZtKpyXhKsZ9SRHw6WsEnKzpD9c7r5fMRTkdIvTy3mU8n WuIUQ/TYEm3xwSUanWA495h5zjHSj+EUdJie0ImG2i02iU88UT4boS6XPkZy1FOo/RidphAtJi4+ yOeuapMC/GQinbo4F1h8kOKSWQbCyS0LZzU6oVG7jZwC8TktzOc51OWTWuK8tjBwlYURGSAsbooa SMy183wwYmOkC19j3dTTRtbFeod64tkrmmwHl71t5ISdvhql3Ki/SF+Mou9F0deilJfElYK+SLKX v6hEqR7+0ovkLz5Z6JtO/EUnj/iVPiD26AMyV1wgg2KpzBOjZL5IlwViuFzN34+aTt9O4i8nSf5O khV1vag7HHW9qOtmfUf4+0guebsYg/LxKF+G8q+jfDx0XQpd6fQNI/5qkYe+PETfGlLWYxy1+r9i vLOUD/UfKR+JLOWImKZ8LC5XPtHfVI7hbZe07+VvDFnpe0D0NSD6FhB/CahaDBM5wgeeJSaJ2eAC /U1RCC4C01eLovoXohJcBV4LrgbXCK9Yp+8Td4HXg2vBG8DfRfsG8D3gjeDvgRvBm8D3gu8DN4Ff EFeL34L7kT4N1sUkKcASHBCz5U3gpeCbwbeAQ2KJbBXjMOOQslzMUW4VTuUOcIlopC+qKHcLVfmu GGv9mb7PugP8CHifmGR9C9wB3g9+G/wOuBP8LvgAuAt8EPyemGTz6W/auvV9tj8Jr60H6U/Bvfo+ u03k2Cfh/k0xyT4D9xL9TXspuAxcDq7UP7ZXgYGNHdjYgY19HRjY2J8Ws+3PgP8VfErMdkwW4xyX g+8Qkxy54DzwGnAEXAPWwHeDgZGjGfwA+GfgR8TVjl/h/in4OLgX/Dn4BPgUGBg688EF4EJwpRjn EmK2a6QYx7Z7lL/QRKlP+KtLF8Jqn4XVPgtrmwhrmw9rq4e13Qxry4O13QBr89MXkug7SMpyfTN9 CYm+g0RfQaJvICkv6Y8pH8LOjghFOQob/ETcynb2EX8JaXjCK24XU5P0L4D+Kui/FvqvpC8VQfeD 9K0i+lIRfaeIvlIEfS9C33KRCi2fQctn0OKDlsugpQxapkLLVGi5HFroy2Pv03eFoIm+1DSNvivE M30VqadFGnT8G3T8G3RkyDv030LPVOi5A3qmQ8/N0HOVDOl/gK6pcpv+PFr+Dvqs0FeFkRVB5wUY 2Xeh7T7lsP4FRvea8kd46yfiG8ox02OHQ+tkaA1B65XQei20ToDGDGh7i749As+7EbNcJjxmhPkr IglFlh+L7+o9ogF8D3gj+HvgRvAm8L3g+8BN4Nf0fvE6uB387+A3wH8A7wW/Cd4HfgvcAd4P7gS/ p+viffAH4G7wIfBh8If66+Ij8BHwCb1L/Bl+/gX4JLgPfArcj+j2F5R/Cf4P8AD4r+DTGIuu90gB lhwVP1RWwsL+Sf9MuR33XP0z6z69x/oWuAO8H/w2+B1wJ/hd8AFwF/gg+D3wH/V+6yfgY+A/gXvA n4KPgz8D94I/B58A/xn8BRhjsZ4G6/rrthH66w6/3u+4FpwDXgherH/suAX3ZeCVKL8VfDv4Dr3H kQvOA69G2RrcI+Ao0mvB1eAa5NfjruF+N3gj0t8DYx0c9+PejPsD4B8g/SD4h+Ct4B9B/8/wfCfS jyL9K6SfRvp3YKyRA2vkwBo5sEaOLl13HARjjRxYIwfWyNGNNofAh8FYI8cnepfjGPhPmEsP+FN9 r+M4+DOU9UL35+AT4C+Qx9o5+nA/hTzWyJkPLgAXYr0sYrMYyTuXIjbDdpfBhmn3siH3f5HLQe4G WPke5Q/iciHxtE9kwzK7YJldsMwuWGYXLLMLltkFy+yCZXbBMrtgmV2o/TEsrR+W1g9L64el9cPS +mFp/bCiHlhMHyymDxbTB4vpQ3/0daIu5TZhU4LgPFhQvv4hrKYLVtMFq+mC1XTBarpgNV2wmi5Y TRespgtW0wWr6YLVdGEl+7CSfVjJPqxiF1axCyvXh1Xrwqp1YbX6sFJ9WKkurEoXVqMLqPcD9X6g 3g/U+4F6P1DtAao9QLQPiPYB0T6g2AUU+4BiF1DsAopd7LEHhANYzocnO7H3/h5773PKXuy1b2IX wm7D+B7DDN/EDA8xvuuRo68/jgG+9dDwjliBfTId+2Q69sl07JPp2CfTsU+mY59Mxz6ZLuivuDeB N4sZ2CsnYK+cAJ/tgM92wGc74LOH4LMn4bMn4bMn4bMn4bMnsZ+OgM8egc8egc8egc8egc9ivcVC 7JvT4aeH4KcfwE8PwU8/UPLERCWfvuooGrCPjsM+Og776Newd6Zj70zH3pmOvTMde2c69s507J3p 2DvTsXemY+9Mx96Zjr0zHb54BL54BL54BL7YAd87CZ/rgM91wOeOYI9Lxx6Xjv0tHftbOva1dPjK Eext6djbJsBXjmB/S4f9d8D+O2D/HbD/Dtj/Idj/Idj/Sdj/Sex/I7D/jYD9H4HNd8DmT8Lmj2AP TMf+l479Lx37XzrZu34CWJ/A+Wyzfg9WYAHi+SHE80qsxAKsxD+jtAnWfq2yDyepDv20sl/k8ep1 ofYB1OrEjrlZ34BcHtruQ9u38NSPtpvRtg1tc9C2A+2+I+ymH30bNfejZgdq5vD5imzmF6ypEOVX ofwNlL+N8tnQtAmlz0DT1dD0GjRlcf13+Zz4Pss+4ZbDxDi5ElwCLgWXg8PgNeAIOAq+Fzv9cPoO HX1zjr44R9+b47PRDvGfvN17fNx1ne/xX2bSJE0mXEppgYJQLuUiF7nLRRTRCipFdGURV8zuChpE ZMEC6hZag7AKWC4CRajgUqFF2yqxIGJDgZa2KSnpJZempUmbDkmmkzRJM5NpCn73ObORg55zHuf8 c84fr53MzO83v8/n/f58Pt/vbyyzE+MvR2fGX+X/9ugoq/aX7BLHWbkPsUs8Kt5tMvSIIOW1ndGZ 1vObwqvOmGBPeWR+TXf+9dElVrCr1PxXo0viVxd2X5dE+4hsksgmiWySyCaJbJLIJolsksgmiWyS yCY5c7wzb3DmeGfeUDiz0pmVzqx0ZqUzK51Z6cxKZ1Y6s9KZlc6c4sxTnTnFmacWzkw4M+HMhDMT zkw4M+HMhDMTzkw4MzF65hmjZ54hk69GJ/jrhILGtYU9wnD+N+byv9OEy/FFfAn/EJXbu5Xbu5Xb u5Xbu5WPzf/vtMX5X4vL//LZ6E5jecGjbdHGouPC9qLjcQI+jBNxEk7GKfgITsVpOB1n4EychbPx UZyDc3EezsfHcAE+jk/gQnwSF+FT+DSm4jO4GJfgs/gcPo9LMQ2X4Rd4HE/gl3gST+FX+E88jXn4 NZ7Bs5iPBXgOv8FvsRCLsBi/w+/xPGrxByyxW1vm8dXQVvQaXsdyrMAbXl8ZmopWYTXqsQb5X61r wFq8ZQdxlbuVq0Nj8Qo7iTewEquwGvVYgzfREJqK1+Kt0DRm/7B9zHgciAmYiINwcNheMhuPgQYl vwzvlDwTdpU8i/lYgOfwB6+/7tFus2SFvxtDU8kGx7f6Oxu2lx6GD+FwHIHJYVfpkTgKR+MYTAlN pcfiuNBWejzUQqlaKOV76Wmen+6988I7ped7/GLYVRYL28viKMYYlKAUZRiLclQggUrsg32xH+Rb Ng4HQN5l8i6Td5m8y+RdJu+yQzAJh0L8ZeIvE3+Z+Msm40gchaNxDKaI6bTwTtnpOCc0lZ2L87z2 CUzFZ/B1x/2Lx2u9903HfQvVuA7TvTcDt+MOzMRsrz/t+GcdPz+0lS3w/DkMei0Tto8tglzHHhCa xspj7IHhnbFHqKEfFn4ZkTpF1CmiThF1iqhTRJ0iZxRRp4g6RZQp/H7i/hiHAzAeB2ICJuIgHIz8 Lyzmf1/xcByByTgSR+FoHIMpODb/653uso/HCfgwTsRJOBmn4CM4FafhdJyBM3EWzsZHcQ7OxXk4 Hx/DBfg4PoEL8UlchE/h05iKz+BiXILP4nP4PC7FNFyG/G9DXo4v4kv4B3xZ3FfgH3ElvoL87zre jvwvO87ELPwINbgTP8ZduBv/AfcbhV+ZfAAP4iH8HA/jETyK/O8uPo4n8Es8iafwK/wnnsY8/BrP wApYNB8L8Bx+g99iIRbBrC0ya4t+j+dRiz/kf+My/3uTeA2vYzlW5H/tEauwGvVYg7+fIl8O/5z/ DUzrwL4m//nWgX1N//yvPq8rNvGKTbxiE6/YxCs28YpNvGITr9jEKzbxik28YhOv2MQrXuQeZTF+ h9/jedTiD1iCP4be4pfwJ7yMP2Mp6vAKluFVvIbXsRwNUaJ4Ld6KEmP2j8rHjI8qxhyICZiIg3Bw VFFyb+gtuS+kS2b7+xF/zwldJY9Zk3hQmGZPeU8uJb/2nphLxFwi5hJTumRx2FHyOzzvvVrkp9wL jn/Ray95/0942fM/Q5wl4ixMv5We13tvjcc3vdaAtXgLjVGiZINru7crcW9X0uy1ljBcmJRtYnM/ V9LlXPcsJWl/212X2F2X7IJ7lhL3LCXuWUp2YwgZZOU2HHaU7hN6S/fFftgfB4Xh0oNxCCbhUBwW lZd+CIfjCEyJEqXH4jgcj1O9dprH02GVLbW6/vfUjRJlsaiiLI5ijEEJ8v9AuwxjUY4KJFCJfbAv 9sP+GIcDMD4qLzsQEzARB+FgHIJJOBTiLBNnmTjLxFk2GUfiKByNY3Bs6C37sHu0E3ESTvbcTqHs VH//dRKf4e+zcDY+inPkcS4+7+9L4T637DLnfSEsL7scX8RXwnDZ18V5reP+fkq73y1zv1t2K2aI 4XbcgZmO/4lr6//C1H7E4xyf+xh+gcfxrM+bj79O8d94jYdlGefuDcNjo7BjbFH+vyoK6bH0HFvu cX+vHxAlCpPdCjV2otcOwsEwj8cemv9eMt/po/uqGflfky3s0V57//Ub8r/iWvgeJb/f6ovGxC4O /xS/NLxud1qe/27Le73RibGPhFTsDJyNj+PisC52SVgT+xwutSv/cthqd7HF7mJL+ZVhTflVuDuk yv8DP8FPcQ/uxX1wL1c+G/fjATyIh/BzPIxH8Cjm4DH8Ao/jCczFL/EknsKv8J94GvNCKvHhkIri Is3GrnRPfJN76PPEnxF/JnZuSIo/E7vI40/CtthP3bt8NTrJ/DrJkWvKvxSS5f+AK/BP+Newrfw6 XI8bcCO+h7tDRm4ZuWXklpFbRm4ZuWXklpFbRm4ZuWXklpFbRm4ZuWXklpFbRm4ZuWXklpFbRm4Z uWXklpFbRm4ZuWXklpFbRm6Zis+GbRWfw+dxKabhMnwBl4dtcs/w8OzQwqE3YwUfw6rCN4eHy32+ vOfHvhoWxb6B7+AnYRkN8r9m3Cb3+XKfL/f5cp8v92VyXyb3ZXJfJvdlcl9WfltYVP59/BCz8OOw SFzLxLVMXMvEtUxcy8S1TFzLxLUsupAD1RyoFlsnB6rFN6yChlTQkDjbRdIqktb4l/8yFL/yLxmr SyVnTrG6VHLnlNF7/OWqa0h1DYmuVXStomsVXavoWkXXyplqzlRzppoz1Zyp5kw1Z6o5U82Zas5U c6aaM9WcqeZMNWeqOVPNmWrOVHOmmjPVnKnmTDVnqjlTzZlqzlRzppoz1Zyp5kw1BVop0EqBVgq0 UqCVAq0UaKVAK2eqo4uoUEWFKl6spkIVP1bHLo4Ok/002U8b/b71ntH76ROoMIEKp1NhAhVOH/2W +Cu8Ws2r1bxazavV1JhGjWnUmEaNadSYRo1p1KiiRhU1qqhRRY0qalRRo4oaVdSookYVNaqoUUWN KmpUUaOKGlXUqKJGFTWqqFFFjSpqVFGjihpV1KiiRhU1qqhRRY0qalRRYxo1plFjGjWmUWMaNaZR Yxo1plGjKipVC0MyTsj4ARnfIuNxMrxdhrdGB9NoOX2W06aZNs10GEeDcd59SP7L5b9c/svlv1z+ zfJvln+z/Jvl3yz/ZnE0i6NZHM3iaBZHsziaxdEsjma9Uh2e/bt5NxSdFLvcjLsS1ebcdWbct3E9 fLaIO96fdTPMjDvCmoofhlTFv2MGbscdmIlZ+BFqcCd+jLtgNlaYjRVmY4XZWGE2VpiNFWZjhdlY YTZWmI0V5mKFuVhhLlaYixXmYoW5WGEuVpiL+4xFOSrMvPxkTxViz+jxpB5P6vEk3fL36VO8u17v JvVuUu8m9W5S7ybFnhF7RuwZsWfEnhF7RuwZsWfEnhF7RuwZsWfEnhF7RuwZsWfEnhF7RuwZsWfE nhF7RuwZsWfEnhF7RuwZsWfEnhF7RuwZsWfEnp9ZV4ZN1H6Twq++P7PyGbVHp8mo1vvbvT/MjXe5 8S433nVsu2PLHFuhU8plerJOKZftyaPfAb3BoXc59K4sa2VZK8taWdbKslaWtbKslWWtLGtlWSvL WlnWyrJWlrWyrJVlrSxrZVkry1pZ1sqyVpa1sqyVZa0sa2VZK8taWdbKslaWtbKslWWtLGujM2VS w5tVvFkVq44O5c8qGfyrDtijA7IyuVMmE0e/mZmY/2ZGJo/mv83i3SrereLdKt6t4t0qWdXIqkZW NbKqkVWNrGpkVSOrGlnVyKpGVjWyqpFVjaxqZFUjqxpZ1ciqRlY1sqqRVY2samRVI6saWdXIqkZW NbKqkVWNrGpkVSOrGlnV6OMrC338UVm8Nfq/OU0V9UOifj6qkG+DfBvk2iCvA+V0oHcelk+DfBrk 0yCfBvk0RCWx6Xy9JeyJ3Rreid2pLu4LfbGH89+0e3UkdmfIRkX+757oeEdkY7epiO/jztAUuysq i93t7HtDd+yR/G9ph72xx8LeCvvbCvvbisPwIRyOIzAZR+IbjrkG1+Kb+BaqcR2+jevxHdyA7+JG /Btuws34HqbjFtyK2/B9/CDsLeQzItLO2IzQJZcdsZ+HXTF3etFVsZtU+82Y7tXbZPl93BEaYzMx Cz/CndGBsbvC4thsx90fOmIP4EE8hDnhJfm9VBELb1bEUYwxKEEpyjAW5ahAApXYB/tiP+yPcTgA 43EgJmAiDsLBOASTQh8N+2jYR8M+GvbRsI+GfTTsqzg3NFach/PxMVyAj+MTuBCfxEX4FD6NqfgM LsYl+IY8rsG1+Ca+hWpch2/jenwHN+C7uBH/hptwM76H6bgFt+I2fB8/CC9FxSpnKxU3UHFb7JEw oJbuDIPqZDj6AhdyXMhxYIQD+QrbZsXJWnGyjshSOUflnBUma4XJWmGyVpisFSZrhclSP0f9HPVz 1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9EeqPUH+E +iPUH6H+CPVHqD9ilcta5bJWuaxVLmuVy1rlsla5rFUuS90cdXPUzVE3R90cdXPUzVE3R90cdXPU zVE3R90cdXPUzVE3R90cdXPUzVE3R90cdXPUzem5W1R3vhdn0PR21X1ntA+1O6m9ndq7ohtpXEfj OpXe7chVtO6kdWfsB57PCD3OGlT5aZWfVvlplZ/mw3t8qONDHR8GYj8LK3VAiw5o0QEtOqBFL71p NrzBoyYeNfGojkd1PKrjUR2P6nhUx6M6HtXxqI5HdTyq41Edj+p4VMejOh7V8aiOR3U8quNRHY/q eFTHozoe1fGojkd1PKrjUR2P6nhUx6M6HnXyqJNHnTzq5FEnjzp51MmjTh2S1iFpHZLWIWkdktYh aR2S1iFpHZLWIWkdktYhaR2S1iFpHZLWIWke1/G4jsd1PK7jcR2P63hcx+M6HjfxuInHTTxu4nET j5t43MTjJh438biJx008buJxE4+beNzE4yYeN/G4icdNPG7icROPm3jcFFVzMMnBJAd38/s1Lu7i XBvndnKuj3N9nOvjXB//E/x/nntp7qVj93jtPk7PDgs52M3Bbg52c7Cbg70cHFAnS7nYzsV2Lqa5 mOZimotpLqa5mOZikotJLia5mORikotJLia5mORikotJLia5mORikotJLia5mORikotJLia5mORi kotJLia5mORikkt9XOrjUh+X+rjUx6U+LvVxqY9LfVzq41Ifl/q41MelPi71camPS2kupbmU5lKa S2kupbmU5lKaS+1caudSO5faudTOpXYutXOpnUvtXGrnUjuX2rnUzqV2LrVzqZ1L7Vxq51I7l9q5 1M6ldi61Rx/hUpZL2UI3/rcLQ1wY4MIAB7IcyN83DVB3gLoD1B2g7gB1B6ibpW6WulnqZqmbpW6W ulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpW6WulnqZqmbpc4AdQaoM0CdAeoMUGeA OgPUGYhOMBneNRne1f1p63l57B5Z3CuLQvT+fgRzrPePWbcn2dUdisPwIRyOIzAZR+IbjrkG1+Kb +BbsIGk9TOthWg/TepjWw7QepvUwrYdpPUzrYVoP03qY1sO0Hqb1MK2HaT0cfYvW3bTuFnFaxGld kNIFKV2Q0gWpgv5/7QC6/0+Vbwcfy3+z8b+v9m5+dPOjmx/d/OjmRzc/uvnRzY9ufnTzo5sf3fzo 5kc3P7r50c2Pbn5086ObH9386OZHNz+6+dHNj24KpimYpmCagmkKpimYpmCagmndkNINKd2Q0g0p 3ZDSDSndkNINKd2Q0g0p3ZDSDSndkNINKd2Q0g2p/4tuSHEoxaEUh1IcSnEoxaEUh1IcSnEoxaEU h1IcSnEoxaEUh1IcSnEoxaEUh1IcSnEoxaFUYY3vL/yvkGfxKs2rtGmTNm2StE/TPq9xmsZpGqdp nKZxmsZpGqdpnKZxmsZpGqdpnKZxmsZpGqdpnKZxmsZpGqdpnKZxmsZpGqdpnKZxPse0HNNyTMsx Lce0HNNyTMsxLce0HNNyTMsxLce0HNNyTMsxXZGvhem4BbdCvckxLcd0tJ9ZnPnbnlFp9xQ6PWum Zv9PPWLvfos9qjtT3ZbQbSW6bZtOO1CnlUfT3p8o063GM3C7+/I7XesnoV9l9zs6pzf7rc5DzjqZ wlkKD31g19SvuvtVd7/q7lfd/aq7///TtOlXff2qr1/19au+ftXXr/r6VV///9NdUf5uJUeple/f twxF8dHXclzaG32ZtvW0redfL/96aZu/s2njxBj6dtG3qzD/Znv+c/cID9spzfHaY6GLrl107aJr F1276NpF1y661tO1nq71dK2naz1d6+laT9d6utbTtZ6u9XStp2s9XevpWk/XerrW07WervV0radr PV3r6VpP13q61qupXjXVq6Z61VSvmupVU71qqldN9dK9i+5ddO+iexfdu+jeRfcuunfRvYvuXXTv onsX3bvo3kX3Lrp30b2L7l1076J7F9276N5F9y66d1Xk85yOW3ArbsP38YPQVdB4z2gn5KIDYkui CbFX7ThfU5evh5mxlWF+bLd9RibMju0JjXGTM36Su9dTwuL4GSH5/r9WviLaL/6Phf8PY/l/U9id 2BzWcmyez12E13TA62FjbLlKX4GVrrnK45qwObbWne5GV2vy2IzuaGysR6dm7HGzdkLDGAkD8Sh0 xEtRhoPd/Z8SOuOnht3x03A6zgzZ+Hlhe6IqpBPXhIbEt2FGJL7r8cawOfFvMBMSP/Q4w+PtsIdO 1MCKmbgPujIx2/sPec3sSzzq+Rw84TPmhT2JBT5/MX4Xdid+j+e9Vuv5Sx7llGj02jqsR4vnrdjs 7y3ocFxv6EjsxnDoqBwf+ioPxAS4O6x0d1h5tNevCw2V9vSV4qq8OwxV3hd2Vz6Mx/B06Is+O6pq G59yVG2hai9Ve6n6LlV3ULWVqi1U3U3VFqq2UDNLzUFqDlJykJKDlByk4h4qZqiYoWKGgr0UbKNg CwVbKNhGwRYKtlKwlYJtFGz9OwXbKNhLwV4K9lKwlYJtFGyjYC8FeynYQr1e6vVSL0O9DOV6KZah WIZiGUplKJWhVC+lBik1SKlBSg1SapBSg5QapNQgpQYp1TKqVBuleimVoVSGUhlKDUZHxp4LP4wt Cb+jVJ0a3EuhZ6iyM7Y1fFOdTY/1hCdV9xWxITvtPeECdfZGPB6Wx0vCz+KJcINqb4qPD5Pjh0fX xo8J31P5R8ZPDp+k2tOqf6qaezx+Qbg9fmH46ui/zmqP/2N4Kn5luC5eHZbm//2SrP5kJr1qlXgd K8PbrvgOP7a6YtIVenxqv0/c7hN36aXz9NLH3BE+x7FXwzpn5fvlzUKPdEcfcvZ6Z6525g6xJcVW 4RM2FvrhjLDRma+G1c56x1kvOOMAZ2xzvfZC/7qrLvTw4fr0JM9PCVud1SHK5dFhKmt34czlKmsF VqmYNc5eq6o22kU2eWwOO1THDtWxQ2XsUBnbVMY2VbFNVexWFbtVxW4VkVMRORWRUxHbVEJOJeRU wg7O7eDcbq7lJ393tI94SkQ+z/Wec90/yvUlrAojdN1Cz2TitpD1+YM+f9DnDyYe8/yXIetzBqNi Zw2J/CZnbM/XvZ3wc2bJErm8Hhq9ujm2zhzJa7g1pOi2zue2+NyW6EpXne3omXqqs1AtfwwzXH2G MwcoMUKJEZ/QSYlAiaHRvhqixFCsNSzyibUqqTGWVj3lGB+uiU/gxkQchKPCzfGjcUzYGT+Oz8fj JO7RPf5x719Y+LfLp4rmVL3XSd0h6g7pvU4KD1E4UDjovU4qzKB0oMRsSsymxGz910ntEWqPUHuE 2kH/deq/TqqPUH2EWjMoP0SxGYmFJtEivBxuTiz3+CYasBab0Ia3vdfucZvP2B5urozCG5VjwqLK EpRisudTcJ0JNSvM1oOd3BypfCRsr3wUc/ALzA2LogoVOagat3P6dNPnPdPnPdPnPa6frdPf0+nv 6fT3dPV70aH8yHuZpX0/7fudVWJGDZhRA2bUgNyH5D4k9yF598u7X979cu2Xa7/5MmC+DJgtA2bL gNkyoL4HzJYBsQ6Js9+sGDArBsyKgaJyV5ylAh7h/jLuP8j9B2NLOVqHV8PK2HKr4gqsDE+rgr2x 9V7fqLZaw/TYpvDnWBs2YwvextZwd6zd43Z0+swdHpPoQnc0S7XUxlL+3om0yuv12Idd4eZYPwb8 PYjdodpsajS5W03uVh18hRm1NrbXe+/ivbA09hePwSpchBjy86tYtY3xd4k5VR5mxiv8nQjfKcyz fT3uh/0xDuPDear1YtV6sWq92Np6V/yQcGt8kvcOxeHRV+KTPR6Jo8y8o3FM+Kf4FM+PxXGeH48T /H0iTgoXmZH/bLIs5Nosrs3i2izVfql5eV/8LMecjY+GH8XP8Xguzgt3xM/3+DFcEL6mKy6Of8Lf F4abdMYVo/9idqEOuTV+VXRQ/GpUh7fM198mqkNj4jrcGPbqkr065EEdsleVzFIls1TJrMQs7/8I /4Gf4Ke4N5qQuA8/w2zHP+y1R/Co53PwmM953PNfenwyfCfxKzyNeeGuxK/DrVazOxLPef4b/BYL w1RdNdUKd4cKnKUCZ9kf3GWVuyPxh/CjxBK84LiXvPay4/7s76Wo8/pyz1d6fZXPrffaGrzptQas RaPPWof12OD4Fse2YpP32mB6q+5ZunZqYmv4s86dahW9Q/derHunJjq9pgYTajDxDtRhohs9YVlC HSbUYSINNZjYhX4MmACDyPo7F5Ym9mDE3+9BzSXUnKkws1LdVaq7ynhYWlnscUyYbkpMNyWmV5Z5 Ptb0KIcarEyEZZWV2Mff+2I/r++PcTjA6+NDq5W+1UrfWjnR5x3kmINxCCbhUBzm2MO9fwQmu/6R XjNhTaOZlXeERh0+q/LuaEIlryt5XcnryntwL+7z3kPhVp0/y6SaalJNNammmgKzTKuplY/7nLni ftJnPu3z53n+azyDZ8PN0WRT4iZT4veFlfm1wnq+wiTo0vGzdfbXdPYSXbtY16625mZ07Cs6tlNX rtON9bpwqS7coOs+rbOu1kmLdcx9OmaFjunSJQ/rkg26oE71/1r1X6b6l6n+/H+pcJaKfyv6F/Nq gUh+a8VaH1tslVpiJvzRay/hNevc695bHppNz2Yr1zIzq9fKtcQa2CvaHqvXEqvXEvNrnshXmFM9 Il9rFi0Xdat5s9282S7yLvN6o8h3mdkbzeyN5sly0S80CxaaBQtFuVeUX8zveaxe6xP/bNJeE5ZY wZZYwdZbwZbozV692WsFW68/F+jPXv25QH8u0J8LrGDrE3c678e4B/eGZlO92VRv1pu9VrP1VrP1 JnyzCd+sNxdYzZbozQV6aaG6X6jOF6rpHuvJRuvJRnXbY03ZqFZ71OlydTlPXc5Tl/PUYo9a267W tqu17WqrR231qKvt6mq7ulpuLdqoppZb4ZaoqQVWuPVWjmb1MU999KiP7XaQS9VBHV61Q1sZ/kjp HVaHdWrhk6b5FtN8i3pYQ9UOqjZStVFNvGhyb6XsKpN6C2VXUXaV2tipNt4xjTeYxhtM4w1q5EQ1 MmzKtpmybWplkzpJmqwNJmuDydqgZppM002maKvJucFEXGcirqP6DqrvoPYOE3CdCbjOBFxnAq4z AddRdoept87UW2fSrTPRWk2xNlOszRRrNcUaTLEGE6zVBNtkgm0yrTaZVm2mU5vp1GY6tZlODaZT g+nUYDptMpXaTKW20anUYBq1mUatptEG7qwyWbaYLFu4tIpDq0yXrabLVhNkq2mxxbTYYjJsMRm2 mAxbONXIqUZONZoKW02ALZxq5FSjzt/CqVU6f52OX6fj1+n4dTp+nY5fp+MbdHuDbm/T7W26vU23 N+j2Nt2+hYuNunyLLt+iy7fo8i3uibvtjvP76jPCu9GZuix/n/VtHTVHR83RUa/xeaau2cPXZ/ha y9da3ZLiaydfF/F0EU8X6YicLsjxYiYvZuqAHD9mqvicKp+jyueo8jm8mKnKc6o8p8rnqPI5qnkP vRbRaZFq3kOrRbTqpFWnqt5Dr06VvIc+tfSppU8tfTpV8x7VvIdGtTSqpc8i1ZtTvXNU7h4518rx 9XCfih2WwVLPdos9E55Tm1ujQ2S227OkzHpk1iOzflk1mAMpmTXIrEF0u0XXILoG0e0WXYOodoto t4h6RNQjoh7R7BbNbtH0iKZHNA2iyN/L9kSHu1LGlTa5UtKVkq7UTcP8PWqjqw25WqOrNbpaxtUa Xa3R1TKu1kiLQVoMumqGFoOunHHlpCsnXTlJi0FXz7h6xtWTrp509UZXz98fJt0jbDUvd4e3ZP2W Kw+54haz7CUTt8XEzd8fvFiYuCWOGhq9h0qN/jdMp8SvjE4rKNfhnS3e6Sg8y9/b7S3oOGb0rEHP 0j6/2ecP2A232tOmKTwiz3JKRBhjT1qCUkz2fArmhn6fsbXgzDpHb7aK5GMciqb4jBXe+SP9Bn3W nxzxzl/v7wvrTWS+lKIM5eFPsrpcNv9Kx0E6bqXjVjrm76+30m9QDH8SwwoxrBDDClr+7X33JBz6 gfvvyY4/Wi9O8TjX8U96LX/PXSTnvmii+AbENCCmnWLaOfoNzi7R94hrl7h2iWOXOHaJYZdrD7j2 gGsPuO5O193pujtdb6fr7XStXa4z4Bo7o6N9+suyf0Pmqz4wZTfSeaErZQtTtbzwL0V+POrlJtlX 5/9Fz1+nj4xXuerLrvqyq778v5w8+Ukz2XH5KTPFY35izHXs30+MsYVVdLd9wB731iV8/XK4cfRf d7zlyl8p/IvR08S91ZEvcq3BfUGz+F+h0uIPTJD8ytBKqbm8zq+771BrLrXmyucVn3qPT1vExQZ7 t2YKzqXgXE42UHGujmjVEa0cbZDfK7qiVY5b5bhVjlu52mAP1mwP1my/1fx3k6OVyw1cbnh/ckz2 GUeHuXJ/Rd5budxQmB6TqL6Z6psL30ZkTJE94XVR91J+s4h7RZz/DqeX2pupvVmUvSLspfJmKm+m 8mYqb6byZipvpvBmV+ql8GbqbqbuZupupu5mXZUxdUesfqpHhWXCK1HMKjhip7QnituNrPRswLOu aLJnfe5hcvYnffYnfVbKYSvlsJVyePQ7wpQ9S799fM6Kl7LSpax0w1a6Yfv1nNUuZY+es6/osyfP Wd2GrW7DVrdh++6cfXfOyjZsZRu27+izsqXsPfqsNMNWmmGry3A01lq+RyRPWLv7rNn5fd07rtrH wac5+HRhqoy12g/Fx5skJ4W0DHoclY6fGe1rwrjniU51ndao2Ofs8Dn571xz+QxknCh8g5DKH0+J 8frpzJDzev5bWUc4b3t0oGf57IdkPyT7oULmV9krXB2aPpD5kMyHClk3elyH9diMLZCdzIZkNiSz oegIV1tL3wx9W+jb8sE7c9dOu0qSthlXSLpC8v278ecL3/glaZuhbQttM39zh97ieWvhW8DCnTpt W1w9SduWD96tR0Uyz0RHxyv9NT48abfUZ7fUZ7fUJ6YXxPQCtTJ2TD12TPlv13rptNPOqI8D73Lg Nxz4jfvIce4j8/86Mr/r6bHr6RHXC3Y3PXY3PXY3PXY3PXYzPXYzPeJ5wU6mxy6mT0wv2FH02FH0 2FH02E30RKWi+b0r73bFnCvudrU9rrbG1dZER3l3G926xLhJjJscmR39Dvt/OHSmnd156vpCOswL XTQcoeHI+y4977Vaz1/y+LKd1kqPH3StxfNW/NW9tx3T4fjtYdPfuDiBah1U66BaB6U6KNUh7vbR 76Q6KNJBkQ5qdFCjgxod1OigRgc1OijRQYkOKnRQoYMKHVToiA6R59tyfFuOb8txlxw3ynGDHDfI cYOdar7qNshng11lyq4yJZe37SzzFbhBLhvkssFOMiWPDfLYII+35fC2HDbIYYMcNhT+K8qj4l+P jormRN8Ij0XX4FrcHJ6KfhAeiH6If8cM3I7OMCfagSQGHbMn3B+NYC/exXvh/qLjQmPR8TgBH8aJ OAkn4xR8BKfiNJyOM3AmzsLZ+CjOwbk4D+fjY7gAH8cncCE+iYvwKXwaU/EZXIxL8Fl8Dp/HpZiG y1AdTSxaFl4pejW8WPQaXsdyrMDKsLRoFVajHmvC0uInwwPFT+FXaPB8Ld6CXIv/ghDuH7NfeGzM uDBnjF32GLvsMXbZYybiIByMjvDAmLRjetEfHig5Hmfh+vBYyXdwA76L6eGpkltA95LZobGkMSwt ccdTOiUsLT0Wx4UXS4/HaTjd8/NxVZhT+lVcHe4vfRTz0OH5NmwHz0p7wlOlKezy3pDn2XB/WSw0 lsVRjDEogZ1imZ1i2ViUowIJVGIf7Iv9sD/G4QCcE5aWnYuv+/tajzM9PutxfnixLBMax/qssQfY H38tGhfWRgfA9IsOxARMxLE4DsfjBHwYn8PncSmm4TJ8AZfji/gSrsBX8I3whMp9QuU+oXJvj74X 5kbTcQtuxW34QZivmuer5vmqeb5qnl/807C2+B7ci/vwM8zG/XgAD+Ih/BwP4xE86byn8Kswn+tP jGkJa8dswdtoR4fX3/HYhbT3e9HvtffC2pISlGIsynEQDsYxmAI6lNBBdcwvOcPjWR7P8/gZfA1X 4+uowvXhCZXzhMp5QuU8oXJuVzm3l8i3RL4qaH7Zd/PaRA+ExuhBPISf42E8gmfwLOZjAZ5DPdbg TTRgLd5CI9ZhPTZgI5rQis7wvJnwvJnwvJmwOtqNIWSQxTD2hMXmxGJzYrE5sdicWFzcHRqLe5DC TqTh7qS4D7vQjwEMwh1L8RDy5/0FISzWb8+XmgWler9Ur5fq9VJ9/l/EnQl4FEXeh6urerp7enrC FcJ9Xx7rgevqikdcN7oegLKKoiDggotgotwCISBeICinciqoIKIooPHiEA/Wc1UEBhgGgtyEEDuK 3AlT39tN3E9XXd399nm+5Hnt7uq6urqq/r9fdpmx2+uP7Rs4doRbyNMZuurF9p1cD4RBcA8MgeHw EIwG1pvNGNmMkc0Y2YwR62mx/QzHeRwXc1wOjIPNONiMg804sNZeYa29wlp7hbX2CmvtY9bax/Z+ KIUyyh4knfFg3S02zhSmqCYiYAXfdhN8HQVEIfj07hh44fc5VxMZ0EZkiQuhp85njuczx/OZ44OY 432Y432Y432Y432Y433EUGoYpvOY53nM8zzmeR7zPE/cL6qIB+BBeAhGwxh4GMbCOHgEloqGYhns 1MN4o8N4o8N4o4/xRhfwRhfwRhfwRhfwRheI4BOkj+kC3moBb7WAt1rAWy0wZur1xix4AmbDHHgK noZnYC7Mg2dhPjwHC+B5eAEWwovwEiyCxbAEXoZXoBBe1evl2aKKbC2y5Lkcs+FKnS+v0gPkNdCB 6956lOyjc+WdkKtz0WzXqM56ILrtGtWN40D9iRqk16gvREStEZlqHap3Pa58g3DVTr1A7UKL7Ban qD0c9wafDcRxv6huDhTVzEEwGO6BITAUhkE+DIcCGAEjYY7OY7/IY7/IM9eKKuY6SMB62AAbIQmb IAWbYQsUAePJbC9gthew1+RHqun1zPph7DF5kf3CZX/JZ3/JZ3/Ji5SLapYC5pZVHWpAMzhV51mn cWwNvxVZ7Cl51vmc5+p89o989o989o989o9B7B+D2D/6sH/0sZhL1jBgLlkz9HprZvgv6NfbDaAh NILG0Bra6wWstGGstGGstAK7n6hi94d7YRRMgmmkz+H4tGjIaiqwF3K+jfzbYQcw51g5j7FyHmPl LGDlLLC/ElHbhzLyH+Q+848VVGAfEVWcTL3eqQlZUAtqQx2oC/WgPtBXh7469NWhr04TaArNoDm0 gB7U1RNuhwKuR8BIvT5q6PVuJz3AvQUKdK47Elg3LuvGZd24rBuXdeOybtxHYTxMgInA87qTYQo8 Bo/DVJgG02EGzIRZ8AQ8CbOB8XGfgqfhGZgL80SVWD4MhwIYASOBsY0xtrH7gPUdY33HWN8x1neM fsboZ4x+xuhnjH7G6GeMfsboZ4x+xuhnjD7G6GOMPsboY4w+xuhjjD7G6KN3uqiSEQUXYuwPUq1m pexkNwrOgs8eqSXvYTfzwm8XsMAGB6LgBt90FH7fUfAJ9l7wFSIogBQKIIUCSKEAUiiAFAoghQJI oQBSKIAUCiCFAkix89Vg56uBEihBCZSgBEpQAiUogRKUQAlKoAQlUIISKEEJlKAEStgle7FL9mKX 7CXu0L7oDX3gTsiFPLgL7oa+0A/6wwDdmx21LztqX3bUvuyofdlR+7Kb5rCb5rCb5rCb5rCb5rCb uuymLrupy27qspu67KYuu6nLbuqym7rspi5xdwtxdwtxdwtxdwtxdwtxdwtxd4sI/t6xAJ6HF2Cp qMPOW4f46xN/feKvT/z1ib8+8dcn/vrEX5/46xN/feKvT/z1ib8+u3U/dut+7Nb9xF68bDHsgxLY D6XwFfhQBl/DN3BAT2Nnn8/OPp+dfT47+3x29vns6kPZ1Yeyqw9lVx/Krj4UTZ9E0yfR9Ek0fRJN n0TTJ9H0STR9Ek2fRNMn0fRJNH0STZ9E0yfR9Ek0fRJNn0TTJ9H0STR9Ek2fRNMn0fRJNH0STZ9E 0yfR9Ek0fRJNn0TTJ9H0STR9Ek2fRNMn0fRJNH0STZ9E0yfR9Ek0fdK4TmQZHeDPcD3cADN1gkiU IBIliEQJIlGCSJQgEiWIRAkiUYJIlCASJYhECSJRgkiUIBIliEQJIlGCSJQgEiWIRAkiUYJIlCAS JYhECSJRgkiUwEsU4iVW4CVW4CVW4CVW4CVW4CUK8RKFeIlCvEQhXqLQ+FS4xmfwOawWLlHMI4p5 RDFPtgn+jSrHP3K8Uo8kmrUnmrUPo1lnXSp7Qm+i2/eimszTpUS2i4lsfYhsFxPZ+uDFJ6gB+iW1 XL+nVooM9S7RbzV+fg0+fZ2oRZQrIcoptRF/fzLSRYh0zcPPmCwhfT+RZ6DwiHIeUc4jynlEOY8o 5xHlPKKcR5TziHIeUc4jynko6RKUdAlKugQlXYKSLkFJl6CkS1DSJSjpEpR0CUq6BCVdgpIuMadp 35wOM2AmzIIn4EmYDXN0DpEzh8iZg+8qxHcV4rsKiaIuUdQlirpEUZco6hJFXaKoSxR1iaIuUdQl irpEURed6aMzfXSmj8700Zk+OtNHZ/roTB+d6aMzfXSmj8700Zm+eUiXmofhCByFY3AcyqECWBNE 5qFE5qFE5l5E5gSRuR/+L4n/S+L/kvi/JP4vif9L4hJSuIQULqEEl5AigudEdmkfp5DCKaSI5L2I 5L0i9ClCn4joOUR0D9eQiqS51tq3BBggQQmPSO/hKFI4ihSOIoWjSBH5PSK/h7NI4SxSVn3yNoBm pLXguiWw1+IyUiiDHJSBZ53NfeYg6qAGriOFQshBIXg4jxTOI4XzSOE8UjiPFM4jhXLohXLohXLo hXLoZbGPWuyjFvuoNQAGwiDdGzXRGzXRFzXRFxWRg59NoiQSKImENTv8RKYsawm8Gn4qU5b1Pscv dCEqI2HxLvG9SeuIyEJxJFAcCRRHAsWRwAsX4oUL8cIr8MIrUCAJ/PAK/HChfaFw8cSF+AIfX+Dj C3x8gY8v2IJKmY8v8PEFPmqlH2qln91Fl9q3Qlc9FH/g27mcs6bsu+Bu6Av9qLM/8Fx4hy14Bx/v 4OMdfBSOi8Jx8RA+HsK3x5J/XPipgj6qx8VP+PgJHz/h4yd8VNBQVJCLCqqDr/BRQkNRQi7ewsdb +HgLH2/h4y18vIWPQuqHQuqHQuqHQupn76Lu3bAH2Ott9npU0zRU0zRU03xU03zU0lDUUj/U0nzU 0lDUkovXT+L1k3j9JF4/iddP4vWTeP0kXj+J10/i9ZN4/SReP4nXT+L1k3j9JF4/iddP4vWTqK4E qiuB6kqguhKorgSqK4HqSqC6EqiuBKorgepKoLoSqK4EqiuB6kqguhKorgSqK+GcQ59+CxfoQqcN dKPuHlz3hNvhr6T14ngH9IY+cLcuQaElUGgJFFrCuZcyE0h/jrwL9Arnec5fgEM6GRUiCwWXiPJs 0Rq6MFpTuO71eqd7A9wInXR7lF17twvnQ3SpOxTy4TulN4rzB2G08FB8HorPQ/F5KD4Pxeeh+DwU n4fi81B8HorPQ/F5KD4Pxeeh+DwUn4fi81B8HorPQ/F5KD4Pxeeh+DwUn4fi81B8HorPQ/F5KD4P xef9Pyo+7weKr6YYry8yuop2RndxvXGbGGL8RVxu9BAXGT3FTfJK0Un2Fjeqjvoy1Un/QS3T89VK 3U7t0B+jDTMVO5zaoyepYv2h2ifqqRL81n59WDQS49OrxEK9VvxNr6X2Syo/DfY8aj+d2k+n9kuN 3vowsXU3reDmcGUddRtauZhWBqkVerl6C1amS9U7+jVi3Eb1nn5frdLjaf0BWj6qduu9tN6G1ifQ uqL12bS+Sjjqcz1PfUGfcPJqre6h1umlKkGpDXozUbEInbpQf0DfPiDnzcTOz8k9jdz5am06Te6n yX0VcfQ1StxDiZnhZzueRW8LiOYNiN5XyXZE8t66t7xLKPkCOnmV/ov8UE+XW8Xv5CEicqaoos7S z6oVwiNKn8UTvExLH+JHlVqL11yvXyVKR6g9zRMliNT5lZFaVXpSxZPtVft4qhLS9+uvjJuEqZeK CFhggwNRcCEGHsQhA6ro5aIqtNGbxYVwv14iHoAH4SEYDWPgYRgL4+ARGM8YLtVrxDK9xpB6s6HA hAhYYIMDUXAhBnGoCtWgOtSATKgJWVALakMdaAiNoDE0gabQDJpDC2gJreA6XWR0gD/D9XADFMAI GAn3wii4D+6HB+BBeAhGwxiYqDcZk2AyTIHH4HGYCtP0Jnm2XiLPhWzooN+UD+uUHKtTzPKOvJVS 5lkFc2wJb6KUOXYtc6xCHU4XqyOsiKPaVsfSR9Tx9GZVri1Vkd6rTuhslSZd6zpmJF1sWvoy09a2 6aSPmNH0ZtPVlhlL7zU9nW3GSc8g30C91BwEg+EeGAJDYRjkw3AogBEwEp7Rm825MA+ehfnwHCyA 5+EFWAgvwkuwCBbDEngZXoFCeBVegzd1kbkUlsFyWAFvwUp4G96Bd+E9WAV/g7V6ibkOErAeNsBG SMImSMFm2AJFekmkXC+1FDB/rYheblXnWAOawWnQGn6rN1vnc3xEF1lTYTrXPKf1LOc8j8XzWDyP xfNYi0lbAq9AIbwBS0lfBsthBdB3i75bn3D+d/iU88/gc1gNG2Cj3mSluLcX9sM3cAC+hYNwCI7o IjsDqkBVqAa19Sa7DtSFelAfztWb7fOhn15i94d7YRRMgjnwtF5jL+R4RC9xWuki53S92TmT49kc 28O1nN+sNzk9uN8TboeHSZ9O+gyYCbNgIZTrTVGhi6LVOLK+oqyraF2orze7PXTK7QO5cBf0hYHA endZ7y7r3WW9u6x3l/XuPgrjYQJMBPrrToYp8Bg8DlNhGkyHGTATZsET8CTMBp7RfQqehmdgLszT S2JX61TsGmgL7aA9XAvXQQfI12/GhkMBjICRcC+MgvvgfngAHoSHYDSMgYdhLIyDR+BRGA8TYCJM hinwGDwOU2EaTIcZ+k3vdL0kI6rfzHAhpt8UJrFiCTt/iVovzmRfrhCPi2F6lsiH4VAAI+CYTuGf U/jnFP45hX9O4Z99/LOPf/bxzz7+2cc/+/hnH//s4599/LOPf/bxzz7+2cc/+/hnH//s4599/LOP f/bxzz7+2cc/+/hnH//s4599/LOPf/bxzz7+2cc/+/hnH//s4599/LOPf/bxzz7+2cc/+/hnH//s B5/CZXxAPz/UpXjWUjxrKZ61FM9aig+djg+dju9ch+9ch+9cJ+fp4vD/H3ny/3W0XR7R24lmSaLY LLVaNCJebiOCPYKHm4WHm4WHm4WHK8XDleLhAv+Uwj+l8E8pPJOPZ/LxTD6eyccz+XgmH480Cx80 C58yC08yCw8xCw/h4xFK8QY+PqAUH1Bqn6ZT9unh53GWov0DLZ9CZ6fQ1im0cAoNnEL/+uhfH/3r o3999K+P/vXRvz7610f/+uhfH/3ro3999K+P/vXRvz7610f/+uhfH71ail4tRa/6aNRSZxB138v5 c8GnpmkfvemjN0ujmaynTno6GnM6mnIdmnKdV6CLvREwUhfHM/X2eE3IgkbQGEaRPldvF5Ko8iJx HR2nlokL1HJxq3pbnKveEbUZ3zfUeyipVaKV+ly0Z6zb4+sjKIZL8PbVVUKcw7h/iXJoiM7ZQepO cRp6oT16oaUqFldQ73uVf8s+nZbe1QvJPyVscwn3+qAqlosM0j7manXwuZQ//ixdo7fI/unP06U/ rVkdF9FqW+LhVfThZEprouURUi8jWi4nWpaEn1G8P/g2SlLrc3VJ+DfFWuRtQR+C7yLYI84gx5lc rRbZPGEm9xryrMGnvnXSn6mBog39f8+8GL0mSfmIq7+Tm9iEJizjqoirXBHn6jhXH4lWwhTZIgIW 2OBAFFyIgQdxyKDFjqKmugWN1xVyeabl6MB30Jnv6jXmQJFtDoLBcA8MgaEwDPJhOBTACBgpsvHy 2Xj2bDx7Nh49G4+ejSfPxn9n472z8dvZ4fdfxFG3B2mpiKfYo97mTQbfZvKufh11u59nH8iYLKNf b5GLp+XZ46K68YVoZqwRZzMyXRmHP6pbyNVZdFZdw8+Y66xy9bvBpxKpwXqHmirOU9PE+bTj86Zb oGQWmReIc8w24mxGq7NoSImGtHMub3OgaExLXwXthy3FK7/X5EPVhdK3kr87x9s4DmSGfaE3oZFL 0cfHwvmzQTiUUsIKvgmF3FnkzCJnlJw+OcpEltjJLoqGErvRTf1pKXing/U6dHcpb70KO+6asL4E b3A9pagzUMSR6roCD1+Bh6/AI1fgkSvwyBV45Aq8bwVtdtTFwb94osbTWCl2WNt6fVDU+kGbXdiz ukMezzYQJb5af0PvyngOnxlXk7YPUep92o3R7tFfbDdGuzuC72ahtuq0G6HGQ9RYSo0HqTFKbd9U PkUF66wjqcHnBXZByXeH/twZKOpQMkqPLUoepmQFJeP0JR2MGiXLWRU7xZ/ELtgNx5jZx6EcKuAE u0NHnEsnfbbqwm5xq+imunO8jWMe3qc//Rms56rhzIup4vfMh4sY8S9osU34btbqJ8PWEnoDay4T l3O8co6cY1K3mQYtWkWqiz/Zt0Bn6Cpa2dNgHmzjejvsAPppl5F2kONh+hZ8/mMZPTvGMx+jZ6fx 3Mfo2Wk8d12eO9gxHJ7X5Vn3qo2iajjrVlDiPUrsokRdSuyiRF1K/J7cVenznnDmrdXl9PsoJXeF pRLh9xLcQnudmcldOXbjOIhdcYdoyo5Xxh7jsjPWYWesxn63IvxGneD9pcilSCnjPXTkrFO4NoJP w8tSA5hV9xDv9tDvYlrcp/1wvm2j3C7KudTuULPkTkrUET31N+J2+CsM4O135H3eQr+6wiBmZpB7 J7NkDyO9lz7tw1+WUMt+4uTFolakqv4mUgpf6W+sXMiDu+BuGASDqTej8juBktScouaUGsBTDWLP 38F73Mks2sUKCp+WfbiYMdqnPw29eC36V07/yulfeeXTB39T3kotW6lFUstp9LEqtRyhljS1BJ80 71DD9uD7iOhfOf0rp3/l9K+c/pXTv3L6Vy7OED1FW3E7/BWGiRyRD8OhAEaIHFqsQou/Yc+KMMId 2LMijHIH9qznGOlXGOm3mKcfMk+vYp62VS/oSTzT34kQLU/2hrgV9KYYNXGBaMMcbWNerJPmHJFj PgVPi5xIVdE2so1jKcev4GuRY50K50GuaGvlwV1wNwT9c+jV4cp5IyvnjQzfVTCC+/Te8K8Ri+j3 /MpcWZW5sui3T85zwr9A7NPrmBm56VV4wa/wftvwel/h7baZp6R3M9dy0z6pZaSUmafoS6g1N71V HWacyyldwd5wQn9uRvQRfOFRM6YPkvNzcl4Rln2Xu2tIWUOKG5b11XHaK2dUTuj1eMy0GRUWZdPk Wo+XTJMzm30pN72HVtK41IP0rFQd41hOqxXMzJMlK2g1jTs9SI9LTYejSy9ipJ+sqYInOMSsy8XX HhEGtZRRS5paNDUUh21bwqB0GaXTlNaULK7sw6nBOKUn0ocdlG5G6c2UPqyOs2KD3lcwj08w49Lo BK1P0Jcd1NaM2jZT22EzqhPhU8V4z56oilMuoeYT9OmlIIpqSY1H6UeRSgtJqaO0XWTGOT9FNwly pFeTYy/tBSOVIsde6gxGKUUdXzO6//S+ePuV74nSv/B+wrzheyHvL7wPnvH/+B7YT//N8WeX+S+P O8/4M+Md3vnJcRYZZqaImjXpX23hmnWprR5l6qMZGnDekHuNuNeUe825bsG9ltxrRTwwzSxaqMfd xhxb8E48M5MrPIRZi/br0kI9Wgrqakh6I9KbkN6c9BakUw9vIcgdtFyvMkfQUlBXdfolubvbzCKl FtQWDelfdXLups6G9E/SP0mp3WZj7jeBpqQ3J08L0lpy3ir4VnJqKaKvwRNKsw59rSsilbUEpYvo f/CE0mzGvebcO1la8ryZUJO5l0Wfa1NvXZ6lHm+/Pm01CJ6L+42435j7TbnfnLQW3G/J/VY8H0/B u6lJvVmk1oLaegN9SDM6O8z6vMsGPHND8jQiT2PuN4Gm5GlGnubkaUmeVkS24D154bjWFpn0Ixix o/Qjk37E6IcXjm1TrpuHI3iUPmTSh1jwVoQKn71u5Tif7H0weip87pMlyip7LUWV/3ROsGp9xu+f 5gWr/SwR/3fnBqXOFvbPzQ/uthA1/ltzhNp+w1P/h/OE0qeIav/XuUItFwRP9N+ZL7yJT8L3+B/N mTA2xP/deRPu6qeow+l97KTd2XHqs6u1U8fTZexql6uKdAm7T092tcbsam3MSHofO2p3dqP67Grt zGi6jF3tcjOWLmFn6smu1phdrY2ZmT7MiJzBiJzKiJxq1ua6jv4NI5JBr1ozKi0ZlRZmQ9Ibka8x eZpAU66bka85+VqQryX5WjFrojg3D8+VrYLv9VklaqB2M1G6zVEVv0crvI/aqxJ+t9Ayo6u40Ogu rjBuE+OMv3DsgXPvqJ9QN+JFbtLLUB5PhN9Ud+q/yPV+mCv4DqSNYep3V0v+cSVx8iuNd/SS8Cz4 drsdnFXBJZ8hhGiDJz1N/IHfs8U14nrRWtwobiL1ZrTcReIO8Yi4WowXL4i7xTKxkqt3+J0kPhEb xGSR5HeOKMKdPCX2UuPzRj2jnlhrNDTOEOuMtkY7sdO41rhB7DZuMbqI/UY3o5vwjduMnqLMyDXu Et8ag4zp4rAxk9+6xhP81jNm81vfeN54wWhgvGOsNhrJs+U5xlnyXHm+cY5sI9sY58lLZLZxvvyj zDEukFfIK4wL5ZXyGuMi2U62My6VHeT1xh/kjbKTkSM7y87Gn2Q32c24UvaUtxtXyV6yl3GN7C3v MtrK/nKw8Wc5RI42bpIPy0eNXnKCnGrkyulyhjFQzpMvG4NloXzfeEB+KDcY02RS7jSek/vkfqNQ lsmvjdflAXnEeFMek+XGSqmVMN5VUiljlbJV3HhfVVHVjU9Vpso0vlBZqq6xRjVRTY0NqrlqYSRV K3WqkVK/UWcYReosdZbxpWqtzjG2qXPVecYO1UZdaOxWF6tLjL3qUnWpsU9dpi4zSlSOyjH2q3bq WqNU3aA6GWXqFtXDOKhyVZ6RVv3VPVKo4Wq4tNQINULaaqqaJh21SC2SrnpVvSpj6g31hvTUUrVK xtXnaqOsrXao/bKpOqy0/I0ZMTPkeWameYq81LzYvFh2NAeao+WN5ljzNdnHfNNcKaean5mr5ZPm WnO3fMosNrV8NeJGXPlpxIt48rNI1Uh1+XlkXWSTXBPZEtkmk5GdkZ2yKLInskdujRRH9skvI/sj X8vtkQORA3Jv5FDkiCyOHIsck/sj5ZFyWRo5YUXkV5ZtZcjDVlWrqkxb1a2aUlu1rYZKWU2s3yrX +p31O9XAOt/6k2poXWt1VGdZt1r3qfOsB6yHVBfrYWuc6mZNsCaov1iTrMmqh/W49bi63ZpmPaH+ aj1lPaVyrbnWXJVnPWs9q+6yFlqF6m7rdWuFGmK9bb2nRlofWB+q+62PrfXqQWujlVSTrZSVUo9Z W60v1ePWXqtETbO+sSrULFvYUj1n23Zj9YLd0j5X/c2+wL5YrbMvtS9VSfuP9p/UJvtqu73aanew O6id9g32DWqXfaN9o9pt32J3U3vsHnZPVWr3tnsr377THqLK7GH2CHXCvtceZUr7IXu0adpj7XGm ZU+wp5uOPdOeaVa3n7CfMGvYs+05ZqY9z55nZtkL7eVmLXuV/bF5ir3G3mCeZW+2D5i/sw/ax812 doWtzRuclk5Ls5NzinOaebNzpnOW2cU51znX7Opc4LQxuzkXORebtzmXOpeaPZwrnavNnk5bp63Z y2nvXGve4VzvdDT7ODc7N5t5Tg+nl3mXc7fTzxzgDHOGmYOdAqfAvMe517nPHOKMdh42851xziPm CGeCM8G815nsTDZHOVOdWeZ9znPOAnOMs9BZaI51FjmLzHHOAedb8xHnkHPIHO8cdY6aE6JsfObE qBk1zclRO+qaU6JetJY5LVonWsecG60XbWjOizaONjYXuNe7t5jPu93d7ubLbk+3p/mKe4fb2yx0 73TvNF9z89y7zNfdvm5f8013sDvYXOoOc4eZy9zh7khzuTvafdF8233H/cjc7a53t5i+u9XdbR52 j8XqmulYs9jESOPY5NjTkfGx12MrI7Njq2MHIs95tlc78nfvdO/ySJHXybsjctS70+trRb3+3kCr ijfYG2JV94Z5w6ya3nDvQSvLG+ONtxp7E72JVitvsveYdYo31XvKOt17xnvGOs+b571one8t9l61 LvXe8JZbV3hveW9Z13hve29bbb13vY+sdt6n3lqro5fwElYXb4OXtG71Ut6XVndvu/e19VfvW++o Ndg77lVYw710XFgj4zIurfviZtyy7o878bj1ULxqPMt6JF47XtuaEq8br289Fm8Yb25Ni7eMt7Rm x0fGR1pz4qPiD1pPxcfEH7WejU+KT7EWxh+PT7UWxWfEZ1hL4rPis6yX40/Gn7Zeic+NP2e9kSEz MqwVGdUzalkfZ9TLaGCtzjiScdxaK6SLfhfCu6zadeIU0Vj8l370Mr1T7xFn62LON/9kjrSepRfz W6bHcnWd7kyZ9zkrrrxfrEv47/bKq8M/Kh/cLdEH+f3fe/ZPtPMtPPaL/c2Ht36QspUWsoJWfvYH 50W+Tbqcc49I3kXEud75wz5+9zQ/0eanepv29WfUsIOn3ftLffwVPw61Tq2sfZcu1e/r3ZVXB37U +n4o0l/qdfqovlpEGbvTRJPv3U//UmP6EO/uIDX8b88ZfxTLybvP6meFB/94h/9U+ivYrVPUsZXL CDqrpbiEs0bh3b/pz/UG5g9zB9/+0+2/oJ/RszmOgWx9ph6kB3L2vXH87uk5K/1R6bT+QO9lBn2g /04/eA/B6P2w1D/yfvoLQyHwqUJkhGfjK1N86v7su7n5/VlRmXKQJz/A2G/W36L3q5B0Lm/hH63r /eEb2v9d7h+VL9X7WGP+dyMe/GU0PG75fp5f6ndlvtQPrvr94OqjX1cHP63D/JUzTW/k/Tl64y+0 fOR7a7u1+P0v5H5RLwhWtP7gV/fph+X3BLMjmLM/urP+V5TmyfRD4dnr/7ye9V9+RXnmiH413Le2 Bu/t3/3Rz4e76fOM649/nF9VQ5leFu6av3Je/EQNB379rPqJ0pU7rF77H5VeEv53Y7Bz/Nd/fvsr 2t9zMpbpcubRt/92C96/vNsK/hy28l3E237yt/J+o58ocyq/jfg99Qe9nF95XH3y91+Ub/2T5StH l1lyiN3p0M91mP3zK/0NO9i2cE0Fs/pomD4lvN1Qv6NX6kQQ0X+mfMX3zseJOuz/N4lrgxVSmVZE bFj+4734H2XKv3c+kchTRVwlunO+qDJtJ6O35uej6nfthzN6BuWj7D79K3fyIP0VvVgo/cbPlv/n WRhBPfUi/dHK+x/pDxn/Tyqvfrx/H//e+VhK1xHtRKCEsivT3tJLqeGln21/10+np3ljwf6oO+j2 uqe+tjL3nB+Vv49d7Fn9kv5CJ76XLMWt4n7xCGfjxYTg38yIF5m5i8QbqMPlYqU4J/yrwnlildgg zhebxG5xjdhrGKKT0d3oLgbg6P8sBgZeXgwOXLy4R/aReWIofjwpCuRmuVOMkMWyWIyWJXK/GBN4 czFWHpZHxCOyXJaL8YE3FxMCby4m4c1jYopqpBqJ6aqLulXMUN3VbWKW+br5ughcrRazI9Uj1cWn 1mvWa+Iz6y1rpfjc2mxtEV9Y2tJibeDpxLrA04mkfZ3dQRQFnk58iae7SWwLPJ3YEXg6URx4OlES eDqxP/B04ljg6UQaTzfOELi5SYZlT7GnG9HA0xlVAk9nVA08nVHNnmvPM2oEns6oGXg6oyWe7oBx Bm5OG9c6yokYnR3HcY2ujudkGLc51ZwaRk+nplPL6OXUdeobfZyGTmMjz2nmtDD6Opc42cYAXNvt xiDc2RhjCO5snDEs8F9GfuCJjOGBJzIKYvmxicaowOkY07yqXm1jufei96LxN2+n97XxfuA1jHWB 1zA2BV7D2BJ4DePLwGsY2wKvYewMvIaxL/AaxteB1zC+CbyGcTDwGkZ54COMisBHGCcCHyFlRjQj Ju2Mmhm1pJtxNOO4DP43hY3hjDHCGSOZMVNxFNPETOb0LDGPlGf5tcV88QJRaiHzyQrnk8V8WsGq e4tZ5YazymVWfUz6JyIhYmI9v5JZtgFVvUlsQV0ViR2ssZ3MuSZir/iGFX+A36biW3FENBNH+W0u jokTooVIMyOrhTOyQTgjVTgjvXBGeszIXFFV5jEvvXBeVmdeFoksuVVuFTXkl3K7qCV3yB2ittzJ fK0fztd64XytHc7XmuF8rRvO1xpSSy1qKOS/yGTWSv7Lj6jJ3LU55+WLOirKPM4M53E95nEX0VLd ymxuxWzuzvltzOlW4ZxuwJwuEoa51dwtpLnH3Csss9j0RcwsMw+KhuYh87CoYh4xK0Qj8wSzv0U4 +5uEs79BOPsbhLO/QTj7GzD7/ygy7Rw7R8Tsy+3LhWlfwXqIsB6uJuUa+xpS2tpthW23s9sJx27P OmnGOrmOsh1YLdFwtcSCv4CIuH0TayaDNdNZNLG72LeKKnZXu6toYXdjFVULV1G1cBUZrKI7KZVr 9yVPP7s/KQPsAULaA+1BtDLYHkzN97DSYqy0fEoNt4eTXmAXkH8Eay8erj0j+HsKecbYD9PuWHsc dyfYE0iZaE+k1CR7Enmm2FNJmWZPoyfT7emksD6FG6xP6pltz6bUHHsO6XPtudQzz55HzoX2QlJe tBdRdrG9mHFYYr/KyLxmL6Wfy+z/oe5L4KMo8u+/3T19zKQmCUkIuQgQrgAxhhAChgQBERVcRcRj UcmhCxrJZIJ4ZCQzgAaRRUVUREXkWlfRRRYVEfkhyyKisoiAiMgtAiIiIgIi0v9X35mMiaAQYHX/ nU+9qamuqq6Z6X71vn28LMB38pb5Fkb1b/MdjHaZ+R76/MjEnml+bGKfND8xN6C3z8wt1NTcan6O 72SHuRvb+tLcQ2nmV+ZefJNfm/uohfmN+Q22uN88gDEfNA+i5vfm91h7yDyE8sPmYYzkiPkD+j9q HkXPP5o/oudj5jGKNX8yf8LWj5vH0dY2bfn/VS2dGks2AYJNgGATINgECDYBgk2AYBMg2AQINiEF bPIAcIw1hlTJKeSQnEKK5BQS4JThwCpXgKIls5AGZllHIuKTiPXkjvg04gBFS5YhTbIMJYJlPqdY sUPsoDjxhfiC3GKn2EnxYpfYhbW7xW5KEF+KLylF7BFfI79P7EP9b8Q3qLNf7Eed78R3yB8U31OS OCQOoc5hcQR1joqjWPujOEYR4riwKcEtQ+tYyV9Ah9sB1N0GxYDFLGrkdrpd1NAd4Y5ATeF2Uwp4 LRYlce54SpLsRvFgtyRgsjsFdVLdTSjO3dTdFP00c6ch39zdHPVbuFsgD+5DObgPJc+6p2Arz7mn otU09zT0PMM9E33+zf13aijZkDTJhhQt2ZCiwVj/DLHhePxpzIY62HAS8s+ABzXmQQMs+DLys2k+ 8E3C3gY2XIz8EnCgRu+ABzXw4MdgzHXgV43P31vMgxrzYEPmwXjmQRfzYCPmwQTmwUTmwSTmQaFE KVHkVgYoA4BDlDJguTIUOEwZBhyrjCU3WPIqUpklnWDJW4CSJSOYJZ3MkpHMiXHqXnUvNWAejGEe jFV/Un+iKGbAaM2hOSgG3Gch79Jc1EAboA2gFO0GvpNNcl9j5r4m2kBtIMoL+e42yYONmQebaCXa zZQc5sFdpIEBD5IF7jtGLma9JGa9eHnWFsdnd7M7jt4eZg/SmOMs8xJwnAMc1wd5yW4as5vB7JZg XmleiRLJbpp5tXk1sL95DWpKjnMwu8Uzu7mY3ZLAbkUkzBKzBHizeTPq/8X8C3CwORgomc5ipnOF mG6YOQwld4LpDOY4y6w0K9HWZ/pQv4bpAsgHOW6UeR/ykuksZjqNmc5ljjPHodVD5sMokaxnMeuJ EOtNMCegXHKfxdyXxKynMes5zGfBelqI9aaaU5GfZk4Do003p6O+5EGNeTCpFg9qzIMWeHAB8kHu W2j+C/l/m6uAkvsscN8G5CXrNWTWi2fWczHrNWLWS2DWS2TWS2LWE+Z35ndoJbkvnrkvgbkvKcR9 x8BxGnOcsBRLIS3IVq57XJXkdN3ruhdY5aqiCFcA3BThGukaiZJqVzU5mafUiAkRT5HKjBMnvgbX RItvxQGKYX6JZmaJA7McRv6I+IGiwCnHcZxLTmng1twaRYFNTIpkHolhHokDg8QgLxkk1t3I3Qh1 JHfEuRu7G6O8SYg7mqEHyR0xzB3RzB0NmDtiwB3Pos/n3M+h1Qz3DNSfCdaIYdZQSc3eL8+8dtp5 US71put/Tef//7HYu+0vZQq923qyuEue5+FzffXte4c8w8WR92J+/1nNNhlXhaLPvTL+5Fh0g73d 3lX3jM6pt1tzhs721n+E53ax+yDylK+/Gnuf0GI3Iu13z/y8TLifvb98Z3/LGCpHrHgQ3+x2ex9S +MxerUg0rlbrDai1nuR5j0bIhc4w1kTXv9PiCo+m9nYF/ZnLvjrZ2QV7z4nn5uwD9jb7U6w54SrE mS41Z8nrvpPHT2ivrnW+AGPXwvm9v/Yr21tOPKt5rpaTX8E5ZauZ9jR+PcZnw5fLJM8P2S8i916o Ts2eJY/g7+0Pa8rrtZ0dvI9u//m9PAtmb6pV4yE+HyTPlW/h3A6MpjZDhb7f0/19+az19lPXq/+C Pa1Wv/Yh+xjSUXmuy/6pTr3fui71P7b8zsf8aSz25LNo3Pck/W2ndOyDqWfR628v6cTcKvmUOfWk C7jhtK8hnv1c8Yv+6oyq9rF3mu3n2ovsOaHrA3H2c/YiLv1czu61Z+8z0g/rwY1bWT/sYm3CbCbn JHsrXl8K1drH19veR3oHf7vqnrlmJkukmnOzSzEXvGd/hDQZpb3tNfYHXL42qCL4ivaf6z/SE0b+ ZZ13PIfa/6xVUmrPsMvsB+VZfntouLQLyubL4+7Eq44kr7meeC10j70Yn2XDuTtSa/YHOY+BwWp0 4XsUuj5bewzg5fC1EXmN5RQ9/+dcjfFMF3xLbn59VF5vPmHtMHtpnbrB102Y3T6Xe8gZbO9judez 3uLvSeYwv20NfWtA+zZ7Jf/eh0k7yRzmpqwT+tyH4+Dr0NUlDcxRc9XpcHDt2c9vP1+Hrnu9skal SO3F8/YO/O07QXtuYe15kqMdR/M55q6TLb/gszUnrD/2y5JQecXJy6k+19HrvdiD6tkgeI/FGLua X79hBnhVJuResOcFc7yuRp/x9U78Um+ewejm2vPBmK+H3i21Z5G8P+gNmUcCc4LFloIlalTwN2Df D0I8Ebx+FnlCn+/ar9tvh/qMk+9C5XXYwbbrP1puh6PU/jT8riZ22SZzNXFlUIkzo70n94/gPSKh 4+cAM/JNdl9+9zbJq3lepLuRG29Pwlx3d6iXWve24Bt4y/adwWiL7Sp7ul2G3BIc1dPtwcwPD2E2 mo7v+W17sn0r5tZv5DVA/mQL7Nn21OCWQ7NGkr3kF33ustchqgweuR3DuZDutH8IptNXzHX6PsjH e/iuoLqzFM/T4ciXle9Wvu+h9h0XmXXvWPm9lrpXcfkOpq9PPRL+RCfcf/V7LHUjWfmtYh/+7lT8 yb/OOYt067PU1h84GmSU9Qlef+VKd7jmnrMfr/2sPdy+336S8x9if58m75QJzUNBvfi9/RrSorPb DveUFbyT5az6+NzeiZmQ50f8pjuxH4Y1d/BXt/dDc+w/mQKs97bOQHPXav1B8FfFWCQP/if0bkvo +AmN+o85nk+22IPsv9gL7Xmk8rsq+y6wdVFQEdhv2EfwbpxdYV9gNweP5th327edxbaC+rHpWY03 xEnBmDZ8v+G0umvP5WLPPAd9yL13XZDVoW9P+PV5/XZ79c+z8B+7YDSf4Zjjc57Yh2WkGI5UgkoX a99F+pV7VX/vBeN9uPaRC3214I8cz68vONqGSe0UvNPVvgPqaC2OvuC6txk/s9+0b7AfRO4Re2Ow 7Ay39e7Zj7eeWzxY+z6v/90lrHEPnP3dlSe71/1cLkF1CP39BWa9c3DG4lT3KP9m29Pco+xX+Nz+ V2e+pVpL4jnp5bQWaKGzVq72o+diJKfYRojpoG7P+rz8OfqVTrWVz6Fs/8tHyrlboHoOnrNvJuYs xnEujvff8XrEmeyN0D3bgy1DT3bUnBdZydcZVv5mY0+o7pz6b/f3Xs7kGYgT+vjVqyG/0YbP1ssz RcFIOHhGJ3wt2PVb8TGf202kMjLqv11ufwZPedm7eO74+VmymnNypxvbRdAl9d/qH7rEn2nD+l95 InlXg7wuHY7s7bcYvwY/n/JqxP/aAt3//a8/M1Gr3pH//lhObzk9hjzTWf2kz0qdclt8B8HPzw7y FYvwnuU6aaOauvJcVQrdgGPuD1jqavcgayB6OgXP8pWYP+B8n/3tOexrG4XOKJ/0iaM2/JSTvIL+ 4UnWnqpv+RzVtpqWNTk+w78tVFKzzS68rV+Mq9a7B37us2Ys8nmtE0Yln8pqL6/SnEnUbk+2n7cX hJ8DC+WkIgid0/wwPI72J4z3+fpvr077M7hTyF7NVyXeD7/ne4CgN43TvtJ3Gk/v/cq2T/ps8ina 7OSzVnImZy7gd0tx7AWZwfVb+pJnlCjqenrPa56k/Znc/7BGPm/J6VDwPWPorPlvs0Pos6TUvd8I +9e39kecJlMjaNIvQ1eTtgaPad7XSus/0lN8juAVtlrRul1k323/3Z7CvgHhe3rsPvbceva89PdR zHKMv74d+/jJrioHryj+ouzbU1/FOdOF75EJMbN9AHriAPTRenvDz0xk70WZvGbc2b6W37+KPWCd fZP9jnxvv20/bi+TZ8x53WN1+t5UU16vEV1pl9kj7d6hd5zDHjiY88/bM+yh2A8mQ60twMwra8yz X7dfC83a8ux8PGXxNed77CFcFrwfcQp09bPy95AuCeG7gOqcC7J/qHmav17jfcp+EbHa06F3K3nb k5nnV/J3IK++zrEP2v/iCsGn9kN3GIT24o713+oftfxXnsY+cSvbahgreN35j1rO5DoVfumvqdZZ h7BDwunMPbEk79+5mvMplIPYsym3/QKq4wueTZKpg/0xjlD5t8nebF+A42UwCTs4r4fiVBydwZiq Uej93NCVCpXCT0xz+cu/8Tn43grbh3kudAbS7m4XIvWxB1GsHZyDazw0qpAutrvY19ihJxvs5fZG vltCHrF7MCdtC8Wv7SidZ852XOu3z26cfFzT7BnAF8PvF8hYrs6dFf1DmRuoH3WmbPaJaclran92 1/HVdsTxwzxTLrRvt1+Vc5jtt++TOfQ6ts5mg/eA3X4G4x1il+Pzl/MbC7khzJv38Uz9EX7LXceD T9K/wa4gNQt/s/YdoT5OI8Y76ba/PHWdE9rs5TsCpE7gvYn35qV47+DV4jf1jmwVRfkYvUprTuFj NyDkYzeKLlNUpSHdwu5097A73Rh2pxurDFBuovHKbcpt9Dj70j2h3KmMpUnKOOVJmi3d6WiBdKej t6Q7HS2U7nT0f8q/lA/pbTVLbU8r1Rw1l1ZJdzpao16oXkhrpTsdfaxepvahT9Sh6h20Qb1HraSN 6nj1MdqszlRn0nb17+ps+lydp75BX6lvqm/S1+pCdRHtU5eq79C36nvqe/Sd+h91JR1UV6kf0SF1 jbqGjqjr1HX0gyY0Nx3VorUYOiYd5shmhzlihzlda6G1UEx2mLPYVS5Cy9VyFTe7ykWyq1w0u8rF sJ9crDZAu0GJ0wZqhUq8fFZOSZCub0qSdH1TMh1vOBYpA6Trm1Iind6Uv0inN2WQHq03UAbrcXqi cpv0e1PK9Y36NuUu6femDJd+b0qV9HtT/NLvTRkh/d6U0fr3+o/KA9LjTXlYerwpT0qPN+U56fGm TJUeb8pM6fGmvCQ93pRF0uNNeVt6vCmrjJuM0con0t1NVaS7m+qQ7m6qLt3dVFO6u6mWMdWYoUZK Xzc1Rvq6qbHS101Nkb5uanPp66a2Nt4z1qttpKObeoF0dFPzjF3GV2q+dHRTu0tHN/VP0tFN7Ssd 3dRS6eimVsrn41S/pVqqGrAMy1RHWBFWhDrKirKi1fusOCtOrbYSrER1tNXYaqyOsZpZaeqD0nFN /at0XFPHScc19RGrvdVefVT6rqkTpO+a+pj0XVOfsLpZ3dUnpe+a+pT0XVMnS9819Vnpu6Y+J33X 1OnWIGuwOkP6rql/s4ZZw9QXpPua+qJ0X1NnSfc19SXrQetBdbY1zhqnvmI9Yo1X50j3NXWudF9T X5Xua+qb0n1Nfct61VqkLrQWW2vU5dY66xN1o/Wp9Zm62dpk7VK3WV9a36l7pSubeli6sqlHLNup qD9IVzb1mHRlU3+Srmya4kx0pmpu6cemxTrTnOlanLOdM1NLdmY7s7Umzo7OjlpTZydnF62Zs8DZ Q2vl7OnsqWU4ezkv1c5z9nb20bKcf3JeqWU7r3Ner3V0epxDtU6upq4WWr50d9O6S3c37TLp1qb1 lm5tmle6tWmV0q1NGynd2rQHI/pH3Ky9JJ/a096Sbm3av4UporQV0qdN+1jcIG7V9kufNu249Glz OKRPm8OUPm0Ol/Rpc0RInzZHQ+nT5kiRPm2OxtKnzdFU+rQ52omZ4iVHhvRpc+RInzZHnvRpc1wo fdoc3aRPm6O79GlzXCZ92hx9pU+b4yrp0+boL7aJ7Y4B0mXNcaN0WXPcJF3WHCXSZc1xq3RZc9wu XdYcZZFqpOXwRIrISMedkTGRcY57pLOa497Iw5GHHf4oilIcAVKV7WC9SER8URRNCjXAn0YxmIcd lIC5W8es3hLlrfBnUmvMghZlgCWd4MMuJMCH8v88dOX/gCEZM5IZMwqMeS1aXYe/BuDNm9DjQLqZ utEt4NDu4NChUA534K8HDaN7qCFV4i+efOTHlgNg2AQwrKBExa1EUhI/IZysRINzzwPntkZJupJO WUobpS3K2yntkM8AFycyF7cHF18J7AtGvpj9QhOVm8DL2czL2czLHcDLw1FepTxAOcoYZQz6fBBM nQymfoRylfHKE9RJmQjWbs+s3Z5Zuz2zdhZY+0XkZ4G7s8Dd72A+WKYsoy7Ku8oHlK+sAJsXMJur YPMcYEdwusGcHs2crjKnRzOnxzGnX8Scfj5zemfm9BRw+ovURJ2lzqLG6kvqP6iZOhssn8Ysn8Ys 3xQsvxD4f+D6VOb6Fsz1jcH1/wGuBOM3BeOvAn4E3k9l3k9l3m8O3hfUUnOD/Vsx+6cz+7cG+ydQ Wy1RS6R2WpKWRD3lTIA8ZgJqg5mgNTBda4NWmA8oQ84HaJWn5QG7aF2wtkArAHbVuqIO5gYg5gaU yGetL+FnrS/l56sv4eerL+VnqnthnghQV8cIxwOkYLYYT1GORx0T6QLHk45JFOt4yjGF8hzPOaZR I8d0xz8o0THb8TolYUZ5g7KlmyjlyHmF8uW8QkLOK8BoPZq66w30BtRezi6UjdllLWn6x/rH1FRf p6+jKP0T/RNy6Ov1T0nHrLMRJZv0TSjZrG8mU9+ibyFL36pvpYb6Nn0bRcg5idxyTkLN3fpuaqB/ qX9JMZiZviJF36t/jS3u07+hWH2/vp8aybkKW/xe/54S9EP6ISrQD+uHMbYj+hGM5wf9B+SP6keR /1H/kbrqP+k/oefjhkqxhmY4qKuhGzopmOFMwmRhWOQ2nIaLoowII4I0QxiCEgy34aYCI9KIRB3M gvK/uhuxaBtnNETbBCMR9ZOMZIoxUozG6DnVSCXpgNoMmGakoYfmRnPUb2G0QP2WRjrqtzHaUCOj rdEW5e2MduQwMowMijTOMzLR//nG+WibZWSht/ZGe9TJNrLRtoPRgYSccbGtTkYnlHc28lCzi9EF PeQb3Ug3uhsXo2YvoxeZxiXGJRjzlcZV+Fz9jGvQ/01GEbZebJRgKzcbg9DPYON26mYMMcqpu+E1 hmGLdxp3UQ/jbgPsYVQaPoo37jXuxWiHG358loAxAv2MNEaih1HGKPRwn3EfRRj3G/djK9VGNeqM NkZjK1AAlCwVAGVBATxKOcYEYwJ1kDqAEqEDnsTaScYkSjKeMsADxjPGM5RvTDYm49ueakwFTjOm U7b0gEV9aAX08JLxEvBlA3upMduYjbavGHPoYuOfxj/R81zjVaydZ8xD2zeMN1A+31iAmm8ZC1Hz bWMx1v7LWEK5UBjLUP6u8S5lQme8h/rvG++j5APjA9RcYXyImquMVRjPR8Zq1FljrMEI1xofY8zr jHV0nvGJ8Ql1MtYb69EWGgWtNhub0fMWYwta7TJ2obfdxh7U/8r4CvW/Nb5HnUPGIXwbh43DGNsR 4xglSh1DHaBj3MhHmg0ox4wxYynZjDMbUa6ZYKZQJ7Ox2ZTaQ+W0pnwz3WxDl5ltzXbUxcwwM1By nnk+FZhZZhZ6aG+2R81sMxt1OpgdsDbHROwIbXQBdTTzzDxsq4vZBfXzzXysLTALsC3pKaBIzUTZ UjMBoZmA0ExAaCYgNBMQmgkIzQSEZqIkqZkoWWomIDQTnSc1E/LQTJQvNRMlSq9ayrS6W93RCsoJ JVBOqAPlBIRyolypnKgTlBMiAWuwNZgKoJ/KKcryWhWoAxWFtlBRKIeKQs0R1gj0M9IaifwoaxTK oagwHigq1H/EeoRyrPHWeLSCrqIO0FUTUfKkhb3OmmQ9g/zfrb9jWy9YL9BlUmmhBEqLXFJpAaG0 gFBaQCgt4JfWt3ShdcA6gK18Z32HfqC6KEuqLuRty5b/e8tJdLFTcSqUKBUYJUOBmUDLaVFHJxbK crqcLuSFMxIY5cT864x2RlOus4EzBiWxzljKd8Y546iDs6GzIRU4452NUJ7oTKQcZ5Izic5zJjuT kU9xpmArjZ2NsTbVmYoSaDvkoe0wEmg7ILQdENoOCG0HhLYDQtsBoe2A0HZAaDsgtB0Q2o5cUtvR hdB2V1O0q7+rPxmua1zXIH+t61rkr3Ndh/z1rgEUJ5UfSh5wzSTV9TfXy8hD/yEP/Yc60H+o80OE QmqEGpFEF0kVSJ2D3g1SBZIqVSAQKhB4g7iBGosbxY3UVNwkbqIGYqAYSE1EoSik5qJIFFGaKBbF pIkS8RfkB4lBqD9YDEadW8WtqHO7uB35IaKMWgiP8KBOufCizlAxFGvvEMMoFcrybpTfI+5BOfQl cLgYDqwSfkoRATGCmomRYhRq3ifuQ837RTW2OEb8FSXjxMPoGRoUW5kgJgAfE4+jzkTxJMY8SUxC P0+Jp5F/RjyD+pPFZOSfFc+izyliCtY+J56j1mKqmEptpHKldCjXmdRO/E38jXqK58WLyM8Ss1Dn JfES1r4iXgHOEf+kDDFXzMXaV8VrWPuGmE9txZtiAUreEm+hBHoXCL0L/JdYQi3Fv8VS1HlHLKNW 4l3xLmouF8uxlRXiQ5SsEqvRJ9Qw+l8n1gE/EetRZ4P4DGs3io3oZ5PYjPwWsYVyoJK3obftYju1 llqZUqGVR1GK+z73/ZTmrnbjW4JuHkMZ7gfd+K7c49zjqIn7IfdDKHnUPYHauR9zP0Y9pZ5GCfQ0 ZUg9TXFST5Mq9TQQehoIPU1xUk9TNpRdN9bTvVhPq6ykg7q5RjFLfRzJ+jiS/oy/SFbGl7Iy7s3K OIaV8eWsjONZGTdiZZzAyjixln+Pzv49Fvv36Ozfo7N/j4v9e3T279HZv8fN/j06+/fo7N+js39P FPv36OzfE8X+PTr791zG/j192L8nlv17/sT+PVewf8+V7N/Tl/17kqDUI6Cb3YqbNXoidVSSlCRo aKnUO0OpX0l5rMWvVq5R/oxyqcW7KIOUQVDYdyp3Au9SfNDNw6HIO0GRj6ECaPEHkf+r8lfUl4q8 ExT5k9QNWnwydYcKfw34uvI69VDmKW9jrVTh17EKv4hVeE9W4RdDhWeRxipcq6W/Nejvi1h/Xwb9 3YdVuHQYcrDDUAN2GGrADkMN2WGoAWv0q1ijX6A+qI6lrtLZn/qHlLrU5e3UV9RXqI06H7q8OSvy lqzIW6sfqB9Af0st3kxdra5G+cfQ383Ytaix+qm6CYp8i7oFKB2MMtjVra26Q/0CJbvUXUDp7ZbK zkYt1K/VfchLf6NW6rfqAeSly1G6+qN6DHnpddREPa7alMqOR2maoqnIS9+jVpqu6chL96M0dj9q oUVoESiJgvrPZN2fzbo/h3V/Py1ZS0G5VP+ZWnOo//O1VlD/maz+s7S2WlvkM7QMYHutA3VAJNAJ +c5aZzpPuwDxQCbHA+21fMQDmdqF2oXoX8YDmRwJXMORwLUcCVzDkcC1HAP0gvqfSJHQ/VMohhV/ Aiv+ZFb8nR3zoPi7QPEvpQLHO44V1IN1f89ankw6ezJFsSdTLHsy9eVIoDdHAt3Zn6kPxwN5iAfW kMExgKl/ihjA4BjA5BggktW/yeo/Qd+h74DK36nvQonU/QYr/kas+Huz4o9hxZ/Aij9RP6gfBEpN 34s1vcmaPoY1fS/W9KphQNObrOZNVvOJrNp7sV43WanHsFJPZHXei3W5ybo8gXV5L2hxxL1GJhS5 wVo8hrV4r5AKzzFyUD/XyEV9qcV7sQoPam6TdbbJ2vpS1ta9WVvHsLa+nLV1PGvrRqytE1hbJ7J6 TjTGGeOgKR8yHoKalOo5jxVzvjHRmIhyqZg7smLubkwxpkBHSq2ca0yHVs5nrZzMWrnAeN6YBR3/ ElRyMqvkq1kfFxivGa+hlVTJuaySr4ZKno+2b0IrJ7NW7sxaucD4t7EUPbxjvIP6UivnskpOZpXc mVVyAavknsZqqOR8VsndWSXnskouYJXcjVXyxaySOxqbjE1YK/VxUBl3NPYa+1Ei9XFn1sd5rI+v No4bx6FQpTLOZ2VcAGXcCHmpibuxJu5uNjNbUg9Wxj1ZGV/Hyvgi1sHdWQdfxzq4J+vgZLOT2Qko FfDFrIB7mheaF6JP6SgWxV5iOnuJRbGLWBS7iOnsIuZiF7Er2EVMZxcx3exn9sPWpZeYzl5iUewi 1oddxGLZRawvu4glsYtYEruI6ewiprOLmM4uYlHsIhZby0Usil3EXOwiFsUuYknsIqazi1gUu4jp tVzEdHYRi2IXMZ1dxGLZRSyJXcR0dhGLYhexpFouYjq7iEWxi1hfdhHT2T9Mr+UfprN/mJv9w6LY P0xn/7C+tfzDdPYPi2L/MJ39w6LYP0xn/zCd/cOi2D9MZ/+wy9g/rA/7h8Wyf9if2D/sCvYPu5L9 w/qyf1gS+4fp7B/Wh/3DrmD/sL61/MN09g9LYv8wHTFMLOUhYmlJ3Tk+6WG1tlojNki30qH121nt qLOVYZ2HeCPTykR5lpUViltyrWyrA13M0UuulWt1BsoYpqfVxeqCfmQM08PqZV0CvNTqg94ut/6E OldYV1BH60pEMgVWX6sfIoTrrOuwVsYz3axCqxDjKbFK0CroxCgjnJ6IcEqxLRnhRFoV1lD0c4d1 B1rdad1JF1l3W3ejpMoK4FPIOCePY5tkdm7M5Qgn33rYehgo45yLOc7Jt56wwBIc5+RyhFNgPWc9 h5IZ1gxsXUY7PTnauc560ZqFVjLmKbD+Yf0DdV6x5gBfReQTYW22Pgd+gZgngmOeSzjm6WEdtA6i Zxnz5Fk/Wj/i08mYJ4Jjnqs55unOMU8+Rzu5HO3kcbST63QjwslHhNOAunGE05MjnIs4wrkYEU48 oqBGzgTUTESE05ljm2SOZ3ognmmNrbRFPBOBeCYHmOvMAxYghongGCYCMcyVQBm9RHD0EsHRyyWI XvqHIhYZq1yPOGQARyw3um5Eyc2um6mrq9RVChziGgL0uDxAr8sLHOYaBpRedA3Yi64Be9E1ZC+6 huxF14C96Bpw5KNxbHNVRHJEGl0Q0TviKuoacUuEj/qzU52Dox0HIpx2iCJkDNOOY5g24i+IYZqJ 20QplLqMW5pxxNIOEUs58l5RgcjhLnEXSmSs0lzcK+5FSZUIIEqR8UlLjk/acXzSBvHJWJT8FVFK G45SWotHxCOoL+OTduIJMRFrn0R80hrxyVPoTcYnLTk+CUYmzTkyyRTTxDTgDDEDKCOTHI5M+okX EZm0R2TyMsr/IWZTFkcm7Tky6cCRSQ4ik1dR8pp4nc4T88Q81HxTvIlyGZ+cLxYiPskUi8QirF2K yCSLY5Icjkn6iffFB1i7QqxEuYxMOog1Yg1qypgkR3wqNqD8M8QkHRCTbEJvmxGZpHJkkiW2iq3Y roxPsjk+OV98LqDx2B0wg/1I24o9Yi9KpFNgmtgn9iMv/QJbsV9gGvsFZrBfYBr7BTZhP9JU8ZP4 CSi9AzOELaAA2UGwBYQ5FCD7CDZhb9JUdhNszN6kqewp2Io9BTPYm7StO9IdhXLpL9jKHeuORYl0 GUxnl8Em7gR3EtZKr8EM9hpsxV6D6ew12MKd5k7DWuk42IodB9PYcbCFu9RdSs04EmuJSGwkR2LY H9wPuB9AhDYG0VdLjr46cNzVD3HXE8hPdE+iLI6+Orifdj+NvHQubMXOhY3ZuTCDnQvT2bmwFTsX OkhJPpAyAuJXaGNpC1HRAKQipEFIQ5CGIt0TflW8s/DqR7ofaSzSeKSJSJORpiO9gDQb6TWkBUiL kZYhrUBajbQeaTOpI97nREU7OKkjViGtQ34P0n6kQ0jHiIpVJAspEikOKQmpaXAMxa1+5TUj2Fdx dijJNp2RuvI6Ku6J1Ds4Xm4zPfgZi/siXYt0Y7A89KqO2MhJ8c5Bmof89nBZMO1G2hfKr0M6GMof DaaRFEoGkkCKQUpASg3WHdmC61NxCdKtwe+p2BP+zoN123I9Kh6G5EMagTQ69BnGBbc3Miv0WScg TUKaElo/M7Q+N5TyUYbfsVh+noVIS8KfJfiZ5yEtRFqCtBxpJdJapA1IW5F2hl731nqtqX8A6Ujo dUOo3ZFa648TlTiQXEjRSPFIKT+/yt+vJA0p/bRf1ZE9fv6t5GcryQz91vVNSXUT799jg9vh/Sop WI+3WzvlIOX9/BruI9ivOvJSlHdD6hXa/7Cu5PKfX0v6IV3vaDBwa1nvqlVF95cTo8EogGPLY4Dj yxOAE8tTgZPLWwCnl7etWiVbBW4seqE8K1AycGdZ36p1A/eWXVu1sWh2eS5jfjj/WnmPqo1ybeDW gQfKbqzaXrSg/NKq7cF8CI+UlVTtLlpcfgVjf+Ayzi/j/IryAcDV5UXA9eWDgJvLh1Ttlq0CHuCt yB8v81TtK9pRPhS4p/we4P5yf9U+WR4YVugoG1Z1sOhQ+f3AY+VjA75CV5mv6mixWj6ecSLjZKBV 3BMYWT4dGFf+AjCpfDawaflrVUdlq8CI4lblC/yTC6PLRvjxzZYv9lNhfNlovyExMLowpWycXxRn ly8Ddi5f4ReyJDAuWB7CtLIJ/pjC9LJJ/oTiruWrw9izfL0/QZYHJoQws2yKP7W4d/lmxh3Avpy/ tnwP8Mby/cCS8kPAW8uPhdHjVQOTiod5rcCUwpyymf4WxT5vpL8F99Y2VDLCG1eDsiQwszCvbJY/ q3i0N4mxaU1elgdmFXYrm+PPLR7nbeXPlfnAnMJu3gzke5XN8+cXT/BmM3YO5yd5uwKneHsCZ3p7 A2d5+wLneK/l/I3+fNk2MK/w8rKF/h6F/cqW+C8tnuctCeNCb0lgYfES763+SwuvL1vuv6JwYNlK HoOHcVg4v9zrw0huKVvr71+80jsijGu9o/39C0vLNvgH3La4cgTjaMZxwGWVE4ArKicBV1dOAa6v nAncXDnLP0C2qvbdtqNyTvWIQm/ZVn9R4V1lO/2DbttTOQ+4v3Iho8wfqlziHyTXVo8uHF6212/c dqxyud8oVcv2Vo8LYuGosgP+IaVW5UrGtcBIzkdyPq5yAzCpciuwaeVOYKvKvf4hslX1BOAR5MeU HfcPLc2oPADMrjwC7FyJEllePanwYY/Df09pV5/Enj5X9ZTCxz0uv7+0ty9aYulozscD+/pSgNf6 0oA3+tKBJb5M4K2+HL9ftqqeWerx5VXPKny6cLv//tJhvm7++wuneqL9YyWObFH4vCfeP77U5+sF HOG73D9ellTPCZaH8GVPin9i4VxPmn9y6WhfvzCO812PYwfl1fNCON+T7p9eOsE3kPGWcH6SrxQ4 xecFzvTdBZzlGw6c4xsFnOcbU72wdKHv4UBJ4SJPpv+F0iW+x6uXcG+zQyXLfU8DV0qUJdXLC5d6 cvyvla71TWV8viYvy6tXFr7vyfMvKN3ge9m/QOar15Zu9c2t3lC4ytPNv7h0J755oG9+OL/Xtwh4 wLcUeMT3PvC4b5V/8e0O3zqgy7fRv1i2rd5auM7Ty7+scKPncv+K26N923+B8b7d/hWF2z39/KsL d3uu96+/PcW3j/FgOJ/mO+pfX7jPM9C/+fb0eymMmfca/s2FBz23+HcUb/COY5wA3Mr5nd5JwL3e KcAD3pnAI95ZwOPeOf4dslVgSYnDOy+wvPCop9S/p4g8Xv/+Epd3ITCaMZ4xxbvEv1+uDawsMjx3 +Q8VGd7lEmW+JM27MhBZJDzD/cdK0r1rGTf8Ip/p3QrM8e4E5nn3Art5D/iPyVaBtUUxnlEBtSjB MyZglfTyHgFe7j0O7FfhAF5f4QpYRamehwORJQMZb6mIDmwoauF5PBBXUloRz5jCmBaIK2pRkY68 tyITeFdFDnB4RZ4sR/2tJaMquqFkTEWvwM6itp6nA0klD1dcDny8ol8gqSjLM9W/WmJgb8nTFdcH DhTlep5H/akVA9FDbsUtElGyNVgewnzPy4GmRT08czG25ytKgS8zzq3w4puR5UdK5lfchdmT80WX euYHWpUsqhjOOCqMSyvGAN+veBi4quJx4LqKp4EbK6YCt1c8Hzhesrvi5REO9LMokFGUWjEX2MOz FHiF532Mc1/FfOBBiVyytai/Z1Ugu+Roxf9j7/uD2sjuPF83stB4GA3DMAzLEMIwhCGEOIQ4hGMJ cQhDGIYhLCGslxCsoX+quyWkVqslGyGEJMsO8VGM10u8PuL4WJ+PchzKcXGOwzkO8flYL0sRinh9 rMtHES/lEI4inENYn0M5931PEoN/JOOt2v9261ufb7e7n16/H5/3/fHcbV95VOPrAUhbnde68xij czKQbGmx3+wuZZKcM92l+DyQZmlxwhWLxX6b9Cuq78TPmRTnEuh05yroLOc66FznA9AFKgJdpBqh 7/i39y28/U53hUWxL3VXMSVq0mO6XE3prrKo9tXuWovXvt7dwFQ6jmKtpm/pGjWru8Hitz/obmbq 1VzQTUS3qAWgLWpRIBPHJIEchldLID6B2CCQzyhqedcSo6qVoL1qTdSDB3ZhPxjYzfjVen8WE1ab /FnYEwXKmF61BXsl1QIafE1gD9Ov8v4SZkBVwL/AeglUM4Oq6l/EvA3UMUOq17/JDKt+0CNqOMqx QCOe38BeZlTt7c6z1Kj9oGEcAm3MmDqAx0QdBB3t6bg6BHpCHe5uIB7nrry7Mwm8D7b8K3JZZ4pf kfd0poOu7syK2ed72ModvC/Xdeb6h/Zd6iwAje3MQ7mxswjbnM4S0GBJIgZ5b2c5WI+2zkr/HGH+ AjOljgRYZlYdDUjMnDoWcDDz6nhAZxbVia7bzLI61XWHWVNnAz4oMwdlNtT5QJDZVBcDh1laXQ70 sSZ1LXCMNasbXav76tRNfyWb6qIDJ9gMlylwat9el9lfz2a7UgNn9uW7MgLn9u1yZfuz2DxXXvd1 ttBVGLjAFruKA5ei8QZb6ioNXGErXBVdMziiCFxjq1xVgUm21lWLZ8HVEPfsbIOrmehW0M3Qthm2 1dUeuMm2u8TAbVZ02QN3WLtLCyyxmutAYJU94AoE1qMx7Xu0KwJRXDSOIlEKG3AdgdiVxI1sxHUU 9BHXcYjiMDcevNfuAs0edZ3uQexx19keI3vSdb4niT2NS+4zuC52rbNnXZd7UqKRm2XQdbVrhj3v ug5rnMSo7EXXdNfSexmuG10P2MuuW/B00bUA43DVdRf0ddeKP5eddt2DGOys6z6054brIehbmiHQ Z9nQdkL9C1pyTzp7V0sLzOAR6MliV7TMKLd7ctl7Wg7Uc1/L95ewD7VdPQWcQdvdUxSNMLmdWllP CZes7ekpx+uip5JL06ohSodYvacmqrlMrS4agffUb9NNRLeQp1iI5rkcrbFricvX9natcru0tq51 HFH3KNxujY2dq0R78frq8cdGEuLhnjDRvbhVPf1cmSb19EfPiR7g9mgOfwpXrekQD0NU3DPI1Wm+ aAzcM7RND0OkqvlzuUYtCHov1jhq7RmJaq5NOxyNVHtGOVbr8xdxknYMNFyHKw7tRDRqDez5QPeM 4VXfM070RFRzunYKYlGISHumOJ92BiJPiEt7Zrmgds5fzx3WLoB2aJcg5pzWrkBsiedlLqq5Pu1a z3x7jjYJqxtbZjN3TJsB75mj3YTzE9rtnkVLlnYHewRtqWeZO6Wtdt/jzmjrPWvcOe1BzwZ3wY16 NrlLbmOQjtl2Yr0tLe6koIm74k4Ba+x1pwfNUUvIXXNnBVO5SXduMIObcVYHs7mb7oJgXjQGaJfc ReALiJfhbmO7HfXR3B13SbCQW3KXB4u5VextuXV3JXg9sFrB0vYZd02wlHvguBGsaD/mru/O4JG7 KZgR88tn3C3dZt7otuBYws37F/kkt4J9ulv1b/Ipbm93Kp/u9sNzb7vD2H+5wQbyWe5+uJ7rHuhO ZYrcg3FPwRe4h4JVfJF7GNoGsURPCl/iHgnM4N4Fa/ly92jU0nbf4CvdY1BPjXscvAD43GADX2+/ EGzGfirYyje5J4LtfIt7KijyFvds0I7HLaiReg7wvHsuGOAV9zzkOGDDg5FotIN1oC2q41GNXQ8e wTp6JXiU6OO4DcGTRJ/mVfdiN8173cvdJt6PoxEcmQTa+LB7LXoO/g40/Ap8QfAstrrBs3yveyMa VwTPxzT0ItDI97s3wV+Qc9Kvs/yATndn84O6CSIKiCuCF/kh3RyNIqBVWzp4vP2MntpdyA/rGaBH 9Oyox4d6QAcv86N6XtTLB6/yY3phdzE/rheDhutwZUIvjXr54PVtehr7qeANoo8TfYuf0ivAd4MH Dy7ws3oVeGrw48G7/Jxe213Lz+sNoBf1ZvBi9XprdzMZ8xWi78VGZllv7y7l13Sxu4rf0O3dDfym rvkXBVo/ELwvs501kZ2y1FkfrpcdnU2g9c4Wf7/s67T4eTnYyfuN8uFOJZIMZVS429fpjaTJxzr9 cPdEZziSKZ/q7I3kyGc6+yEbOtU54O+Vz3UORvL3Hesc8vvlC53DkV3ypc6RyG75SudopAw85ph/ SL7WOR46LE92TkT2yDOdU5HqaHawb7Jz1j8m3+yci9TJtw9ciDTKdzrnI3vlpc5FyOOWOpe34vDV zrVIm7zeuQHnDzo3QxcU5KMjrGL0mSKSkuQzRxxKii81oivpvoyIT8nyZUeC0QxUqvXlQc4VzXRI TqHk+gojh6NZnlIAV1SlyFcMORf4+kifdNpXGumT830VkWNKia8qckIp99VGJKkQl9zX52vwe5VK X3PkVDTPso77WuP5bDTHVGpIXlkr3cUZn6996+lnfSJokisp9T47ZEzRHOch5JjjSlPnWk+5VOHT oP4W34HIGcXiC0CeBSMQOafwvkgsVjmqKL4j/iFF9R31zyle3/HIBcXvOxm5FM0HlbDvdOSK0us7 G7mG45zIpNLvOw85NWTWkRmibyoDvovgNSCDBn8BOnIb626SU0fu4KdElqJaGfRdhh4NQc6lKsO+ q34vzn8jq8qI73rsfJ3oBzheOoRiIwnZ6yFjTEOrDiUpo77pQ0nRc6JTlDHfDf+AMu67Bdkr5LCH 0pUJ30I0Yz2UtU3nStd9d2HEpnwroGexxjlmYG9UK3O+e9G88lCBMu+77x9VFn0PQcN1uLLcZYjm mIeKtukSHMUdKie6MqqVta6dkDlC/nioRtnoSoY8EbLIQ/XKZleaf9ZGd2WCNnXl+Ods5q78SBue l0NNRLfs6+vaFVm1pXbt9o/ZMrrK/FO27K49UDKvq9rfIpj0QPAhyR2IPyK2C3IWwaxHQgYhVT8S 2mkx6kd7UoQM/Tj2HfrJULKQjTWcnw6lCXn62VAm6PNbulC/GMoRivXLoXyhFH5liuZ0QoV+NbRL qNKvh3YLtfp0qExo0G+E9ggZ2H4SfV9o1m/1rGFrGaomuq49qC90pwqt+t1Qo9Cur4T2Wkr0e90L gqjfD7UJdv1hiCVawnYy5IjlVqBDuqB5DCFfNM8SDnh2hoJCwJMcOixEPGmhPuGIJzN0TDjqyQF9 3JMfOoFtZugU0WeEk55doXOgd3fTwmlPWeiCcNazJ3Qh6lOE857q0CXhoqcudEW47GkMXROuevaG JoXrnraecmJFTcK0h/Xzwg2PFJoRbnkcoZvCgkcP3bYoHl93lXDXE+yuEFY8h/2jUQ+FdeiOxQ/e EM49fcED0ciNS/YcCy0J9zwnQqsW5DkVWhfue86EHggPPeeCD4VCz4VQjmjwXArtEnd6roSRmOy5 FjaKaZ7JcJKY6Znx94s5+vFwyvbaxHzPzXC6uMtzO5wl7vbcCeeKZZ6lcIG4x7MaLhKrPevhErHO 8yBcLjZ6UbhS3Os1hmvENm9SuF5kvSmgJW96OCWmHd4s/6Koe3PDTaLPWxAKikFvUbhFPOwtCVvE Pm95mBePeSvDinjCWxNWxVPe+rAXz2/YL56xeMNh8Zy3KdwrZnrB5osXvJZwf3TuxEtePjwgXvEq gT7xmlcND4qTXi/oGa8/PCTehJ8Oi7e9vcFUS40XMizxjncA9JJ3MDwirnqHwqPiuncY9ANPWXjM irwjPfNWo3fUb7QmecfC49YU73h4wprunfAr1izvVHjKmuudDc9aC7xz4TlrkX2mp9xa4p0PlVnL vYvheSi5DCUrvWvhxehTrDXejfCytd67GZixNu2nw2sWo5jv37C27DeFNyzl+83d2VbL/tTwppXf n3GQtir7sw+arKroO2iyNO0H72z17i88CLHc/uLuZqt/f+nBVGt4f8XBDGvv/qqD2db+/bUH84Ti /Q09a1gfLIxm/daB/c0Hi62D+1sPluLo5WAFjlIOVuFdlIO10RVHdjCOxHYqHl0dV2J7BWRn4GCD dWh/eygf+/eDzTgHP9iK2XiwPbo7ROzDfeuwfhzqJ5GYdWS/2H1DyNtv774R270h+yrWUbvjoCjc 268dtEezfuvY/gMHNTzXgUZEo1epNer/IkT9ltpANPWA+h0yUL+nKWSkd9BG9Bz9PJ2EnqeT6ZfQ C/QrdBp6kc6gX0Mv0Tn0G+hlOp/+OHqF/g79HfRqQk3C2yh9R/WOL6OMHeoOF8rc8dMdP0VZZhD0 UXO2+V2UbW4wt6J68z7zQfR18/vmn6Cg+bp5Bf3AvGreQDehNX+GDOR/PzCjF9Fz6CXUhJ5Hzagd fQWx6FuoFf1H1IfCqB/9HEXQP6BfoEn0T9RO9L+oJOoF9HvqReoViqLwN04m/N4k9SrVQglUJmWl IlQBdZg6RtVQx6nvUF+j/hv1M+rrCd9P+D6lGzSDm/IYAoYgtd9w2PAtymd43/A+FTB82/DXVI/h u4a/ocKGEcN56puGi4YfUUcMPzH8hOo3/E/D31Lvk+8xjxlmDT+nvm2YNyxQf224a/gVNWj4teHX 1CnDbw3/TP1n/BYddXrHyztepv7rjp/veEgNG3cYc6kbxjeNb1Lrxo8bd1G/NX7OWEb9Dn/hQf3e +CVjFW0wVhvfpY3GrxhbabPxPSNLZxp5o0pnG91GP/1J4zeNffTnjP3GQfrzxu8az9C1+MsJutE4 Yvx7+qvGaeM07TTOGOdo1XjbeJvuNC4YF2if8ZfGZboLv49F9xh/Y1ynI8YN40P6cCJKfIF+PzEl 8RX6u4mvJr5B/01iXuJn6fOJX0xU6PFEV+JReiXxrxL/KiEp8duJgwkvJH4vcSThZfz/qia8mvjD xEsJmYljiT9NyMLvAyXkJf5D4lzC7sRbiXcTShN/lfjPCW+Z8kwXEppMv3nu9YRfmH9n/p0Bfy+n oMOgk1AW/tq48nwMJkAhylPaa+4rYlXN2zerihS7oikHahaUgBKpUhr6lYvKZeVq1ZhyXZlWbii3 lAXlbt3OuhzlSJ2uHH2r9i1ROa6cVE4rZ5XzdTlvVQGrDMDxNcLx3yKK+j31e0QDo5NRAtz7CHkT FdHfo7+HKPr79Pfh3nn6ByiB/jH9Y7SDvIlqpH9G/wyZyJdgz9E/p2+gneQd1CTy9ukL9C/oXyAz ee/0RfrX9K9hdeA3S1MSqARq638N3pFgRGnky7H0hLSENPQnCekJ6SiDvCn6WkJ+Qj76CPkqLCuh PKEcZZNvwF5P2JPwRZRDvorJJe9sfAzan0SlkJHDGsnXkE++Jk/KM/JN+bZ8R16SV+V1+YGC5HXF qCQpKUo6QZaSqxTIq0qRUqKUK5VKjVKvNCktikXhFUVRFa/iV8JKr9KvDCiDyhDBsDKijCpjyrgy oUwps8rcdrE1K/PKorKsrG3JhrJpo22mbWK2pdoybNlwNe8RabXlQdlCW7GtVNmMi63CVmWrBY2l wdaurNlEKGu3tds02wFbwBaxHYE682xHbcdtJ22nof/Uc0rMauBv1l8iY5IOkoAyQQwoD72JdqBC kET0KRATKgN5DpWD7EQVIM+jKvQWebv8HbA6+LvLF9FfoBaUjNpAUsDusOhlJIKkIhfSyBeXB8i3 lt3kjfIQygB79D56DX0b5CPoP4Fkof+CzqCPou+BvI5GQHLQj0DeQP8dJBf9GORj6H+ga9C+SZB8 8r9hfxzNoX9EBeh/gxSifwL5JPolyC50D/0G2n4f/T/0afQQ5DMUTSWi3dROsH1l5P3xPwXbl4zK yfvjFVQW9Tr6AvUG9Qb6EvneswqsYQP5orMFVVPfoCzoy1Q71Y7eIe+S15GvO9+lFEpB9VQH1YG+ QrkpHTVQXVQQNYLtjKC9YD2/if6C+hZ1BH2d6qf60TfI151tYEkvoX3UGDWGGGqc+iliqQnqbxFP /R31d0ik/p6aQlbCXxmsQD5STAWmAtRB3s5zmD5tKkZO8kaey1RmKkOaqcJUgdzkSyKdvH/nMVlM 76H9JsbEoE6Y27tog3C/BP/LEtIoYAwwDpgATMUwG8McYB79uTQmjUsT0pQ0K81J89KitCytSRug N2VaNoGY5VQ5Q86W8+RCuVgulSvkKrlWbpCb5Va5XRZlu6zJB+SAHJGPyEfl4/JJ+TTIWfm8fFG+ LF+Vr8vT8g35lrwg35VX5HvyffmhclgxKDuVZCVNyVRylHxll7JbKVP2gFQrdUqjshekTWEVSXEo uuJTgiB9yjHlBP4fRHe077CCE/yGuY38+wpv/avx+12QFwnLkwnLXyIsf5mwPJWw/BXC8jTC8nTC 8gzC8tcIyzMJy7MIyz9KWJ5NWJ5DWP4GYXkuYfnHCMvzCMvfJCz/OJoCKSBc/wTheiHh+i7C9U8R rhcRrn+acP0zhOufBa7TqITw+3OE3/+B+giVBbzHzC4nzP48YXYF+T7iC4TNewibv0jYXEnY/CVg cxesgW6qG9YA/kriy4TNNYTNtdRfUn8J6wFzuo58H/EuYXM9YXMDNQU8bqSmqWn0VdPXTF9DTaYW Uwv6mslqsuLvtZMDyb0wT0kw9s8jytkGvCsGlAIqAFWxa7WABkAzoBVfM7wk7XaWyLN/HKTMnHpD KnOWS3uclfL8o8DXpGpnjbwIWFZvYUh1znp57Y8Dl5EanU3SXmeLvPEB8J+lNqdF3nRaFFpdkFgn r5j+OEgZs3pXkpyKkupUJIdTJdCdXiUDkK3ayXmeuqIUqvckn9MvBZ1hpfgDkD+Xqvelw85epeJD UKU+VGpdBqnP2U9wzDkgnXAOKg1R4HPcN6X5A5C+nnIOKa3OIXwkOOMcVto/HLicdM45Il1wjiri o5AuOcfi9W6HdMU5rtg/gHTNOfEscLTpJ6RJ55Q045x9Km465zAcrH4KQ7rtnH8m3HEuSkvO5Sew 6lzDcEiuPmndufEscDj0M9ID5yaGjFSawKiaMBy6fg4fO+zus7JFbZeTVLOcoqY+DodPvyCnqxkf BkdQv0TqyFKzCXLVPLlALXwERWrxEyhRSx9BuVrxzKhUq+QatfYJ1KsNcpPa/ARa1NZHgPv9DFA0 106ZV0VZUe1PBdxTDriSlYArjZRTVe2Z4FUPyH418ARwfRHAEVemHFYjzwLlqCtH7lWPbKFfPboF fP844KQrn5yfdu1Szrp2ywPqcdLex6Ccd5WR80H15IdBuejao1x2VT9Sx5B6+hEMq2efAP7tVVed PKKeV667Gslx2rX3ae35gxhVL8pj6uUnMK5elSfU609gSp3eDuWGqy1u27fb4rit3LJxt1zslg1a cEnb7cgWT7bPa3xe4mN01+XYGtsVl769TcSWHAabAmvf0Re1AY5j0fVL1tUJNYP4DeC74xTgjH4l zmfHOTjCc/B95Z7Lp9x3BZWHrsM2g6sP+xfbTtcxfB33zZbsOmFLc53C9tWW6TqD7aQtx3XOlu+6 gH2AbZfrErbtpM/Ad9tu15W4fbaVua7Z9rgmcb9t1a4ZPBa2OtdNbDtxnQSNrtu2va47tjbXko11 rdok17rN4Xpg0zWEx5f4IDyWMIY2H/jJmD+zBcH/xMbZdhjq6dOMuA5y75iWZDuhpWC/s+Vrt83R Vp0YMZ8S9wW4Tdg32k5p6aRtZ7Ss+DyT8tj2w9wTvww+j/TtnJaLr9kugA8viwL7azy+j6Au6pex vyL+GJ4T98X4SAD8IX17zMeSZwFsl5x+DOxj4341DtsVZz/Glo/EPjPmG7f7ykd8ZMxPxmG7Bn4Q 5pj4PvCHtknnGAbhLfZzV6LYslkA24xWQI43tSLbba2EXAf7YbujlduWtErbqlZjW9fqyXW8hrEv wesW1hFeT7YHWpMdaS3YFtmNmoWsi/g6iNlFwi2oB9s5exLYptgaIfMFdgv/Pm4Dn1hbj62rLfsS bz/Uge2mPUXj8Zzb0zVl6/e4PKw3e5am2nM1L263vUDz24u0MLHhuD/QB3uJ1msv1/rJ7z7M/sTa Za+M2fH4Go9sKxNrM+nrY/Z4qz/YDsfxh571B+ypvSZ2rFfP4z5t4XE7ud1WYvsYt5HbbSKUJfXg MvgejIG9yVXnuKBfc1zSJzFwbIPnm8Q1V/QZcg1sln3WbXZc02/G4xfHpH7bHtbGiR2DuMMxo98h MQXYNPuItmz3a2PxmMBxU18iNg37fxw3YFt3W1/FPtpxR193LOkP7OPapmPVgxzrHqPjgSfJiTwp TqMn3ZnkySIxWcxekt/i2CwWN5GYJx6j4LpideB7zhRPLraXuF1bsV08Dlv/wAYTxGOYWOyB68Lx mDPdU4DjHWeWpyj+e1Ie+kP+DONF1gn0zZnrKSHXcNwYRyxOfASPx4Kx2O8RxMb18bhuCzgWi+Px uC4eoz0lNnMWRPGhsRmOvbbHXzjmisdd22Is3FbyW1wmNiZPrC1Yf/YWbeCJdWXRBuMxlp3XhuyK NoxtUbycXdVGMK/tXm2U8CluB3AZvOaAf+TYq03Y+7Upcj6gzdoHtTmM7evNPqTNYxthH9YWCT9H tbUn4hiAfUzbIAA+YpB1iO3WhJsmxym3Kb4G8Zqwz7lT7fPujK31h23Qojub2Jpld559zV1o33AX Y98TB+4vzrHI+oM+2zfdpR20u4LUDfajw+SuIv2Mle8wu2s7Ut0NHRnu5o5sdyu2RR157vaOQrfY Uey2d5S6Nez/iA/E9gligo4K94GOKncA2+OOWneE5CzgCzsa3Ec6mt1HO1rdx/F4dbS7T3aI7tM4 T+jQ3OfxOHUccF/E5TsC7ssdEffVjiPu6zgGxPY/bps7jrqnO467bxBAfdjPYG53nHTfwuPecdq9 0HHWfRfzrOO8e4XYMJjHjovue+TeZfd9UsdV90Nsyzuu64aOaX1nxw09ueOWntaxoGd23NVzOlb0 /I57+i48vh339d3EjuH+P9TL8NFh0PdgPjh26tWOZL3OkaY3OjL1vVv8gRgcxx+OHL3Nka+zjl26 RK7HbK5jt+5wlOk6mT9YJ449us9RrQcddfrhLa7G84C4j4JzR6Peh8s49urH8DVEI8ocMfcj9O9/ g/Jv6G9QVtC9D/4egN1ACpfBZXN5XCFXzJVyFU0Groqr5RpAN3Ot7EZUuGwMrp0T2c2ocHZO4w5w AS7CHeGOcse5k9xp7ix3vqmPu8hdbrrCXeWuc9OcOSZHCW5wt7jUmCxwd7kV7h53n3vIG/idfDKf xmfyOXw+v4vfzZfxe/hqjo4LlKjjG/m9fBtnigrP8hLvgHI6aSFuES6J7+HnwRPwPv8LZ4Hbb/+r 7IO+C2vjKyAvkX3QFLIP+jLZB32F7IOmIRFJ6FWkgGSQ3dDXyG7oR8hu6EfJbmg22Q19neyGvkF2 Q3PJbujHyG7om2Q3NJ/shn6c7IYWkN3QT5Dd0EJYc1NoF5oG+TTZDS0mu6GfIbuhnyW7oSXol+hX 6HPo/4CUkT3RPyV7op8ne6JfIHuie8ie6BfJnuiXqCwqC1WRPdG3yJ5oNdkT/TLZE60he6Jvkz3R WrIn+g7ZE62juqhuVE/1UD3oz8ieaCPZE/0q2RP9GtkNbYaV/kP059SPqB+hFrIn+nWyJ/oNsie6 z9Br+BaykH9psN1wyfAjxMK6nkC8YcnwKyTC+t2AsaSQF/k/4CoDPWZuMreZO8wSswqyzjyAgTey SWwKm85mEeFZhVVZL+sHCbO9bD87wA6yQ+wwO0Ikly1gi9gStpxIJdE1bD3oJraFtWDBvKE/Abz5 ZIw3KeT5mDE0zNGbwB7MFQOMfzGwB3PFSLiSCEx5CziE98yfA3a0AIcwP54n/Egi++QvQL9kYBJm QzJw4X3gE+ZBCrDgDPAJMyAV/QDkFcKANMKAV2H+rwFv8X74n8Cc/yMwDM/6a2TWM8ke+Edg5pdR FpnjbCoZ5vh1Mrs5ZF7fIDOaS+2jLOhjZEbfhBl1oHxKhxktILvcn6COwCwWkln8JJnFXWRP+1PU D6lLqAhRphJT+bb5KDC8xBQ8LuwBNsAUMSVxYfOY8phUPi5shKlh6qPCHmGamCb2KFx5TNjj7Emm BcQCwmNhT5OjwqhxYc8y3ieFPU9q8DL+mISjwl5keple9jLo/ieFvcoMMINbMoTLxmQ4JiOPi3XE OsqMMmNx4deY8ZhMPC7WMWYq/izrODMLMgRXHhNuN7PBzIHg581jEfNZMxwXyS+IcKtP1s5MiNWk hon4yDLLUbFOMGvMmnUY9MaTYp2C/m1uST1Lb4kpKk8ZqevsNGtmU7fkBptB5NYHIxEXdoHNZvPi Qmb8Llv4mKwA7rHFREpB7seuP+QMoCu2elTP+LmdbNWTwiWztVwa28A2Y+Ey2daocDmsHa60s+1c Ptu+rZ4t4XYxy6y4JXZWi0t09Jl5mBHgN1dGuFvD7eGqMce4OjwSXCPmB7cXztpIbws5lpNIiyTS 12hNmCmzZJamrHPWecKGRTL6y2SkVzgHrJ0iGL8SppzTmWHOB6Ns5oLQvsNcH3DZwh0Dvnu5EyzN nQIu97cf5s6wpfDcPuBJGMqe4y5wl5hN7gp3jZuEFmP+93MzpJcWmLHrTJi7CSXqudvcHagLr1rS I1Iyulbw7IaZJm4J2r8KfV6H671QrgRWXS/3AM6KuDYeMeW8kU/iU/h0PovPJWu5KSp8AV+E1ytf wpeDVPI1sFqV6Irl6/km8jR4Et/ChHkLXpM81AwlFV7lvbyfDzMDfG9s/eEVOMz38wpwzUz4lgF3 B9hatpQfZDP4IX6YH2Fb+VGYX5gtro8f48f5CRi5QrYK2jTATvNT/CyUngOZZ4v5McJA3EsyV7gc CDAGjxK/CFhmq2AN9/MbcF3jNwWanxdMAjxbSBUyhGwhTyiEsZaEYsx3oVSoEKqEWqEBcxxGlsy5 0MzlA9tKhVZeEdpBRMHOVmCBe5pQLByAHtSyzXAnwLYKEcxT0O3CEeGocFw4yecKp5ll4SwrCueB j3bcN+GicBme2Q4M1XD/rGvMqHVDZMEyjFs3YX7moT9VwJd+iZZMYAWGJTNYigl+QFiRUpl0Zqx9 UmiQMqRsvK6BMzBaUp5UKBXzw1KpVAEMxZZjA6wZHp1h65h1LFqC6RdnpCqoC9s7wmBSMmplgMFQ 16xUywxIDcyI1MxMsDSUG4P2rEmtcDYqtErtzDhXJhSLZZIo2SWNWMGYJZMOWIllFUqts9ZZKSBF wM4tRm2ddEQ6Sp4GT5KOM8vSSWzNQK9JJ6XT0lnpvJgmgUUXWqOWi9guk3VZuiwdYVulq7glwlWY J8ydVuG6MI35ExWuD9o9IdzANkm4BXO8wDbA7NwFXhWCPSgUVmCsTwv32ArhvvCQqRcNItgdZlFM FtPaJ9snxUyYwdPAmzXGK+aI+eIucbdYJu5h2/l5PO7MKFsqVot1zJrYKO7lF8U2WD29YGAk1g7P nwf/eFfcAyvYDDarHe44RF30sRliUDws9onHGD9rEk+Ip8QzzKx4TrwgXmLN4hWo1SxeEyeZOah5 XpyBNpmhLTfF2+IdcUlcFdehjVNQt4lZg5IPrMhqZHqtSWBtUmAt1QNv0uE3hcCVUmsW8HfFmsuM iPnCirDC9QkLzDw/ay2wFllzYRxoa4m13FrJT1lrrPXWJmuL1WLlrTVsLRwVfsOqWr1Q2i/2CdPW sLWX1az91gHroHVI7LMOcyyJpj757xnmv6EMU0QO8lZDGv7fZCzDiHqPRqmW0yBnQc6DXAS5bLnc AmK5arm6b27fnOU6yLRlmly7AXILBF9bALkLAr/bu7p31bICcs+Cc1jaXG/+CjwjmWQ0iGQ0NMll EkjMayC5zA6SxRhJzJtIshgTyWKeI5nL8yRzSSIxr5nEvC+SmDeZ5CwvkWzlZUQls8l20ify3qFl N6IsdXAsg2Oj4aWaM5bqZ0FtLRzPAS78AVyKorY1iporz4hrgMmnYCaKWg2ON58NtQE43o7hTgxL Ubw9Hz3WHgechPNVwPqTqD0LxwcfjtqLgMtQL4rBCEh6FKRvj+HtlMeQ/i9AFiD3KSh4Sr0YRY+h 5NlQD+P+djmg8g+gJor6m1G8Xf+MaAK0PAWWKOph3t7mnw31MLdvKzGoMXijqF+KHt9dgOMswA8I P4l64MDbvR+O+vVYHf0xDAAGH8PQUzD8GEb+BRgFjD0F44CJp2DqMcw+G2rvwnHOQtbHUwH3alcA 92LlFp8Ry4C1p2AuVudDOG48G94xwHHzA9TSH2CrTHLsmAbIhHumD561He/kxJ5v/nC8kw/4/+yd CXTV1bX/f/c3JSJcKUaGEGhMFZGZgBSQB0oZcwcGQSlSQUSKiDZFioo8BEQbKSKxYBFlKKWIMSAi IFMAKZMUmcqkIk2BAgUMChGQkpu39+f8gpFH11tvvfVf67/WeyvrfO9mn3322WefffY553cHGn2/ fVbKNSX1OkXbNpfXdHltHbzec317/lXJqiOlwXVKppSW1yltv18incrl7/L5tixfBnksEh1wNb9E eg74fv4oi5Py8xr4+6qP+pTz7UPft+lqTimfA8rWcLC2dM8oi/lu1a+J6QumPjJIylAp2SZH6P4S GW34OqbIeCk5Jr8O0PmSPBmZKmWG2QMic4L8ftnEe0R8UpafI7KnRZaY8UZWBH4QnZovVSdF9cp8 RiQvRsR3EbEhonpPBv4N/Klt2SfL9rAj5fwseqKW0aF1UdkvohUDu66dp2vm6OqeUjZPOWZvjFYx tkWrl2t/2YyFfy8J9j75d7R2wMsvV1Zcp1y7L++6Ttlfbn8tt8deLUXlyjX769X98n+yT9Ye8P29 sN6A7/bAcvvd1ZwlJdo+eJV9KxoP1pjkj6jsSVHZg6Ky/0QHB3xZw7p/sG47mfUUlX0mOtzkougz wboI1kFZXtTYUj2a58hPZWskx+QtbX81B167tq5ZV2X55eraygnsnxDM+cTv2iMv6y0qe1P0dWN3 VPakqO5Bh4OcpGOQPSi6KGj3X+Wga/P49WTKbL5OPr5al/xd+Ze57r/Kp+nfL/8pT5bPlZnlcmS5 fIhseiDT0vhAc3Q3iZ9u9UzRs43Ot55pujUJeBIrsQ5Cax4Lzi/d5GwUvRDkMZnTbhpbE0w+i6nv 1V/BmaBblyCX6f7/epDnNP5kj+4m+rqJvpjY203ippvo6yZx1k11Sox1GxPkz7J8uSg4m5Wdm4Z/ l0fRFejAxgkmX2LXtXn4mhx89QxTlod1nKpL6ySmuk0p135iMJ4Wxl+cuWRs3V4PeG3KlS7XKdee BQdcpwR+vfZcd7WMKVeuPdeVndH+J2ezpQO+f/5aP+C7c1f5M9aAoO2qcj65dm3J+otuH/Cf1lV0 z4CrZ6yoruvDJhddzVfHTFxHTwXxVMZXmQtB/Omr5JVYsO5issZiYVPKr7dYiskRsVQTn7E61znH SIk1CEqmKeRB1d8yeG373RrUNRGTvS7Wvdz6E7nY/Wa9xWSPjg2UMsTsPWWFfJRn/KRjjj0pZUSg W8YRGxWMM5CPyZ0u9pKUSVJeG0Auik2XIne42DwpeWb/00KelDNBbLGU5SYfx9aYONW9MLZBylYp OwJ/7ZXymbknxI4bP8XOGPmY7B2xS1IS5gyo+b8sN8dlD4hXMEX1sc9IbMcrG7/H5QwaTzNxFs8w ftR5jNcN6hoFOpqbXB6XM2JczodxzT1yHovLOSwu56q4nKfig4x/40ODPCbjj2cHryNNPMTlLBSX M1Bc9oj45O/iR3O3ngfichaKy1koPifgBzk3LueBeL7Rr+skLj6KyxkgvrZcrJbdA8r2KKHjG41M fJvh6acxKm2otOn/Po3xv+lZmVvP3ajvqNrbrPcsKyldSh0pDaRkSmkppW251w5SsqR0l3K/lH5S BkoZIuVJKSOkjJIyVspLUiZJeU3KdCmzpMyTkheUxVKWS1kjZYOUrVJ2SNkr5TMphVKOB32e+Rev 56RcCorKJywr2TX85ApSKge2nQleZQzJVaWkSckw/KuvdaU0MrYmN/9uzMmtpdwjpZOUqNGT3NP0 l9xHykNSBgX8oVKypYw0epNHSxkvJUfKZClTpcyQMkfKfCn5weuScq9l8iukrA1e5wTt1par3yhl m5RdUvZLOSTlyHev6p/kk1KK/huvZb4oNn787xbmoHzpborqZ74KA9mT15TL5r+dL3sta1+m9wZf SsVgvoV/Q5XvXm+oLqW29V6kSyQe6RXpGxkQGUwZFhkeeSYyJjIhMjEyJfJ65K3I3MiCyKLI0siq yPrI5sj2yB75Oxg5HDkWORX5KnIhciVqR5Oj4WhKNJWSHq3DvxvIX2a0pZS20Q7RrGj36P2RKdF+ kQXRgdEh0ScpI6KjomOjL0UnRV+LTo/Ois6L5kUXy7+XR9dEN0S3RndE90Y/ixZGj0fPRM9FL0UT MTdWIVY5VjWWFsuI1Y01ijWPtY7dE+sUi2q98HvG+sQeig2KDY1lx0bGRsfGU3Jik2NTr1tmxObE 5keGxfKDvyXydz16hfytjW2MbRN6V/C3P3aIckT+TspfUaw4djluxX1KxXgV2RNqXPcXF6zgFxeS +cWFCvziQkV+cSHMLy5U5hcXqvCLCyn84kJVfnGhGr+1UCOcHm5q1Qw3C3ewGoYfCQ+x2oWHhX9p dQyPCD9rRcJjws9bPcITwi9a94Vzw6ut3uGC8FprbHhr+LQ1nl9fmP//sWWhUJVQNp9XWaX/m3xG ZlAks2S0DUqHoGSVo7XIqsm4P6BVrl9ADwzKkKBI1s2QrJshWTdDsm7GS4HspEBeea+V+/f04HVW UOaV6zMv+Pdiq37WNvnblbU/61DWEfk7CR7JKpK/4qzLESviRyqav6xtkSqR6pHakduEW0/4tSNN Ii2yjkTaRNrLmmRVZhXLuoxHBshc3cQvbVj8xobNb2w44cxwpuWGO4Y7WV64azhmJfF7GxXD/cMD ZR4eCz9u1QoPDz9lpYdHhf/dygiPD79g1QmvCa+x6obXhddZd4bPhM9Y9f4faw8lHnR/IthXoiOU uBG6AnRT6KbQzdwugs29EfAHwv8d9CTBTO996C7Qpm1T6O60bSzYCH5z90n0aNtM9Pdzmyl6D+pn n7xRQqe47RW9XwkuQWa29lsCXVKADePhPw7dDLoZdHNjbYCjwF8iIzpL/ubWFywMRlSf2gexipG6 rRjXY1g+RGnnIHQytRat3oHzBG0jcG6Cbkfbp9F2E5a0Az1kWiAzWLAJdBPoTLc1/KHQLdAAH2xG bSa1P3bvVvQex5LWSCrdzDmHjPHDJLStQZvORWN3AXyDLcGeyAxC53J0ijfsHtqj3dAbIPiiJ6vb HgndDjzoDRccozIhG5yGPHbalqIzGMlp3iOC89H5A+WEDigdOk9tLvIdkX8VOgVt58FC5C+7fxa+ 7W4S7Onu1V6UDp2FM9g9INhGZawLiqEs8FuwQNFxkOyKnt4qHzqKhgXQC6ntjHwp8vWgj4MbwGXI n3Z/IZJR709CX9K4tX1vndAJ5YcGetsEj7gSCXaqylinvXGC3yiGjgccQScTPalgGm0fBXPBam4p tQ8LvVPRPgS9BtwFTnP76Rz5p8HlYB6YAxYpJlWXvpqbGUTyRV9/Q2UgdDuwUoB5YA6obashuZHa xXAOwhkDZ46Zd6UFl4N5YA5YBKp8VyRH08oy6L2hUQE9DcvnQ68C5wecPDAHLAI7yFjWezlE0RBF ej8AnqdtboDLwTwwB1QNuXjjVZVxpoOvYvN5sBA9hWpz6LS3XbAYPO3NBLPB/iCR4J0RDdWYr0tI FoKnAhxHDGzQ2ICTQEMCDQk0JIiKI9QegXMk4KwSdBjLrd5GYmY7mA32B3crEgmFJsaUlkhTbbuh T8uZXm0Qjt06QBmLvUWj1E6DkwYnjdWdppoFN4GriMx8GeMoE59ongLmBm11XTxFzFfT/4lb+poJ ZoP9wU3gGVB1HqLtIbyxC227oKdBzw5QvbcNO3skqbZKBk2kQc836K1mZrOZR609D33a/zf1sEG1 yoIjd1rFVPi7mNldcJawRuqA6WShpuS3F/26gs/DP0EuKoZ+TXeQ0N/JaZVMPlTJUAXv54I3k80m gNXwxiJkGrAW9kH3ABcEOVD2lxD67SRFf7fOvv8b9YZHLnUHqE/8FUr7DZR2ThLbC4iTTKJ3O61W eEu0rbsIq7R2qMnnvmbO+oqyNveypvayjnR13A6dS+3fgzE+hT2Dafsu8u/iZzKMd1L9oyi5WtHM V0Nf9kd7JPKVoDciPybIHnnkgRzdHViDg+FPA38A3k4vB8DSpC46m0n59Ku1HXWWZeUqnRKg6rwr yMmzhK5OTO6Gkw5+5tfU+SXfziaeHyBvL9Us6u0hJneppFeX2EtWjsydxnCK5vPQdrOK5a4sOwLz skc9LHlgFTG2ilVpcBPrZRW4iR1Ec3WqthV/rqPVOFbQOOJQe/mVWuV01Vqnq8kqrpxVQrVY4+1p tcK/SH5Q+ZZqrUSyco7rSpcI36c7C5ZnBvlnHJLayzwwF9zg36G0/wort5vuMqzcQ9SuCdCsUKV7 +fWpPQPnDParh1v4uzXXYe1M3Q1Dn7AnpmJtCfz38Xkt6HTGckRPSnZ3V/XvcMOCJ/X0aNdQlPka R1bRWZvBGGfpWnOasg/eqeiku8KxP0bzm0ieR/Nfof8K3Rn929Xzgqo5C5ufVLQWQ58CH/AqWHqu UP13M1P10LDD7L96jpJzwsNkP43wiZxeTrlDGYXG24+onYHlu+mrAG2pOlL3L+oND5+4F5nfkbq/ O1VVm7NPafdu6E6Mt4hRXCRXXGQlpmIn2d5eoxY6zRn7DYG1akkGdANXzq6hLYz6Q1dOg6F7sG0r bYl2u7U7TNc4rXrpGdju5XwpONXtKJrbMo9L3UEan/abQu9F24kAVdts9NyFzkzXFTyqKFFXy9JT mXjAScIPb9NqODiFGDjpqvcWoaEu+Dv0xKF/xdhn4uf2jHEorU6Ah8DH1GNyytJRjNdTq9A3aFSw Bz2BtoHY2Qs9vve6ZoAgGnV0q7Hnsn+bonce3AcWwM8AszQnmDOnStpNwNbeAfYRpTuZUyh6doNb 0LMFPVvQ8znyg5EfrBw7G04bOHFzalXauqCWCO4DC+BnQKt8JXOypZcCg5yjuqKnq7a1e0P3NrTq ESyAnwHWgpNG/HDeQOdRtBWDC8CFYL6rO2BndHZGZ2d0dkZnZ3R2xkudVbNTTyWdenhgAxo2QC+D XqajEK/Own7FD8x4lRbbZqFnFq3Oo0E5LbHzYoDbWFlqQ0+vMatVZ2ecq6fN9cHtQHvZ5O5nzXI7 UEnLnOSPcbavwS2gC/gx2mqg/wK4H8ynbR+wE21XwD8BbnclSv0MHZefp+gOVRl3h7dSVjp9+cM9 3af64atsPPAt8mH1qp/Hum6KtbuJk6PglOCecoDZ2UxMHmDWDuAZ4lNXmXigjs6UV03wLe5ENpK1 kdwNPYHe25h4Yy7eUY7jMFMO/K7IHwUvggvAzZzkF/jH6UU5pTovMr9KHw+QuYZeYSJHORIJWcxg FjMu92hrgvMXuVfGvRsVfbm3luzUlViy05NZdt7kpLRNfeK20n3HfVRp533wt/AX6HnMnU1WRF7O xnou+iFtI5yLHkfyI71vuls0SzvcH53eel92K1P7Aa3+qJhUE35VNFwB85EfQJyM0blwlqlvncPQ ncFmim66zpGbQWzkIL+OiPpU0ZuHTDOiIlUlnZeZ2S+hh1J7J7XViZYOaDB31XywC32141Qwmx2w k3rMOcoOkkNu3MiusVnPJ84cTqST2YPmcj4cDedFTjVF6FkL7gX3gZ+i5xi4A3yavelT9tkVit5H 0GPAlWTXC+xBv9bzm1ufU9ynAb0czANzwCKt1ZuXdwr/d0WyItjK/6mguZFxQ3RWBpgH5oCq4X0k n6HVMuUIKqe7cryHiIp+nHWfBiNgNifD4Zw/O3En5QTr1iF+VtMXkk6O5lIXjqCO4iSabw9wOZgH 5oCizbtT76T+OmJmi1dVWt2ItjngIyD3UzeFsT8LvTzA5WAemEOtjutZ9ZVboHRSLf8NsI/qp5Ub oPqHO4KTr35w2nHqGx3gTDAb7A8SS3py8ysw7z9DspPmRu92b4vQZ72PBN+Avz/AbLA/uAlsrPFG 7WY4m+G8rGdd5z1doaF/5yxdG/w38GnOluncg1pxdm3AqXgyEfU0ETtZz4F2JzR/AP0st9el2PYF /C9UjxvB/sPKcWsGOBPMBvuDur7uUKvcH+od1n/bxLyuCPsY2m4E53BCGMs6SuH88Evi/y1qPw1w JpgN9gc3ISP+dG/VXryP9LmioMqspNVK6BQ8cAEvfeblsRZqa61BbqzH9cbqnlSOV6CWuMuhz0K7 xImL/GjvNLNgUG+vO/X2Kt7QqNjhjsU2jVgLeiWWr6TWZNG24I1eiqCl8+XV8HsIPVf53q1E8hfg s0Eu1cyzhlyai8xE5N9hxX3JOrqRjNqSDDwDerVmYIkraeWtZ142o5Pbq/Mamp9AW33o5Xr/lRuu 1mYjuUYxuUAjPNnitvU7NPPMJMlk+z9zu8lhhZ5iBS1jddwFcjt2FqLhbbRZ7ovSag16PlTbXJ5T udyIZS50D32Uu/BTSouGInAv67oI3MtqLQL3Yu0HQr9Cjyvw0hU9Azhvkp22gC62rdY7svsHcISi w5MTZ5v/ku53rOJc6GXIz6btK6z0HOX4QzQb+I/D/wj5QrA3OMe/oJjUV3c6ZP6okZNUE7oq2Axt V5Cfis0VdHdwq+hzKrexl0r8KG2rbd4ZnX23CmtntLlvEg/53laNE+W7R4M7tT6xzOOO04p13Vn3 iKQuzN0+Zupupf0KXiWpvcSetVJvxBK9mhM6aG1SF3aWObqaJF+tAjeRl1aBuodm8RypPvzD8A/D Pwv/GPxP4fdD2xf0Ym5eo9kZ94IrtV+vUEfk8zzWWcKNey573HSVt/+k92vJcv3x8EVs1rzUSu/a fiVWfRGre62ieHI7eaYxlijuoPZGzkU36slH8mEJa2EmGUNrx4A5QfbQVgfIG+v03i0yM+DPwH7y lf+80MuxuaNbU/D3im46/l/MSD9ndkYi80AgqZza3IM+1jG6P9A7ssNTZcfc2g5ya9tKTn4OP6Qx 7w25l71BtFT3JBf5ybS6yAnhPb2Pe0NduVm4k8mxT9L2SdpOgl6gfdk/pseBzMtsbv2DGNGvueHu ZUW4cF7RW7lbHzsfRP4resQqbwL0aL2bO7+ANjJPoKEF+DM9L8m5UVflSrea7gtYeII4N7fpe4mE zoy9sbNGxtVX9fgjwFGK7hx3IZlTV8RPlPae8Z7BKvVnL2TM+x0FZDNPa52ndBfzQuipjP9XYuEf 9d7tfAZ9Vm/rTlPoznpbd95lLDepJR4ryH3ArSGcWdg/1jkr+LwjkeCe0nd5/D9wJnxYb+syOrWn pt7ZnYnofCpA9WEl8AG9p3srwZ/qPcL5p47dr4oHsriDH6HVAL2nO7dAr6W2GHv+gYVL4H/Nexnp 6hm/Lr23Bfsz3mFgi+BsqbtqDVpt15u7/Re9uTu/xj81eH5YiIUPg1nMzsvMY0RnTaJX0F4IJw07 Z3CLyQXbGZobSi5rLZebTq7eqqRWbiLeHZyo1yP5ArjMe5F8qHQYjBhEQwQNETR0RrKIu1595bj1 4RyAM8OVGQ/R1r4NfIn78n3cl+/jFtaK+90beleSSBB5ewiSn9JjVc6fDdHWUNu6HaDHGYQzTrUJ FsDPAGuxs4tnvN2Mbqgrt0LnLXS2Qr8ZXVvwOb17iv2MAp310VmfkRYx0iL1lfuAavY7eHvAFzSK 0LDYIP4ZCN0FP7Tzo/hKsRv398/0/i6jiOqzL3c3/UZZQZ+j4TzaorpbqVWSeRTfdG8XfMgdL/xn yKjcl+V+rbUvg2lw2roThM521baGcMi3bi3m4kvwa0Vnm6K3Q9FtCI7Ttl4jerkFnV3B1uA8tOUY X6HhLFgXDz8LPqEZL2mLeiA5jj8vce97nKf0Tyid5LPrPay13h14eBuSHaAfVTppi2pLjuvJxEtw H2zFuExstGSWOzAvb0GnoKENMu/q8wFngPrfTWUWFhMbt+ou5hzX0TkLoStDj0HmMNiQVhlgCrNZ Vdt6c3XGvXnwmyH5NrP8stL2l3Ba+S3AqRpvSNbQ2ZQ4eZEcqLgLnfnQt2NzCj58TvkieQlrL7FC eae+9B0rZDmlH0Mv1PeywczSt6HvBHP0XfKg9h1wLvKjoA1WB3Phm7aLoBehLR/8As4X0AeREb7d o1SfiDYEXwRHgu3Ag+AYxZCtaBXDyQQtRWcw9DRwPviDgNZ3DQ7Q9jycXLAjrV6FTqG2ELwMh17s nnDOQhv9bej9Avgptd+CBWhzkOkK9oZ/NKDVhgVwFsLpDF1Kq3rQx8EN4DLwNJJR6EvQPnQCrA4e SdTTkyH2IG99oxzHeCYNTFVOiFGHHgB3wj8EvQbchYzxXo/EvaKhuZkLpe124CxwjpkF6EzQAqeB 8xN6Ol1v/K+c0HvgeWo/QfN0MzroasbzyCSQudWMBU4hVh2H3h2M5V7GlSxtR9F2tHIs/BN6HsnM RJxRzMDyGVg7A9sUc+GcB0/DuVXRMnQamAoeo8c6YDrYFDxBXyYCX4P+O5iaaC/YC/pmZnaCiUnl 24ugGyT09r0PujV8osJOUvSJNP9pRXclGkrUA/4TSnvbmOv5xjOlb+q7jcj/xsQG2l7DhovIfIuv euiqlDVVnfhXnGJmueScrjhGOjJAG0wXrAa2A8dQOwZtY5Qj/lR+J/iZoBVguu4L0NMCVMk43j4Q eD6dWZgFKt1R+c6r1BbT6i4sNBFezIjwf+gzMyOMdLaJZ+hByCzFS3tM9lBfuXvxmFm/KdBpeGYD 8hsS9+hTKeiR6PkV9ExFh1XsdCUCL+G3XGqZzVAt+KfVh6Er2OzjvVRGlIyXEooSV4bWMeKr0G9A E4cPB5hO21noUfmd6NxD7Tsg/rS+YtSnwJngJ6U3C5Ywxgpw3oeuBZ3OrHWH3oHlJ6mtobRkjAXC uYfap8AZ1M7CA0S70xTarPRU9Zh9J3yzIj4G30Tzo2h4FM37Ay8pbTLbdtb1RlbrCWaBrBJy8fzd 6DGZcAf4j9Jm6knobSYHIjkRyR+ZHEgvu+Gz+tyxrJ0t0BdLO4udZh+ZS7bZp75y74buBL8IPReh yYT2DWB9MMOsWWS2gB8G2ekuQXaK0FZklpoVDZIB7Kl4qS0ye0GTN4hbm31BvCp3Coe1H3obHA6a XFEX/B34K/gjoNuDQ4nAZ+G/E+wFGs/jA1o9YPaOfsiTQ+yBZk9hNn38Xx3MBXeCa0Dyeeh95qsU ejV4mba7zHxB48nQWejBYBwvXYCuRG0BdFewd+KCWgj/KDqngAvB/GD9mr408rcQ+RdYEb3BzvA3 QLdEfhza2HdCm+g9QWywM4bI5E4NJAuIFujQBbLxfuh8+H2gTV5l9v08Iqoy+AIZhvOJXxttJiP1 xtplpW/pe0xoKE38hvEKhjaDl8nDPckkC8GHkLxMHq7IWMw+lRLk1XRiWzNDGzht8F4bssoF+JXw Q0GAmnsdJLsGqBoWULswwHT2nWH4MB07NS+lU7sdXEbb7jxjLOYZfhpPGtP8D0SyYvDpGv10Sks+ k1PCs+U79VOOoZ2Kdh7v/27i7skTqtDfXf1kznpuZLzbYnfwb9SVzjs4O5S2P4I+5x7krsp7Xno+ t/radXRe9ImEU899THt3/6BnDKXtIvdrjUZF55w739LnSyJpHVIMDaFVF0Uvj2caPtjIHa1rEw0L XDn3Ov3QcEVr/V606gk25/MJl8BkN1Vn3HlOPeZsVBml7bH6DRd7mKKT7RxGm0haWxVDGaYVnD2K 7hlFGYXiXOcVHQV6OuhTBXuz0UNtH0VvPBougYfBieASR5/n1FO01zh6u0/Xe719CU4Vry926qfI KirH2qO0dUhR5JXeqvJeG/Sk06qJo5/fq+NM19l35mJbvj7TptUSsDWcuirvraXVscASre0DZ5Yz SrMN/LYB6ueI3EDbXPUSti1XOlSIPY4dUvSK9VdvoG3bVk5oLbX6CeRmoSN8YlY/1dbdnijYUJ+6 2GvsVzXr2r9Wy+0/6rpW2n7JfklwjK3vbtsqH8oFeyo6jyMzzeazjvYUwcbOy4LvQzdw3kaP0KHz SNLW7kjbV6FvRtt5jdLQX+n9sn2zrmVbo6KPXR07K2v827zLb/vCude+SdeyfYeuZZUPxcEeitY3 io6Dhi5o623X0Jxp70Sn0hfso7prQOcjGUVDgrY/hD4OfhRSDy/FhlOhH4lko5A+4ZS8KJwrIX2X uSRUrHuB3UTzqj2Wd+31l2VPhwrVHsXQvXZV5dgrdOcK/V33XDANbKQo2gSto9BTwCqhw0ge1pUO fSg0SncTdO4MzROcGvpc9yO1xDqBhm/UEvuKZemn0N2vFP0U6L9BV+LT6TdC/xj+e3BEj/t7X3S6 fcEO4BlF5yS4UNGrCP+Kou2Cr8Cpi8zPFP0DSNYDo9RmQA+E7oPkcTjw3YmKSbWh76B2HVgMh16c P0M/Cj0W7A5nPPiMYghr7bbUfgxdiD0+MrlgHrWboN+H/hLsBv4UPiNySmhrtG0HXwAfA/ch2Rya cTn/pMdfQm/Env3gKTh/QNsgWrVEchv8W6EXQc/EJyugnwZng3fS6vdJsvv4Nc3sKO2eAUvNHCnt VYRzBfoeM0dwXjMzpbTzM3AgmI22h8x80SrJzBo0PvHPmllDfiF4nNoMxaTacNZhW2MkJ4FDjX/o /SdYuN74RDmyJyptPIaf3blgG3rE26GvqcWT9ho0EHXeVHAz8nPAPWAMZNSuibSZ2DkG+dvRgM+9 MDYQP3YdYu8G5I8h8y50OyRNjLUHw4rJ72rb5Fuw00GmMxo+BFPg12TUdfHMNuSnUcsacffS6jb6 wrfOVLPu8OEB2uJbdyJ4B3o+QKYJ+vGnfS9tl8JnlXkmVofQl1mJtU3soecTaCTtl2l1GpnfgiZC 8J4z3EQy/d6KrxYphr6G8yZ9mTi8C7wb7EHbXdDN0JAJngC/hf8SfT0CfR96GJdH714LJCejZzo0 nrfJD+48cCTYGxnT419AEyGrqX0cZF6cGvT4CxDPJ8Fxz9PjKPgmp7EGXbO6WbneTXCqgGQGh6hw 0GabTEVWsb9CnrbuCPAdcAF8kxuhnZ1wtkAfpnfiymHt2OdoRdR5ZjWZERUgUwH5t+CYeV8LvyeY CmKzQ870c9BprCIq3M9B1pRLbISw3H+eVs8hfxmaleiOBg/CZ04d/O/1g0+OcslaLvFgk9XdweAq 5IuJmbHEj8lXeSC5yGMdOS/AMZmziLZmTpl3h5nyiSXnQZC15kwBid6kHYrJRIXH/uUR7T7eTmLs PrUu8g45ymkFdtPeLUvvIO7vE/puUV+wA3hG0TkJLlT0KsK/omi74Ctw6iLzM0X/AJL1wCi1GdAD ofsgeRwOfHeiYlJt6DuoXQcWw6EX58/Qj0KPBbvDGQ8+oxjCWrsttR9DF2KPj0wumEftJuj3ob8E u4E/hc+InBLaGm3bwRfAx8B9SDaHZlzOP+nxl9AbsWc/eArOH9A2iFYtkdwG/1boRdAz8ckK6KfB 2eCdtK1J21Jk7oF+jdps6IfgJ4GMxT8LNqZ2EjgU/Amt1tNvGhYayxmvOxdsQ1tGHfqaWkZkr6Et s+9NBTcjPwfcA8ZAY6GZcTOuMeDtaGDsXhidzKNdhxi4AfljyLwL3Q5JM9ftQVolU5t8C3Y6yHRG w4dgCrXToIlMdy8yt6EZzzjY73xAbRP04Bn7XvhL4RO9nomBIWgzEW5i9RP4yNgvwzlN7W9BZsfG D85w8E20mXm8C7wb7EHtLuhmtMoET4Dfwn8JnY9A34ceLPfoxWuB5GT0TIfGVzYry50HjgR7I2N6 /Ato5nQ1tY+DeNKpQY+/APFeEhz3PD2Ogm+yAdHrmnVBzHs3wakCsqYc5tFBm23WOOvR/gp52roj wHfABfBNVoF2dsLZAn2Y3okEhwi3z9GKOPFMzJsRFSBTAfm34JiZXQu/J5gKYrNDtvFz0GmsYt7d z0FWgcvsh7Dcf55WzyF/GZq1444GD8JnTh387/WDz+p2iQSbTOgOBlchQ1S7JpMUQZuZYjYd/O8T Ic6DIDHvTAGJvaQdxD9z7ZHPPWLVx4dJjMin1kXeIT84rRStz+1PLX0qskNqbzPPMZzJwunCvXuw Pm1w5vIkoSu1s/S7sU66fj7Nmc6zFFs59j/gT1a+fsDC0m9bKKefordH0W0Ev5i22dSeVPSHQw8G u6CtyEjSb5/gacZtlj6j0LvhLDgvBk88GvHdOn2KksXzk8s8D0nh2Ug+/Hna1t4FZzC1r0PbaCgC R4ILGHtFRXssHuilT0jszTy1aA7d3PlQ26qMVcrzipuD5yeC1t9UxstET09adeAJSWvlhG523xJ+ 1eDZSD7PQPJ5HiKYeK1Un1N1L92huRe6j95t7V1KhzpC96W2A3QB9EEkR0MnQ7em9k+0OgWnitEG 50hCb/oNkKlCqybgQGr3G6Q2FfoytW+g4Tb4f4TfAroetT70z6F/bWxQOvSpsYHaZ5RO9Cy9IJFQ B84Sq4bgZ9CzlHZu4i5fqui0Bc/BuQw9Hcm/Knp7FN0QfBvMpzZZMVQMXQQ2Qd5CZjJYD5xA7Uhs mAo9EHoBPZ5GZhT0VmqHoacC+jeA8wLL1ZKhcFbAWQNOBBmp04XaMJyxidX8L+yqeW1CnwSmo/nJ wAblH9I5ctoqWodouwicgjaeeNjH4PRSGbdOQj+r1o7aexNvCyasqPArI9NUOfZXxmY0z1Ub/Fpw CpQOTYHfM/G+xqfKuxup3a+1MnadnYpo7gm/Ojpfxf6apZfFzvFY+w22faatvGzGchz+HKJujLYK taCvUdAZ6GmSuMI7CFfUn+BERTlNKRbCSUPmOHQVRecnWNWcWdtMX8+geTAWFir6Lr6tayKktLdG ncrYVZSjv78jGZJV5lbWsfjVkT+utNcJmYpw+po4xNtp9FIRz1RRj4VeYtR9EvpsdhgWLoCukHhA YyyhTztvBuP0vhlvdIQeqJKhYlo1gb6A5GY0TIGeBH8/3tgOvw6c89TmwvkMbblw2iF5VlEyDvNl 4hD7o4zlb9hQSCSYSJ6qo5ZbwGG8xLyDY5mpYuQTaGhEX62pbUL8FMJvqSj5XeelayCjeIwY2IPm Xcb/gTfU8g6MpRBfVYVfCeyD5LCg3yusiyvE3jkiwUiq32orLbF9jkhWmYfAKXAeQDKVvlKR3EGr zcjMAFdQGw/Wb6aMxcfmpYzxE/hp4DrsGWIkGe+TZtQqKVHEU2siyg+8OpeoxhvqmdAQNL9OHliL 9zYEfameTGaqqslUtCqi1QYkE0R7EySXEpkpSvsZ1k1E2mpmXO1/y6zoYI2otn7M0W3gACw8E2S8 Guw12sv2YM1Ol9rFZi2rNsmWr2NVJq1MXlXNE3hKXGQNIq4G6Z5e2kPo+4m6U8iQBxyzjibRNm7/ mchfzWzqGNeb3Ijk8/B74fmpipKXVpMrNKuYGVkAJlObzqjbM97D4GTwCpo7MF/3gBlgViCjWW5M MI+a2X6rOVPiYTWr6W2i4grv5F4hVq8Qz1eYC6Uv4bexwS5WA46OegYjbWN2MXJOEbOzRjGJKEpi l3FOIjkIZI+zvtI4lDPwF+TAc+RAzTC9sLM1UdqEGN5FVJOLRHIukir/HvxhSHaBjsCfh+X7ofPh d0rsBbNZfef0TK69JKaXHmG+eupqZU5jjCvD7GuJP/F+/S1qLZaPZyzpSPZMcOahbZpVW3SmBjMr dMlC1WxZ/M6b5er3dIInjYpWBfgVlG9Zykk8qJ+yTvTVT8In+D5IogJ0U+im0M30c9qJ5vpZeuFn w8+D7q+fH9NP5gu9CboI+ozS+i0eabtKf+UGfnP9NKDoeZffZvmG37dZo6jfI7As/Z57IkW/zZFI 0e+DJJb4w/RXbpLG6a/cKF1SoHRivP+q/spN0leq3z+mmHQW+nPVn3QS+p/QRqYH2AzJh8FB+rs3 altJobHZ/x3yc6FNq1PYXAz/NviVFZPuYXSNwLOMdwK1S8Ek+D9Gsj19nYG/DZ2ZcFrjGcO5TO2D yE+kx2146TL4PL3fi2R92qpkE+gm0Jn+VviXoOujx/DrYMn90HdC/xQ9BxSTk6D5JZ/kZGofhPMy 2lbqb+Cg4cdoaArdFLqZfl9e5HdDVwVvoVVHbM7E5oHM8kxG+g212ObPh9Mf3AQWU1tNsHHSe9CL 0bkWehIyH4C/hb8Ueg/0ebVQf4VDrNU4bMb78k5JKTR+03fSE01L/qH2lDAX+s67cM5pbUmBetJw Es+D6SCt0NC0ZCOStC1h1CUzoY+h80/Q+6GLqCWiSj6FcwI9+gkcy6oQykk+ZTmPPDt8mJXy8+GP Pm6NGfbwiCetJZbc/O7r2T7dkptFaal1i1XR8q0060dWFavRf7D3HeBVFF/7Z2Z279y7u/ckhCSE UKSX0FukSe8gTaQJKL0IgpCAIkURpIiKNOlNmoDYKIqC9CZNegfpvff6nT1ZkUT8RP39vuf//B+f efKemW13553Z856Z3exCISgCpaAK1IPGdIxa8Ba8A82hLXSEeOjvbR8EDWkgEySHPBBLRykNVaE+ NKFfrQ09oA95jnbQCbrCAP7GYMI+CH7yGZkhHPLCs1AMypB3bgAvg4QXoCe8Cy3hVXgdusFAiARV uWbNSlCldo3n00GzOrWrpoNRfJQU/M7QZ8g3Z6Ej5oPiUBYqwvPQEF4BBTFQB3pBX2gF7aEzvAGD eJ8ApIOs4Crdc1AOqkMOeJ+XR0Eo8ZAeoiEbHbcAFIYSUB4qQQ14CZrSeeeEF6E39IPW0AG6wJsw 2DuDZGBDBkgF2ekIBaEkVIDKUBMaQTMwIRfUhbfhPWgDr0EcdHffZdo8f5fmqi5jE8ZWjK8xdmXs 1bxp+zj1HuMQxjGMUxnnMn7bvGmXlmo541rGTYzbGfcyHm7evEMndYLxmouGZAxlTMuYk7Foi/Zt WxsVGKsx1m7xWscORn3GJowtGNsxdmLsytijVeemzY0+jIMZRzJOYpzFOI9xCR24qbGWcRPjdsa9 7V+L72AcZjzBeI7xCuMtxgcumkb7js3bmxZjKGMUY1pa2dnMxBjDmJcxlrE4YxnGSh3d41RnrMPY kPEVxlaM7Rk7d+zc4jXzDcZejH07ucsHMQ5hHMk4jnEK40zGuV2ojcx5jIsYlzOuZdzEuLNL29da mfsZjzCeYrzAeI3xTpcOzTv5gNFiDGdMy5iNMX+XLnnz+YozlmOsxliHsRFjC8L8vvaMcYw9GPsy DmYcTljAN45xKuMcxnmMPzCuJCzo28C4lXE340HGY4xnusQ36+K7xHiD8Z6LWjL6GbFLfKcuOpwx mjEdYxbGnIz544hJXZixBGM5xiqMNRnrMrrRuCTfE/4XrKLrPBWk/ls5wS8O/d/RJI9hkhfV4P+P lQwuJeQFeb2kGHxKVOTnbH7n8j/JCfLeT8awp0bJLSLpqG6JZ3tcfXCjxKfGZE+NaX6HoU+N6fhM FVvxGLo1eHwZ/ikqUqpIiPqLuRSck6RPGf6SzQiZ/pLNDFn+ghWkpH+Of86JIAX/cwx5KsxH0UYc qf5wmArzYCVsh2NwTRgiXGQSBUU5UUe0EHGirxgupop5YqXYLo6Ja9KQaWU12V0OkmPkLLlIrpd7 5Rl5R1kqWsWooqqKaqjaqe5qkBqjZtE16P6WP6HPqupJys2SlAcnKX/4WNlIst5Hl/lu0OKxslUw cdmZknh/vJH4+OENE5cjIPHxI8KTlLMk2b5SknKjJOUk9YnYm7gcmS1JuWaS8huJzz/1pMTr0/yQ uJw5Z5Jy7sfKdP1lzptkfR8uS/IPYQk1zFozwWZLqLlBfS6SfFUWb+kWz+717DHPXnrS1jEFPVvC s5U8WyfxWcQMSlzLHLGJy7kfJN4+T/3E5XxJWiF//iTlgknKW5KUtyYpn0tSvpC4XCDssV5Gmdjw JOXYxNvHFk5STrq+SpJytSTl6olbsUgVQiRmmosR0EqMY2/bjBLQlTochBlqJmOtCAOfUxlXO5Vw JS7F5bTEJ86L87TdJXEJhLgiroAU18V1UFgaS4OBZbEs6abbH6Qqr9z2kjJMRtAS9z+I0D0fFaQ9 c1M5kkYjnWEcrIbDcEeE0zn46azCnVognUpObcLKzguEbu1CySeno9FCXhrzFMdToGQondNptquR Rloygspn2a7GnSCptJtwNe4lXEt1dXtoNGTAw3SuS2ntL2xX4xGyy6l8lO3qx7Y85m153NvyhLfl SW/LX8+3Kp9vNT7f5/l8f11TndfU4DU1H1+D6/kMN/AZbuIz/HXNFl6zldds5zUStKREl5kt3Se3 Q2UosRpBrCqnglORWF+KS8FH57ScmFLgKr5QPMNEf9lo/z5Uqz5UDBEh0FtEizTwNn/Psq9oKBpB P9FedIAB/A3LQeJ1EQfvi0FiEHwkRonRMERcFpdhqLghbsAwcVfcheFu14AR0id9MFI60oFPZDKZ DEbJSBkJo2UqmQrGyIwyI4yV2WV2GCfzypowXsbJeFgiu8lusJS8f3dYJnvKXrBc9pV9YaXsL/vD KjlcDofV8hP5CayRU+UuWKuC1GvuqYKqIDxQZVQ5eKgqq8pCqvFqvFBGnDFZGGZzs7nIb7Y0W4oC ZmuztShotjXbikJmF7OLiDXjzXjxrNnN7CYKm9t8A0QR6wWrqbho9beFeOCEOuXlm85LzgT5RbBF sJ28GuwdHCzvoES/8mN6TK9CMCNmVKGYGTOrZJgVs6owzI7ZVXLMgTlUOObCXCoC82AeFYn5MJ9K gQWxoIrCWIxVKbEwFlbRWBSLqlRYHIur1FgCS6g0WApLqbRYBsuoZ7AcllPpsBJWUumxCTZRGdxP CquM2ApbqUzYBtuozNgBO6gs2BE7qqz4Or6usmE8xqvs2A27qRh8E99UObA39lY58R18R+XCfthP 5cYBOEDlwUE4SOXFD/ADlQ8/wo9UfhyKQ1UBHI7DVUEciSNVIRyFo1QsjsEx6lkch+NUYZyAE1QR nISTVFGcglNUMZyKU1VxnI7T1XM4E2eqEjgLZ6mSOAfnqFI4F+eq0vgVfqXK4Df4jSqL83G+KocL caEqj9/hd6oCfo/fq4q4BJeoSrgMl6nKuAJXqCq4ClepqrgG16hquA7XqefxJ/xJVceNuFHVwM24 WdXEn/FnVQu34TZVG3fgDvUC7sJdqg7uwT3qRdyH+1RdPISHVD08j+dVfbyEl1QDvIJXVEO8htfU S3gDb6pG1Hmbsv8C9lxC3BF3yIs9FA/Je5iSxgF8nZl8nfn4OtMyWkaDX2aQGSAgs8lsYKlK5N1s s5nZDByzhdkCgmYrsxWg2cZsAyFmZ7MzhJpxZhwkM7uaXSEM02E6SI4ZMANd45kwE0RgFswCkZgN s0EKjMEYiMKcmBNSYm7MDdGYF/Pye+oLQGoshIUgDT6Lz0JaLIJF4BkshsUgHT6Hz0F6LIklyVu5 /jcj+99MWBErQmZsjI0hCzbH5pAVW2JLyIatsTVkx/bYHmLwNXwNcmAn7AQ5MQ7jIBd2xa6QG9/A NyAP9sJekBffxrchH/bFvpAf+2N/KIADcSAUxME4GArhh/ghxOLH+DE8i8NwGBTGETgCiuAn+AkU xdE4GorhWBxL/no8jofncCJOhBI4GSdDSfwUP4VSOA2nQWmcgTOgDH6Gn0FZnI2zoRx+jp9DefwS v4QK+DV+DRVxHs6DSrgAF0Bl/Ba/hSq4CBdBVVyMi6Ea+7/n2f9VJ9+5EmqQ71wNNXEtec9auJ68 bW3cQN72BdxE3rYObiEv+yJuJS9bF7eTl62HO0kz6uNu0owGuJc0oyEexIPwEr8jvhFexIvQGC/j ZWiCV/EqvIzX8TrPeyWMrwQUZF+bnfqWKRqLxrS4pWgJwlhoLATpu++7D8pfwl+C/PB/pveRD/y3 9/3b+7zeF829L8aNtkRb375/+9i/few/1MeE2Y7i+VCRQRZUFYz6kBqKQhmoArWhIY0X2lH83p0i y0EwFMbAFJgFX8MiWA7rYSvshSNwBq5QZA/CJ5zAG6ACXQJxgTfZxge6s+0aeIttt0BPsnGU68U2 LtCbbXzgbbZdA++w7RZ4l2w8bdeXbVygH9v4wHtsuwb6s+0WGEi2K203iG1c4H228YHBbLsGPmDb LfAR2W603RC2cYGP2cYHhrLtGhjGtlugB0ha24cwPjCAsGvgQ8Ju/4CREVzzLoGRHjOfeMyM8pgZ 7TEzxmNmrMfIOI+R8R4jEz1GJnmMTPYYmeIx8qnHyDSPkekeIzM8RmZ6jHzmMTLbY2SOx8jnHiNz PUa+8BgZTvXvEpjAjExlRmb9Q0a+8hj52mPkG4+ReR4j8z1GFnqMfOv1le88ZhZ5zHzvMfODx8xi j5klHiM/eows8xhZ7jGywmNkpcfIKo+RNR4jaz1G1nmMrPcY+clj5EtmZAH3lKXMyOp/yMhGj5FN HiObPUa2eIz87DGyzWNku8fIDo+RnR4juzxG9niM7PUY2ef1lf0eMwc8Zg56zBzymDnsMfOLx8hR j5FjHiPHPUZOeIyc9BjZwIxsZUZ2c0858g8ZOe0xcsZj5KzHyDmPkfMeIxc9Ri55jFz2GLniMXLV Y+S6x8gNj5GbHiO3PEZue4zc9Ri55zFy32PkgddXHiYwY0ECM5ZIYMaSCcxYymPmFDNygRm5xozc cXuK+51G97x5Nq0+ZBdb5URVTdVQrVRr1U69qrqoeNVNval6qgFqoBqk3leD1Qc0Cj6ijqpj6rg6 oU6qU+q0OqPOqnPqvLqgLqpL6rK6oq6qa+p6MNb9jpLYIrbQD0xw/ztXVVVVQarqqjoo1UK1BEO1 UW3BpzqrzuBXcSoOAqqr6kqRwBvqDbBVD9UDHNVLvQtBNVaNheRqkdoI4cFCwUI8yxANlpHWeMZI Z6Q3MhgZjUxGZiOLkdWtGZ3RdZ5dT4hXUntzEzncdbRPwty1UO0fbZHN2yKnOzel2tMaMMIN9w1g 2YxsYD+2X8LvhhsRRqSRwogyUhrR7rvvaNvffldCJggxwozkhmn4DG34jYBhGbbhGEEDjRAj1HDn uwyqW286SXcfaTxnlADHKG2UBqR1sRClpquZao76Qq1Uq9RqtUatVevUevWT2qA2Polxd7ZMTVPT 6Igz3P9rVrPVbOJ7riI/SsytoN87os4+Ovo02mo2rV2kvlc/qMVqifpRLVXL1HK14kltzEefrqbT 0Weqme4TmWoOHf0LRd6ZznAjHd2th3v03BD+xKM+oR7M2RGPM3e/p+xdvJ/bG2g/8zU5D96FvtAP 3oP+MAAG0nX9Pgzmr4t+BEPgY7rKh8FwGAEj4RMYBaPpmh8L42A8TICJMAkmkwf4FKbCNJgOM2Am fEb+YDbMgc9hLnwBX8JX5B2+gXkwHxbAQvgWviNf8T38AIthCfwIS2EZeY4VsBJWwWpYA2thHfmR n2ADbIRNsBm2wM/kVbbBdtgBO2EX7IY95GP2wX44AAfhEByGX8jjHIVjcBxOwEk4BafJ/5yFc3Ae LsBFuASXyRtdhWtwHW7ATbgFt+EO3IV7cB8ewEPqxkLWkrXlC7KOfFHWlfVkfdlANpQvyUaysWwi X5avyKaymWwuW8iWspVsLdvItrKdfFW2lx3ka7Kj7CRfl5PkbrlH7pX75H55QB6Uh+Rh+Ys8Io/K Y/K4PCFPylPytDwjz8pzypLn5QVly4vykrwsr8ir8pq8Lm/Im/KWvC3vyLvynrwvH8iH5ILcp+2V MpSpfEorvwqoWqq2ekHVUY1UY/WKaqo6qNdVX9VPvaf6q2FqtBqnvlRfqW/UPPWt+k5tUpvVFvWz 2qq2qe1qh9qpdqndao/aq/ap/eqAOqgOqcPqF6OYUdz9bqux3dhh7DR2GbuNPcZeY5+x3zhgHDQO GYeNX4wjxlHjmHHcOGGcNE4Zp40zxlnjnHHeuGBcNC4Zl40rxlXjmnHduGHcNG4Zt407xl3jnnHf eGA8NINmmC6ty+iyupwuryvoirqSrqyr6Kq6mn5eV9c1dE1dS9fWL+g6+kVdV9fT9XUD3VC/pBvp xrqJflm/opvqZro5pZaUWlNqq9vpV3V73UG/pjvqTvp13Vl30XE6XnfV3fQb+k3dnVIP3VP30r31 2/od3Ue/q/vqfvo93V8P0AP1IP2+Hqw/0B/qj/QQ/bEeqofp4XqEHqk/0aP0aD1Gj9Xj9Hg9QU/U k/RkPUV/qqfq2XqO/lzP1V/oL/VX+mv9jZ6n5+sF7rdf9Xd6kf5e/6AX6yX6R71UL9PL9Qq9Uq/S q/UavVav0+v1T3qD3qg36c16i/5Zb9Xb9Ha9Q+/Uu/RuvUfv1fv0fn1AH9SH9GH9iz6ij+pj+rg+ oU/qU/q0PqPP6nP6vL6gL+pL+rK+om/p2/qOvqvv6fv6gX7oB7/Q0/R0PUPP1J/pWfqqvqav6xv6 pvWG9abV3XrL6mH1tHpZva23rXesPta7Vl+rn/We/Zbdw+5p97J722/b79h97HftvvZ7dn97gD3Q HmS/bw+2P7A/tD+yh9hj7LH2OHu8PcGeaE+yJ9tT7E/tqfY0e7o9w55pf2bPsmfbn9tz7S/sL+2v 7K/tb+x59nz7R3upvcxebq+wV9qr7NX2evsne6O9yd5sb7F/trfa2+zt9g57p73b/sU+ah+3T9qn 7bP2RfuyfdW+Zl+3b9g37Vv2bfuOfde+Zz+wHzrgCEc6yjEc0/E5R51jznHnhHPSOeWcds44Z51z znnngnPRueRcdq44V51rznXnhnPTueXcdu44d517zn3ngfMwCEERlEEVNIJm0BfUQX8wELSCdtAJ BoMYDAmGBpMFw4LJg+HBiGBkMEUwKpgyGB1MFUwdTBNMG3wmmC6YPpghmDGYKZg5mCU4NjguOD44 ITgxOCk4OTgl+GlwanBacHpwRnAm333muX2eY+8tJ0ryoDxzPllVIX3foZ4nfd+lGqqXYI9qol6G faymB1Qn1QkOkuK9A4fUUDUUjqpRahQcY2U/zrp1gnXrJOvWKdat02qBWghnWCHOGUWMogJ4Bl6a lmmJvGaoGSry8Rx7ft8vvhPilM6rC4oLPN9+1epvjZXSmmb9KFNY66xbMj/Pujfj+fbppPZXIABR kIE0vzpFQGNIAZaQd6afsPuBxHWcm8M59x5NKERCansNlXfZawn32OsI99kbHm27i3LLwE/xRBSk pQggJuHukb3HXW7vI/zJPkC40T5EuNk+7+6JEe4RMdI9IqZwj8jHus9H/fUeTYBKq9AiXIN2ojUh vCaU1yRLtCaK16TkNdG8RkKAWi0vtV1h6X4tqZgsBlJWkBVAycqyMhiyhqwBpjXMGgY+a6G1ELR1 ybpEx5PmTPnzf0ljEyvs/9/6+n+jsK6GPq1u/jc1M0y30K10G/0WKZCrnOVJM6uxmtUiZfqQdbI+ aaSrjgna2PIpVbHHn+jh79VwNOngbwr4uLr8v6aGj9SOdHEU6ffjqliaog839kiIPNy4oyZFHre9 uOMuRR0NKOKYwDHHRIo47lCvrUs99WW3X/6qnbJDYt10Qp1kTpiT3Al3IpxIJ4UT5aR0op1UTmon jZPWecZJ56R3MjgZnUxOZieLk9XJ5mR3Yp6otv2erLcYQAvtp1LdOb/XXQzBUEz2O/VdY6+117EG b3iiCu8iHd5j77MP2Id+1WOMxBSsyef/UJXv/16XMQpTYvTfUudE2uzc/z9Q5+pCiggaykaLbBAu aoo6kJHvuWcTTURLyCFai9ZQQLQVbaGgeFV0gEKio+gOhUUPMQLKiTFiPDQR88VmaCY7yzjoKbvK nvC27C3fgQHyXdkf3pcD5QcwRH4kh8IIvns+Wo6U5O15jD9BOSoMJqpwFQ7TVaSKgRkqp8oDP6h8 qhwsZcXfzoq/g0dvO40pxmY4YyYzk4ko84Z5Q6Q0b5m3RLR5x7wjUvmILpHaN9D3gUjj+8g3TGTw jfCNEll9Y3zjRQ7fRN8skcc3xzdPFPMt8K0W5XxrfVvEi76dvp2iiW+Pb5942XfAd0g0o9jgvmjp e0ixQR8dq4uJb/VzuqRY4s/ujxHL/Dn9ecQKfz5/PrHGH+uPFWv9RfxFxDr3/plY7y/lLyV+8pfx lxEb/BX8FcRGf2V/ZbHJX81fTWz21/HXEVv89fz1xM/+hv6GYqv/ZX9zsc3f1t9W7A7QsF/ssZpZ zcVeq6XVRuy32llx4rDV1eoqzpLOjhXnSGd/FNdJZ2+JB7a0X5Labmx3l02dic4R2Tv4QXCMXJHw fAuNRufyHZfGopW3ZMFjSwQUBZ8Xe2ShmKYgrZ9GycW5FBVMY+uWFnulxVQ6QMl9yiaHyEG9JrfI TXJXWBSmY1YUFUlcqoqqYIhRYhQ/ZbMWmprRZioztZnGTGs+Y6Yz05sZzIxmJjOzmcXMamYzs5sx Zg4zp5nLzG3mMfOa+cz8ZgGxTWwXO8ROsUvsFnvEXrFP7BcHxEFxSBwWv4gj4qg4Jo6LE+KkOCVO izPirDhnKMNQN9RNdUvdVnfUXXVP3VcP1MN/ssygqhiSZxoM/m+FZDz3E0VJQWpKBjGXlWqaE9zn 0vJQ8hOrRSlOLE7JghKUbCgH5cGBqpQQ6lEKgQbQkOLDJpTCoAWl5NCGUjh0gTiIgDehO6SA3pRS 0tUpIVqEiFBIRddoNKQRaUVaSMtPxzxD12tNSEfXa0NIz3d1M/CVmlG0F+0hEz8vk1nEi66QRfQU PemaHigGQnbxvhgMMWKIGAI56QoeA7noCp4PucVSsQzyiNViDeQTG8QGKMDzTQX5yovlmLoKzzo1 4VmnVx7Nha305sJyEVNpZD6ZjyLGWBnr/m+YLEcRYxVZhSLG2rI2RYz1ZD0wKe5pCT6KeF6liHGA NQj81mBrCNjWdGsGhFqfWXMgzNpp7YJIa4+1H6KsQ9ZRiqV72L0gPalHX8jkKgNkJ2WYDDlcPw55 yI/vhHzkvQ9AIfLghyCWfPhReJb8+HEoTGOrk1CEfPlpKEr+/CwUI59+ntrIff6rmGz0qC7rvbrk prqkTVSXIrIIbevWSMmaNJYxuEYm18hH8V1D0FwvP0Vvr0OA62VxvYJcrzCuV7g11/qSavS1tQBS cR3TcR0zWCet05DFOmtdpHq5Nc3NNc3HNY3lmhYm/ZtG44MZNMooybUuz7WuSLp0A6qSKt2nkYlb o8qynXf31f0vxxZcozxuHUVtvu7h0RLguUwp2ohSj5ZJUUfkpFL4o+3oCngCF8VlceLCZcTgNjaZ Fx/zopkXP/MSoLi3MVjMjs2t7jBHQauB1QCQRua9IIRGX0Op7YdbYyE1jcEWQCbrW+tHiKWR2EUo YV22bkFLiiH6QweKFoZAd4oO5kAf0v75MIK0fg+M57b/ltv+O1LwX2AR94DvuQf8wD1gMfeAJdwD fuQesJSU/SIsI3W/DMtJ4e/DCtJzH2yiGCcKdlJckx4OUiwTAycoKrHhAkUXyeAyaXw0jQDIE9II 6XUAdwQJZdxZBqjlPrcFL9hvOeVhE+2TRozmpxzVby0CzZjXvNzraj7WInl/axGoAyUeLZNQiu+e hz/aToKyxllT6ZeXWmupt9223f5LS3mcnXA+6flM8nq/LulXov+OZ6U9I9gPAfshwX5IsR8y2A+Z 7Id87Ic0+yE/+6EA+yGL/ZDNfshhP4Tsh0LYD4WyHwpjP5Sc/VA4+6EI9kMp2A+5/1e8nGrgyEpq ETHxZ/dhpLBEGJ1lBhEj8ouiooyoImrT2TUT7UQn0ZVilz5igPhQDKdfnSSmiznia/GtWCJWivVi C3Gzn3g4JS6Ia+IOOX+fdGSYjJJpZSYZQ+zGihiqfTbiIhfbhqR+rm0sirBtIoqyfVkUY/uKKM62 qXiObTNRgm1zUZJtC7ryXNtSlGbbSpRj21ZUYNueFNW1HUUNtmPMFK41FphRbBeaKV2Ld/22a83k fse1vqn+INvFfmS7xB/C9r4/lO0DfzK2D/1hrqXoJTnbkiGCf6edyE6eIIR0XlIpJ2FDUns3diB/ QLWkPkh1zEf4ishP2FQUIGwmKI6guhUibCFiCVuKZwlbiTLusx+iLOGrojxhe4oXJNWqEmEnUZnw dVGFsLOoRjhGPE84TlQnHGuGg6T6RhAuNN2Zj7t+ahiqKfVqqqdBuNhP8QbV0ec+zeTXhA/8fsKH /gBIqhtFP/6SkJ2uqkakt+1JZ3tAXxgMw2EcTIU5MA9+IB3bANthP438z9G17d3Po54URX09E/Wl vCJWFKfeVElUJw/ZkOrdimoxi9gaQwzNZttYzGHbRHzO9mUxl+0r4gu2zcSXbJuLr9g2FV+zbSG+ YdtSzGPbyp/GtVTHtK6lWj7DdrE/Hdsl/vRs7/szsH3gz8j2oT+Ta6nGmdmWFBO4/SZyy03ilpvM LTeFW+5TbrOp3GbTuBWnc8vN4JabyS33mdse/nBmPIIZj2TGUzDjUcx4SmY8mhlPxYynZsYFGCHA T3Ur9hXAV7oIcf9Fw32Tb3V+pj4b5Cct9maiRCT3tRTcR6Lc33aPIlI+yrVxe5Lre8mfjOS+wuje IROh5KFARNCYRrAnkuxfXE2LgoHiRVFPNBD1RV3RxqpP6tMwYV5YxstecoAcocaoz9TXeA/v4wN8 SP51vDXBmmhNsiZbU6xPranka5dZy60V1kprlbXaWmOtxZsoUaGBJvpQo9+6bd2x7lr3rPvWA+uh TW7P/tgeag+zh9sj7JH2J/Yoe7S9wF5of2t/Zy+yv7d/sBfbS+y99n77oH3YPmIfs0/Yp+wz9jn7 gn3JvuJox+8EHMuxHccJOuiEODmcnE4uJ7eTx8nr5HPyOwWcgk4hJ9Z51insFHGKOsWc4s5zTgmn pFPKKe2Ucco65Zzy6GAQEcMwOYbjLbyNdzAVpkb3HmQWHvUBj/RMihyqkqa1k+1JteNoROfInjSi C/LTz8jjtxAelYXy3Gsy9ZX6CsJ8X/i+hOS+hb6FEOG76btJcRuNVSCFO1ah+OagdRyyuyMWimYG kHYXpTH7fChLo+09UI1G3Pvgedbu6qzdNVi7a7J212Ltrs3a/QJrdx3W7hdZu+uydtdj7a5vPyDV buCEklI3Y6XuyUr9NkaQUr9L9VwEDZ+mRf9eC/5X2unXFrKYTWA2A8xjGPOYinnMxDXPxTWP5ZrX 4prX4RilXsLIz+Qv/VG+CrjzumUg7eP9P2kv/uP+mNB36AjJuKcA9xTFLezj9kRuzxBuz1Buz2Tc nmHcnsm5PcO5PSO4PSO5PVNwe0Zxe6bk9oymdksBqbyzt0187OyR4k3vinWvee6nwP1UcD+V3E+V t69jhjy2bxRFJY+8wK9XOnsOvgq4J5vckzX3ZH/CKFZcFjfEXS8aSCYjZSqZUWZXlc3mZkuztdnW 7GLGm90wPWbEzJgVs2MOzIV5MB8WxFgsjEWxOJbAUlgGy2ElbIItsBW2wQ7YEV/HeOyGb2JvfAf7 4QAchB/gRzgUh+NIHIVjcBxOwEk4BafidJyJs3AOzsWv8BucjwvxO/wel+AyXIGrcA2uw59wI27G n3Eb7sBduAf34SE8j5fwCl7DG/8+Vf7vM5f/oWcuJYRSzN/KTI53SfNLPtUz5XQlina+/Y89Aex3 n5Xxnqr5X5+RefQcDR1DPiebPBqzJyypSh7o1zGvFNfgJsXohWRh2qIsLasha8m6soFsJFuQr+pE Xq+ne0/rScm9j/V4oqMkToV/n9y7Xo8n9x7ZE1PZJKmCewctUarx++TeTXs8UV3+IJEeJEpU58Sp wZMS6UeiRCwlTk04/VZukSS1ptTuD1KnJyX7QeJEqpU4pUySMiROXv0SzpeP8O/cxB/MTQg4SPpZ nLS+EkXZdfg9KL++/cR9E8ogGAIjafQzBWbCXBr/LIKlsJpGQFthN/GXl+/1/lUs/Lewxt/BJ85/ JMyOOGRGuuMeKO2OBUjrInn04N7jECI7jaMlqf0Iyo8Un1B+lHC/3j2BRl5SzBcX3TfAiss0XrnC 38C4Lm5Q/qa4zZp5l/L3xAPKP5TuF0ikNKjPmdJHeS3dt6baksbfMsjf8wiVNMaWYTKc8hEykvIp 3O9zkK6monxqmZ7yGSSN3GQm98sfpLHZKR8jYyifQ+agfE6ZE9wvmuSifG7pfolnrBxL+XFyHOXH y/GUn6Aq8ltcK4NSVczk7nviTKqvGW2Wd99saFYEZVYym7rv6TbbUr6d+1Vg0upulH/DfWOU2c/s R/n3zKXgfuF4GeWX+8kz+yWNIqU/S+BVEIH2AYr0Ah2Cn4EIzgrSqDc4O7iM8suDqyi/miJVgWkp zlAUTT7kER555RAZkjnhf5y5ZSQ08/4z97cYRHAMIjgGEY/9B6ngGERwDCI4BhEcgwj+vw/BMYjg GERwDCI4BhEcgwiOQQTHIAlnKDkSERyJCI5EBEcigiMRwZGI4EhEcCQiOBIRHIkIjkQERyKCIxHx P9WdezxUW9/AZ40ZlxFhkPs9twx7BlGR3JVrRggl90uYaYxb5cQUyiEOCpEGKZVbURSS5DlupVB0 UblULoVIouTdszs6znl7nvM8fzzv+bx/+IzfWnuvvWet3/ru717785mNmAhATAQgJgIQEwGIiQDE RABiIgAxEYCYCEBMBCAmAhATAYiJAMREAGIiADERgJgIQEwEICYCEBMBiIkAxEQAYiIAMRGAmAhA TAQgJgIQEwGIiQDERABiIgAxEYCYCEBMBCAmAhATAYiJAMREAGIiADERgJgIQEwEICYCEBMBiIkA xEQAYiIAMRGAmAhATAQgJgIQEwGIiQDERABiIgAxEYCYCEBMBCAmAhATAYiJAMREAGIiADERgJjI 8u+DfP+1ELHd8KcgUooSc4QYYvbsXKrxFvFzPIADzWSIGcNFBmgAiNwQFzt2HS8bWgyLgjzYcevY AQYwdNAAwyRD2yG1FSUSBVIxEsjjHD2ULcoTFYqiwBD1QdHhP9bjnc2Q7IrGMILKS3jzPEujUymS fsPcBylaxTy+PUyGEAFiYJgQg+0okw0N0Gich2hHOnLavhDP95MEWPh0opCzY9uBYcejd5CJeIif FXDicU4eof4BIX50SgiRD+JlFXLgOex9vIMpId5EKUiCVYLDC1kHeNEooRRfuowxhUal0DzoAfAe 8pAsq54NL7ay3ttHhhzgFwK3KmNnbAhJreEhEokQESJBmiSStgscakLE7yEUe/i/cm48EDernhuP sba1s1/enO2fbA4xgNzKPmO9PYoB4wYux6EZAKAmXG9G8ysMxbO/9F2yuLqmHj1ctYo0RdscrZ7Q a5N/+byxxpxPHnGARDQt621UOCLbq371yE8L2t1kid5r26Vs7/leH69ehV5UcSstTvjYJlf1sIEz bDaRmuLVO5koNZpirODt0p0QnRq8qST8rtP66JE6PseSrKlju9S9/1GuyLVbykvovX6DcEr2UXQT VN3IvUd6Na3jUXWxtkB8Tj437nW66/EFh9zGGVF3o2SBM5IGqdVK+MOiJIbkzOOEHtkregXXOGx7 FS5OJM9WPl6Y32B7fnS6fKf9h2eGORr8VK/+secX3wfLYvjImrVXbJsHyFcMfcxDdD7WjeYIG/6y V90VakKzwROikAEk4R4RhfBwX0quxayCcOyccFJjsRxsbJAkq5AXlm1BcXveGX7V6lvHmvhj9XtO Ol8vJIcgAyi5mvXCNQx8VYuBpFmxPEYEEo4RbOcfaeuqEnYGrTrqmsLC161O4aQhR9YG0hhbyBqy ZG5lmseb+tPp1I0aGl60IPXg5VFU96IEa1D3BrBKNag0ineYFz1UAx5kOBHhNIQz0B3SJWgSCSQ4 BdXhjSCX5XMGAGMDWUHblmMIHb/5t0NERET86BA+tH/ZNv1P046NlTlFruuDSm1yAgSGKInonICI piBvmvLRx/qmwWoiB3qUNfCDOwPFb3NrVScujl3PeMtBfB34IQzTff7J7o3seXyLF3jqc7cbU5b8 MnIHOg9OKVRodxzeNfHkFmX91lsuOKePoQN5M0OcVps2a3R03Z2wlaPOYaTR5yxzalLcjvKuzwjS 5Ki5ULqdef/2s+NyAvVNLxi9jvlz/VNFMk58fKcnSuLpQftyGqemb1N3n38abK3jnG0dteW+1i6X tWV+4+I2ZuwVSSrShXwpRZpn5B9+umoW/XLCKyvVcjO2WKNCpHLn2XJD8nFOLB9BtXUju5WE+gXi dkfvklMdJZlZKomZqQljp6/BjLoBM6pgmVFY0ZMIS8X/zKiI/woHZJFEgye+yO/1DgHBPgQy3SOY +juhIB2SNgnSIhE3sAhFgvm0HEKxlf8XhFKC1n4LpUKMA6j+PjQZE7KpjCnZZuMGUx1dgu56LSMC pLnBhLgWkv/2jSR++I3IPrTwAC+fvyRad/smcsEZk8L9l6wd95ETIy7qpP8ENi9eQheSLyw9uCzX jEp9ExYyITISy4tv7vNA3ZRmhm/C8GCaMcziL8Zk9nwM5jp3WhbaU3eyR1Ngbp3+gclSU6e4EzJn er20cj3Njt8se/k4b8PHCzsWO99EvNbGT7qNNFik24oZczjrJh6KEwwaa71vuZ8R0t4ttIdT8FhG savBxlYDmehgDWex6LZE3bqm2xv8+wjOYvLvVPk4XWSSGEXvHmSapsV1NOkcfsGTdbC5+9rLbHJf JOfsK3lZDs94l8AA0UXqPFkrdm4tUTQ+4edbO04tXrTSFlp0HT3ReomcpeKuVjSwdrV383SFUtgy 0bjgHsGugFeU/Jt8nps71PxFVDwZfo9mBtbruvwBVvJanx7bm1Fx77Z8Dv9cua6iSbtyNeTwDVYw qiAYVUzTeOP/CFbfqlmjiAwinJUIqpxXoAoGFWSxAlV6/x6qftgy/UcE5/wRvcxvh8e6Evsp3XrZ 0/uDfsrE26lh14jz1ZjkX0364NhZXyFb5R3sIdE3MTI+mzZhXCBi0rSwMFl6ze1QZrDlVePPSh6R nA4HL8+XZ+Gq6HcujhDs7kR/jbbJz36kpFxd1vficsphueP3ZqK+eAgGN4x3HKl4UVjriq0ec5j1 lAxSOudluTCUv1D7Iu6kTwC54tq+LG9F3/rm926edb980M+1NELxdOpiBRVdnqliLQ8FZuv29Ydm F9xLslPIOzs+a5AY2eGQvWut71lDduXyrXeq7DPePkcf9v5q3bNkWfBFJebphMElvXeaR9sa5Pbc d9uEqcBVZQXrnd9oe+oBEOb3TDQMh+0KWwfT6+wyvTQVxRB6Ef9ML3cECziuNMVj6dNq3kBUmA0e C6IotOYPhVzfh4pIgNZ9m8cKv89jewoFhgQ8dgG+AV4edB8ZwzC6P4UWQI9CKAVBuppEEgwlTRJM KdJvIYkV/p2K91eouULb6SYKeTdIntojI2OUHU4O2iz+iNLR/n5s79dMYb6XLzbSD4tVazBJb5ee 3zaykX9IQz3VdsIdayuT2fphyr/E2jK5qD7Kcl+OOceTxbUvTocd7bwYanKoN/bpTP30+rOtbqbP ykv1Xyr7Z4qdL6KFOr5fkzG8qJ1BYz4Kd5eKMD0cpyt8P9QVe8PPPrnoSoDGE1Hur2l0lcFwDYd+ QWjnp65kz8X2Vnczot11JfzwFqiTpsKnLPerjo0+k6Sfejdflz3OzcaRoayKJVVb9tp6vekieL43 1X9Twon6aJaf98A1SZE8sv/itmmzTh093byqCLeiNXnJ7fwpjnqNJVzubN3LqNkN94gLtJo19fAs EcJCbPDHCvb80IO4EXFiWROIhwTYuX67ixACGCzSMHw5+F6GZrWy+IBo062YeGIga8+mYiLlnF5d HwES/b6RIBqzSgqHIqPC4DsPY5ThH+DGW8LYs8VRKfPVWvwX1QEc+cTO4bOQ3Te4bYXMIVOmMdMw 3uDfh9v3ahqc2iwqIWBzWAE2C8gMMlkBNt3/BGysCWP8rdX/bV9ogNq5YfMhRbPyccqWy6SrgeO8 GiHFW+fG3cPeWW0i9BqXcn9tHyUQC+U7DtplxcjuKtHXsLpRUOyYO0Stran6FHV1K21u85jhobaB VWsC2otyZQgL3HZ3HO8ShrZ11VHfFPMUsBU5vqxJtHSaPmGU+35mcmIoXlpLr8bx1BRZPk71LEMi fTCDQ3J60OZTUn7bCL7oF5sW8a4U2gnVfcE5Yp8kpsiP/Drkltwk7xYk1StdifJyNCnYfnd+tNDZ sT8HbWqi4f7hSVkPgxTy5ewJ/PB4wJsLBWo3W9bx8focz346W7AgoMjlo5vxfr/0ttoHA44j9yNP iri1agu796dLbj1OuFmqZSIxwSckhtrVr+0qey/rV66JON4k22BevI3+QRWLXNqDmaC2xrfUQqc0 p+iMZKa4BZvLXGehH45etP4dQWNNy2uajsAHymU9P8a8/ZVkTWEfKd7Efr7n3h8o98x6uteMRt3B VHV/VnshnZhXgvuMV9pSOjw/cOGQWS3HHnOfPVtsKoze2ryrDI/qw2lxBUvEEKUHeR36X+V/fmXO V+qdtWQnrH6wASu7f/CEoVJAU3rKidbkvhzZMh633KmCsnj/w6sCCbXhe1GSJ0unhQ98FD6scP1o Z2CxOVHj1LOhffq9qJ88zR/cO9paI7LAS0tuLNQvR28JXArIOTnIV8xXpWPH+ahJH2Kwc8D8nlzm t7C/FsJvib+D35AOpAXBxNbWhFiWCUsmK9SEWOHfp79/Re8z+UGXXzy1SFM9uFdddKB+cKg5e7u8 Xem9fhEbhdUTD84/sCqlQzL84xwPHU4Ibc0QN0ory3KDFJ+g9o4cqH97jGP1HC8GvpXtkG7XVEg4 Pf3BT0Lty4E3RyXH3tgU5jfKk9uSF0w7ue7vLr9fYYQpmD8XlO7Xq/zMjFwRf/+Vspm6Ukm87Q77 VcNsap8DU1OhkISZndDphZ8eZVaOyGb+9KkLP8NZTQ62rzJNPWOB2mbuy6+k4lucOdzNHrutYP7I eX5zQS7GmSPvdkR+Back7TjjUHyQ2bvq5/JmtXcIDmfKpSINiREdOS82HU7P90BfleS5/GUu5wq4 J2fpsDSPbbotw71M70twj5z/V/T+oRj+gd58K+nNeg81FJv1Db6xqVBs8o/xm+911uO/np4MvqhS 4fxtzKJSq1DnDxx4dZ//N9T/t1QW7mu+zMQmNzaT9f2jVaURT+9FbbcGl9Xp+1yDV+Ev3bt5IKVG vUegICnYs8YJ3W4jg7fL7t+/ZdCpttz5lMSAJIgvqY2c/vn+201gYvBmCg7bkmwxOEUW6re9lDb8 JjnwYUzj64xpdo04ttFfVBXkqJ8/fhmOzFbnmeMYpNaJ2Jw+vhdHO1GTvyHXj9C8nXfM081AOOtn GYNBDjHSfAdxWzhRfx2Nu2WMqr8Uh8O/uI3zOD7VW7Nm3ObnQ83a63YXNozXRXMbHegh02QnoLba SB83V7AGJ8jb9UQwa1bvuq9zJUHjzXxcfMd2x5HT1Iygkg1WPR+jGi6K7PdUmSzIUdFijxDzbNWX CpZmTHH/qlbbaVz5av5t9NWhs8V07Rqb5n3yAorh3Hr2SftczIwF6yorK6z9Ws4YLcVEycbkCUG+ I0YCu8Va8uRk7xuPrhut/WDRodbTR4qxUlS1UHB3GXOcPPc8+3TbRkp9rBKdnX8iXLYhh9Go5HDt cqD+sfxwj6qQfPy5hovmUwKUxURS0JWvL7a3JMm3+taflkwQ8EbrE8p3ptQMy766WtHmVRXpgO0x VLcryagoirxUyTwZJvY4LQEfJqdBKuYMYbomrW1gTh5pk300LmXbempi68s54EM5xh3dEtDyOmTs fOY9osoSb7OrW5+1eH7fgkaegfoO4b2t+MJFIgOTCTEw6WgAoNiEv9GX/7BQ+/syLzP2DsvSfktb LjbiqpVryPBxf4+4ibzQylohlgMu74ghwiwCPXMEx224j1u64pqb+fMkXLNy6iDvFbusIjpCDkzV GGWUNSoA5YWioSjIMrQvio6SQTmgolBUOPKDyz3g//xRUfmKMQr/dI7So6gUP5oH1T9K5k/XEgwD oPBzw6ZqXtcqq6qw/Z5yC09juLjdI/CZB8w9yoIOcRxhvxv6VGNhKOTlZNy16+cmTXRviBzFzX6+ 4J4843A3wj9HWVdT4FLuxXc8H6VfHfPGvRWNqdjSpayveUVkZvBuenxZqcmlC4Mh2lfw9Twlmde7 nCJk004bqFXfvN2KmpW6XPf46USjFsbLMMn31ynpxs9GR4bL3exXj95yufMg7pf8QakW3eyJh1B/ qkOkX2U5esfrzZe+hi4YZrtSxr1494eM4eeEhJxnrand28XGhIu/Nm9hZPOETY7se35SZEGo/RP6 /c/xSeecrlmdmvXdbbD7FpowMeXE9NIaTnmoE0Kd62m2OrI+n4GWhBjoFYPLTmSgcXARO5KMcX/b xf8P63Ecv6UicxcksjIPuX9/4AHgI36vwRJXs5bKIG2iDnxPul4Tlpg/p+EcUVKzKCFD5pb0Ba1R DqfgdzoNnX9iMytBTK8+8308/y68T1LcN9Bor1XjrzK8rX1Hnu/9dJ7t/NivBmrXb9fi03Y9e1be Lr65MFPb8m1qcuSuR9pD471KdfWqLtDLONzFr599a8oj33M6M48axifKkW6Qr3K3VJZ1pbRY1slT 8/oL2SwqHkoZH5R5/UTo5I2tnP1Rvqri5NfD2/xCE7LunWvw3FP5ZPMrrmdlX+m5bDzF6QfCsZ8s h8s+Pp59eXIpbGzmZBWzXsEdDJW17e+Mulv+j6wlhcS78hdQkCWU9baV3mBq1uUkxuG4TnzcXj/6 Z+4NhaFFtlsvJIb0GcVFQ4QvacZvA3k9RW/MJu1QbH28gfZ0QpOYuprDe3dvaDsK9T8RubSjDQpl bmRzdHJlYW0NCmVuZG9iag0KMTI3IDAgb2JqDQpbIDIyNiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA2NTkgMCAwIDAgMCA0NzMgMCAwIDU5MSAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ5 NCAwIDQxOCA1MzcgNTAzIDAgMCAwIDI0NiAwIDQ4MCAyNDYgMCA1MzcgNTM4IDAgMCAzNTUgMCAz NDcgNTM3IDQ3MyA3NDUgMCAwIDM5N10gDQplbmRvYmoNCjEyOCAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA4MDYzNy9MZW5ndGgxIDE3MjIyOD4+DQpzdHJlYW0NCnic7JwJQFtV 1vjPfS8L2UgChC1AEkICFEjYKd1IKVCW0g2i0JYWSjdXsJRuWq27g9bOuC+jrY7jMlUb0lpT29Gq dRutOtpxHZ2qdS9ax3XaQr5z30kordW/499v5vu+yb2c93v33OXde869990EWmAAYMKLDKZXNdVN /sTzxb0gXDIdIHlZdWVV8/k3fjcN4MYWAGVddeWUSTHb7goCXHs3gOibXFVd8+HjXwEIF7Rj+rPJ 06c17W9l1wFsvAPYTW9PbvJWivLswyCMvQig5o1pTe7CI+qHtgKw1/Cp7Z1ndHQXRY+/FiAzgPXb O5cvs7rrSuoA6p4GUEQt6l58xm2fVN4LkJMIoIpd3NHTDYlgx+ffgPUNi09ftei5rjetANNeBEh0 LlnYseDAI0XvY/tzML90CSp06xS7MH0NpjOWnLFs5cm/UW7CDo8GcJx72sKlZy64bsFGgEtqscze 07s6O0Z95jwCsPg7gLSpZ3Ss7DYH41MwD/sH1jM7zlj4ds30CwEuQ51uTndXz7KgGS7B/qzk+d1L F3Y/dXCZC6A4F436W+C2lQdmrsr89rR5+nFfQ1IU8LDj03Oe43z2ja0rDr8xuE51QPkEllWBABSw ngKGgO1Wbzz8xqFLVAeklkYE8Uau0TthGsglhQAGcAN6QduJz5WKyOqFnZgbJb9RXoRNphHFF+Eh AaJA0CsFUSYTBdk+EIIeuDdIzwVobLJaAW0KG6kPylsFpxXYBqnRXfJoPlJsPfpob9gL8B8fFEOw Tl4N6/67nyM+DRW/dJuyHRD/S7cZCf8ZQfwSJv+seq1Q+1PKyRqg4Zi0Eup/zvP+LwT2LZz2c+uK r8K5I9o594fKob1/OK/xp/nsREF47Yfb/dF6T0LCz33mPxtw7Kt+alnxGYiXf8PPIj+xvAuqf16v IiESIiESIuF/YxBuhg/+3X343xbEC376ezgSIiESIiESIiESIiESIiESIiESIiESIiESIiESIiES IuH/WBBDkhL667CnMYV3wlaQwb3A/0rLinc86CAdpkITnAQdsBBOgdOhC5bCClgNG4PBUAkrNIZK dGKJ0+BMLLEsVIIFvwYIfgsaSIXbsPRXvApLRpkZ7Aw9PWW4X4koyVI6rBPFevF6ZmDJLI2dzrrY craG3cQeYLvYo6BgB6QyXxz/N26YFkJ/ESfAjwd29Cn/pA1/Wqga8bv7udK154TdwH7SKEPpNhQc L15xxJLmCpTwyHn6uf+W/v5yQfxFW/tfNC89NfPmts2ZPau1xdvcNHPG9GlTG6c01NfVTq6prppU OdFTMWH8uLFjykeXlZa4XXm5WU5Hhj3dkhhnNOh1GrUqSqmQy0SBQW61vabd6nO2+2ROe21tHk/b O1DRMULR7rOiqubYMj5ru1TMemxJD5ZcdFxJD5X0DJdkBus4GJeXa622W317quzWAJs1owXv11XZ W62+Aem+UbqXOaWEDhM2G9awVicuqbL6WLu12lezfElfdXsVttevUU+yT1qozsuFfrUGbzV458uy d/ezrAlMuhGyqsf0CxCl44/1iY7qjgW+6TNaqqvMNlurpINJUls+xSSfUmrLegrvM1xu7c/d1XdF wADz23O0C+wLOua0+MQOrNQnVvf1Xeoz5viy7VW+7NX7E3HIC3259qpqX44dG2uYOfwA5pM7DHZr 39eAnbcPHDhW0xHSKByGr4Hf8iEOmwnzw/eAfcMe4vhsNt6XywMemI8J39oZLZS2wnyzHzzunFaf 0M5zdoVzTF6eszacM1y93W7jrqpuD/0sX5LoWzvfmpeL1pd+HPiD+Vaf6Gyf37mEs2Nhn72qiuzW 3OLzVOGNpyM01ur+fDeW72jHQZzCzTCjxee2d/vi7JVUABVW7oNTmlqkKqFqvrhJPmjvDNXyuaur eL+s1X3tVdRB3pZ9Rst2KAru6y+2mrcUQTG08n744iehU5zVfS0LFvks7eYFOD8XWVvMNp+nFc3X am9Z2Mq9ZDf4svfh42zSE6VaOLbjSocL85ErHVHWFsEstnJvocJagxd75TjMMKC7pCT3aOU4awsz Q7gYPiVUgt8d0w4mRMekWp4l8qqTas22VhuFH+mSOdQnucMXNaItAyqG+0TP+cGuUWneoWxr9cKq ER08plF5qIOh1k7cT4HbIvRgrBHF3VkbzhIduHJRJ2Azkop7MdHqg+nWFvtCe6sd55BnegsfG7e1 5N+GJnvDjFktkrdDs6T5mBTlj6aUD2yYHU4Ik3AO1uSYw26V0pOl9HCy9rjsunC2tS/K3tDUxxu3 hxoEK64gHLTCWddx+eiYYlyaNbi72Ws67FaDtaavIxBcO7+v3+Pp665uXzKGt2GvW9Bnb2oZZ5b6 OrNljXk1f1QMNLCG5sq8XNx7Kvvt7LIZ/R52WdOslu0GfNVc1tziF5gwqb2ytT8D81q2WwE8klbg Wq7kCStP8JZmYiJKKm/e7gFYK+XKJIWU7gwwkHRRYR2DzoBAOkNYJ6BORjqPpOMBnZS4BE2M2221 dQF3zzmtS/raW/nignh0Jf4wH7NPAJ9gn9DPBIXWp7YvrPRp7JVcX8H1FaRXcL0SJwaLZ2gcvif1 tdtxn8IJ1QJmRlNR5E1aA8Fgc4ttj3mg1YZTbQ7KrBafKgf3frmjHstN5tKO6sm+tZ0dvB/gbeF1 lY66zlactuEGsUidT4UtqEItYIkaqQ6fjlipE32DDpTqr8WEb22rrzWHP7TllFZpOht8UGsfg26n NuVO/iB3a1+MvVBam7gU1I5LOVTYN2hqIY0Zk/iwVjKSUos977RjVme7Fa0tg84mnOq0l6rNpFmI W6LMuVAStTmUCXxYokOjU/tULmwQf/i9xsWXpNyhbG2lzkupS0MF8NkGnwZ75BxhylAFtA5m1fG+ 4M+l2FVe9FHezIwAzLSvxJ2Fd1pqSYnZPp2jrgM3f6qvQY19dLhyFN8jNKE2dpNWyUeuRbuLjuZA 8C77KtuIkJdr5y8HPjHBvB0nNrT2Ha/wzc7Jy406XquT1H19UboTVyB7RemGiUroV4kB4R/+tFRL QPjOn5aD+Naflov4hvA14SvK+5JSfyd8QThI+JzwGZUcIBwg5aeETwgfEz4ifEj4gPA+Yb8/TYV4 j1LvEt7xp8Yg9vlTkxB/86e6EW8T3iL8lfAmFXmDUq8TXiO8SniF8BfCXsLLhJcIfya8SHiB8Dx1 Yg/hOcKzhD/RY5+hkk8TniI8SXiCsJvwOOExwqOEXYRHqM2HCX8k5U7CDsJDhO2EAOFBwjbCA4St hC0EP6Hfn1KI8BE2+1OKEPcT7iPcS9hE+IM/pQBxD+FuqncX4U7C7wl3EH5HuJ2q30bYSNhAuJVw C+G31PTNhJuo+o2EGwjXE64jXEv1riFcTbiK8BvCrwnrCVdS0+uo+hWEywl9hF8RLqMKlxIuIVxM uIhwIeECv7kYcT5hLeE8wrmENYRzCGcTVhNWEVYSVhCWE3oJywg9hKWEswjdhC5/cgniTMIZhNMJ pxFOJZxCWEJYTFhEWEhYQOgkzCd0ENoJ8whzCW2EOYTZhFmEVn9SGaKFcDLhJIKX0ExoIswkzCBM J0wjTCU0EqYQGgj1hDpCLWEyoYZQTagiTCJUEiYSPIQKwgTCeMI4wljCGEK5P7EcMZpQRigllBCK CUWEQkIBIV+CyPyJLky5Seki5BFyCTmEUYRsQhYhk+AkOPwJYxEZBLs/gU/odH/CGISNlFaChZBG SCWkEMyEZEISIZGQQIgnmOgJcfSEWFLGEIwEA0FPiCboCFqChqAmqKjNKIKSlAqCnCAjiASBwAgg gQUJQ4RBwhHCYcIhwj8I3xG+lR7LvpFGxL4m5VeELwl/J3xBOEj4nPAZYYBwgPAp4RPCx4SPCB/S 8z7wx9sR7xP2++NxgrH3CO/640cj3iHs88dPQvzNH1+FeJvwFuGv/vhqxJv++BrEG4TXCa9R068S XqHG/kKN7SW8THiJGvsz1XuR8ALhecIewnOEZ6nen6jpZwhPU+efIjxJz3vCH1+J2E0VHqcHPUa9 fpQa20V4hPAw4Y+EnYQdhIeo6e3UdICafpCa3kZ4gLCVHrSF4Cf002N9hM2E+6np+wj3EjYR/kC4 x2/CfZfd7TdNRNxFuNNvakT83m+airjDb5qG+J3fNBNxu9/kQdxGRTZSkQ1U5FYqcgvl/ZZK3kyp m6jkjYQbqML1hOv8pumIa6n6NYSrCVdRl35DJX9NJdcTrvSbZiDWUckrCJcT+vxxLYhf+eNaEZf5 4+YgLvXHtSEu8cfVIy72x81GXER5F1LJC6jI+Z7NyIP6asvn0bWWfdqplsdQHkXZhfKI5iSLH6Uf xYeyGeV+lPtQ7kXZhPIHlHtQ7ka5C+VOlN+j3IHyO5TbUW5D2YiyAeVW9RLLTSg3otyAcj3KdSjX olyDcjXKVSi/Qfm1aollPcqVKOtQrkCZqBKOCIfgJLAIh5FLwMLO88fy5XiuP4ZPrWWEHr+RT62l hLMI3YQuwpmEMwinE04jnEoYRxjrN3CMIZQTRhPKCKWEEkIxoYhQ6NfzeVpAyCfEEIwEA0FPiCbo /OiUANMSNAQ1QUWIIij9Ou5qhWc28jOUAZQDKJ+ifILyMbrzbyhvo7yF8leUN1HeQHkd3fIayqso D6P8EWUnyg6Uh1BuQVf8FiXA1pKlV/uNfMqvIuOsJKwgLCf0EiYRKskOEwkeQgVhAmE8DdlEiCPE cmwXRVHweyx3PCwKsBVlN4ooAvXlbEITeX0m9WwGYTphGmEqoZEwhdBAqCfUEWoJkwk1hGpCFSGd YKPOWwkWQhohlZBCMBOSCUmERBpmAiHeczNyEOUIymGUQyj/QAd/h/ItyjcoX6N8hfIlevXvKF+g fIjyAcr7KPtR3kN5F+Ud9O4elOdQnkX5E8ozKE+jPIXyJMoTKLtRHkcJoDyIHt+G8gDKVpQtKDdz 7wuDZOM1hHMIp/iNeBRiSwiLySyLCAsJCwidhPmEDkI7YR5hLqGNMIcwmzCL0EpoIZxMOIngJTQT 3AQXmTqPkEvIIYwiZBOyCJkEJ8FBvskg2AlygowgEgQCoxUJntuRQZQhlI/QsK+g/AVlL8rLKC+h /BnlRZQXUJ5HQ29HuVh0WC4SXZYLmctyQe1a7/mb1nrPq13jPXfTGq9mzdg1DWtEzRoz4uw1m9a8 uUZxTu1q79mbVntlq+NWC+pVtSu8Kzet8GpWMO3y2l5vc+/+3q96xbje5t4Fvct6r+ndiwrlHb1b e3f3ioHgLk9M7+ixNWt7f90rxGG+AL1Mz9W2Xk10zbLapd6eTUu9sqXFS4WxXy1l+5YyIX8pm760 famApbYszciq4aVLlsYn1xiW5i/1LBXPqu3ydm/q8k7r6uo6r2tD1yNd8vO61ncJm/FO8HSpdDVn 1p7h/dsZDHYKQTCg7BKCflHdtUMYAgafC0OeIDsNDXAqGuIU12Lvkk2LvYtcC7wLNy3wdrrmeztc 7d55rjbv3E1t3jmuWd7Zm2Z5W10t3pOx/EmuZq93U7O3yTXDO3PTDO8011TvVNQ3uhq8UzY1eOtd td66TbXe6bVssqvGWy2WWvANAmn40522Nu1gmkzTntqdKnSn7ks9mCp2pxxMEc4zM33yecnrk0U9 XgS6JFmS1idtSNqcJNdLN6K2O2ZtjNBtXGsU8o0e44vGfUYZGDcaBf16/Qb9Zr04TT9P/7k+qJdt 1rPN0Y9EvxAtToueF90VLeqjeVo0eKJdBTV6nUXnmezWiePcugrdNJ24Xsc8OldhjUeXkVlToZ2m nacVN2iZR+vMrvlcHVQLHjVmfK4KqoSgioHIrIzxX4RamRjFfcRMlhqcj1vimZzh0aK/uSknpyGg DM5s8EVNn+1jl/kcTfzqmTHLp7jMB95Zs1v6GbuytZ8Jk5p9cfyLYyl98bp1UJna4EttavFtTG1t 8K3FGw+/CeINpPbHQ2Vrztye3p6eZTk9OXhBmduDmmW9+COB4RXZu4znLOsBLJLzA4GX6OHolQr1 9M7rxTYwA9U9kpqn5kpFfqiNf2n4wZH8KwL7dz78PzskzpsLoLwVYOjqEb9tPx/jb2ETPAAPwaPw J3gZvmRqaIeL4RF4Dz6Bv8NhXKZKZmIpLPuX+hU/9uFC+RmgE3eBgv/PDcFDwY+H7gl+DCCPHqG5 GlMJMudRTTAmOHC8bujqocDQ8woNGKS6BuFZ1B5kA8FDQgVPB0t5WriU30s1DipvHdo8tOGY7nTD UuiFlbAKVsPZsAbOhfPgQrgELoXL4Fdoi/Pw/nK4AtbBlbAefg2/gavgargGroXr4Hq4AW6Em+Bm tOMtcCtsCOXx9K0Yr5Nyec7tcCfcA/cifwd3wO/hLrgb039A698L96OONJS+DzUb4TbU3olaXorr NmP0QT/4YQtsRZ9ROpwKwC7YBg8it6M3d8BO+CM8jH7chZ59TNJxTTj9wyXp+jjshifgSXgKnoZn cGY8C8/BHngeXvhZOU8Ma3jqRfgzvIRzbS/8BV6BV+F1eBPehr/BPngXZ92B7+W/hiXewDJvhUq9 g6Xeh4+x5ACWpHJU5q9S7kdSC3ux7j7Yz6LgaybAYQjiHffedZKHbpT8yL3HvXOHZGfuj82Y5h66 a9g396GN70N/8hS/vynkjfuxbD9aMGy/E1vt+ZB3yN47sQy3Bc/ZE7LFUyFP8HYeHq77rJTnl+o9 NtzqUYvSCP8ywjp/HWHD9+EDyTJkPco9aj1eYj+W4VbmbRxr23exLlmf1+X6kXV43huY/hh3hwNo ac5PJU98Ch8O338Yyh+Az+Bz+Fq6HoQvcD/5Er7C9DeoOYip72uP13yL8Tv4BxxCDx6BwRGpweNy BmEIfQyMMYGJMHT07qhWEhkeMRS4p0UxFVMzLdOxaKbHo4jyuBzNcI7xeznaE+SpJE0Mi2VxuF8m sESWzMy4b6ayNGZhNpY+Ii9pOMeKOXaWwRyhvHipZtJwXQuWSBhRNpvlsxV4zWEu5sb7AlbMSlgZ K0dNHqYLMT0G8/IlVsJ0mA+nwyH5R8Jz2H4c7ir9/P+DG+oR38QdUwQllEMjTIXmnaBjt+C2OoY9 u7WqKipP+TAmBbCyZyEKzXeLJ1Ym6MzmCnuJ4gpxhrGuQnmF0AwVg2+/9SRe9sSUu/cw91sDrwwY Bp80lrsH9g4U5DOjzShJXLSgVCoU9nSXUJLpLC0qKpwglBQ77enRgqQrLi2bIBYVpgliXFgzQeBp Jr55ZJpYPZghrLKNbSqQsxxHgiU2Kkq0pOkcRVZ9Q6O9NCtZLotSiPIoZWZppd27oj79eXViZkpq ZqIamZqCHHxMHn3o7/LowyfLqg7vFD4qb5mQoVil0whyVdQtWWmmjIKU8Q06vU4ebU5ITlFGGaPV o2o7Bm9MdiSo1QmO5BQHb8sxOBbP/uuChxRnoe3Gwev88Olt8Wh0+fkJbrfalZiYHBAWbM0o0GrV ePMgZJTOSNJqEnewPPCAK3hwq8EuTCkIBA96rPwuwcCvOromuPMLXApL1gyLN8Yr90JiBYaYhHL+ 9k5uHCgsLKxg7r0DhcYiA78Yy8e7i4qMRQX55gd+2acU5Lc6wm4w2lm0yO8ymd04rCzmHkwTElgR Q7fxW5PiLE1qviMjP0UrDP1KFmPJT0/Pt8SIQ9cJmjQ36lM1pXn3uirzrVqWKGPpOkv2aEe/OTNJ l6E2qBUKvMhSD+/XGdWiXGPQyFIOvzesP7+oVG8vH3VkUGSjxmToo7EWkB9kAXkMjIcHyA/bMvVq l14fx387kuYqRGyFtNEzs7khYvROYUp2litda+B3Wo1CH2BrHsxUJ6XPSPK6+BcGHkUzWgNtgPYo Lx8wlpfnGPEmh6yONncbydz+X6DNsI3JtE5npj0+3vR9A8emiQlFTicqaDmYZAGD2RHbbS/KyUoa ejhlTIIgk2nMrgy7K1ldlrXOWZydEXskPifLGcNEUZviykh3JannJGQkaqIdFYVCW+masbXrpwzO Vhs0CoUGjXu5261LK8kcysxpapqeVXNDtTBPbdDK5VqDGm1cEfxYvELugDrYQTbeDhOF6x/IKMwo 1Jr5b1dB6+LTrgzULG+bsQxj/LhA8KOtGj2bMi7A8jzaiWZ5dlN8IlfE869EPPKTyCQ5kkly0CZu t2HAMMDNHMMTuHGYd4LrF2oWLc3IrrLwpkK7j0sRSitMIbvz7cgUl6YQr5hywf2dk3paxiZrZCq9 Orpoeldd/pSSlPzG+UvmN+ZX925odc2ZPiFOKRdEpU6jya+ZU5bjyTG5py1YsmBqPrto0U2Li+Mt 6ckFLsuoZI0ty5YwaoIzt6IgJ3+8d9mMtnVtrujEtLjoBHtyalayNsVmNjmKU3MovwftHo9z+055 HGRAE9ndD0m4tTRu82QkWbVJCQHhGo/Go0uyzEyUx8ykZRxTXsGS3Il70QYx5cmGt5IRaMkHjyvD Z560pGV83pWWjljIhfHxCqVolBsyJhRmlWclGVWyofO08qRxpa7iFI2cjWWsRKZNLXW7imKVWpfR pMG3aZTWqJOdnTHKJJep4/RHksV3jCatTJEwyo5vj8k4f5aLr0IReFh2aCSqhOKAMHsrZGbCmIBQ 7TEYxQT2ZQJLCGiL2ZFiVsy/q1FpdWxKcbFr4qgAS/SY96UzcU36unTBkz49vT1d1Kdb0gWtLD1d lhoI7vNEa3EapCYaWGPqIVf9eJwpHhUmxu/3aBtlkOimeTGQk4NvqXlz29ra5rUN4Dp057SdNdB2 FnMP7C7HuVLIzeXR/5t7I+0M/FWJy74k9Mrk87QIZ6xw9IU5QSbtB0qas/FFhaVl4vK4nFF52cay dSdNXnFy/vhVW1ecbMycmF/ROaXIoDFqFOqUmrldY0+5tj332/bxJ5UmTa4oaXVZog1KpSF68thK R93ptVN7GjJKR1WMiktJT4lOdiZYMlLtabHZ3kvmvBGTUWQb7Skt5ntvbfAT0Sa+AiVwS8irKZD5 sLAMoiGRWcACGaHFmsG/cI6tlz3EaqEALanRsMaCXGnZ5vJvrT2qRmnZDubszRmowOsA90ahtAP8 /7ZEe6xixHECV7qCFjre0T4gHTpsolyZOKb+ZNfiDaeXTVp5x/ysxkkl8Sq5GGcwOotrC+cvSS5q LCpuGO3UqbRKmS/ZnqhPsCUbPGu2Lrvk8bUTcDHH6xPtSWPcaLbrr6o9s95hcVrU5lH83yU04Bp4 Dj/vOvGkdW3IWhpz+Q6B/zMBt7DUo4611WjKM82y6FHhPQ7nWZ1HlVhfLI2vGFNbPdGN8il8DYdm D76z8c2Exyyatqqf28bIt/3I+VYYnzD81hGdztDeKNmsTHxOnZidZs1K0lRfP2fRutasovlXzWtY PY4fARx4BDhU2llaMDnHFJNdVZxcUFRqTdfo1TKZWq/prJ857ZItnSsevqR2/Fj2Xvg1NFhcVVsw c2HJ6FObCvXpZVncbvVot224d+RAMZOT3bbExtpy+V9Z5BTLAtxyNjE3Nlcw5z4u48s0QccaQWaQ CVOmy9plwkaZT4avxxQ3WmSLnjVyeqxYxr3fWZ/4DUQbogWjGK1K1LJGVSIWUP3DkxKeRDl7cWkO hFZp21lz23IG5rahvQvfwm3VLVn8X/ts6T2msNtGzFvTsbNbMGWWSn5SituyMwbfMY9tm1i5oC5f r9JGiYIsSjdm1rLKFVtWjp2w/J5Tuzcsyv9KnD0vf7I7SWCHXLnlbRPTYxNilTG2pHhLvD46McE4 bvVDa1Y8cnFNZe/GudZTV2WMb3KjX04LHmLr5FPBBDaoJr88AvHCI5ACJqEd1GBhZz/gSTLU0VR7 Becao48D5u0nyDvmtBkeSCxfp078WIDTkK3WStMqVRtm7IRm79jx3uZx6Wq9Wi7Hi7ga5xbOJL2a 5U8ZM7puythy3KXODR4Sd8i7oRjmh/tZgD1MBy1e48EubNuSlxePJ/UHPdEeiE/XyLPqUmqMU6hz 0pENDyXS+9SNH2sK93O3a05UbMQgMpnxe8MxMvp0g9uPkrH4eHGHJrUwK7vIFqMcevX40bGoqDhb gdNRZNHq9UOHmUursan1KrlMZdCxV4aywmOW28Or58gXrFMbI2k1+vTYodeG8uJSafxsNY7fBBWh Typ6nYnhxqlRMx0wjQwCQvsDHrWhhobC3JI/pHdSm3lLWH1CD33fK+nf71jIBy/hKi6E86kP/aNi d6D500AjzPNDmgFP0ltwKzfwbYu/OA0B1ohnm7z6UUkZdUlhI+PBhe9ZOfyQaBgol+aS4Z+qeewo pHeA8vueMtGByCS+pE0pyHAUpGhjM8qd+fNLwqNUJ2dbrKMS1PU3Ns1e05g+PGg2OLG+JLVm0uDm 4Tl5Tvhu8fTp4xb3deDaqQ1+LJOhNWIhE84Kz8k4oRffBGl4VUNSaPNOCrBkj0pfb5c2bzv/Da1H 3hg+4Q7kHF1RP7XG0XPw8H4hLx4+80p7ikw2bnXg7BW+ZaPHr37w7JW+ntFDg6bCporRzaXm+ILm CeXNpcns46U7L6uvPDewfOkfL62feG7g/Mquma7saV2TkXnZU7vI58IO6dTXHfK5U48zzaOFZL3a onarRZ2o5hsjek8dYE0etSen3qk3WetMU+iUSj6bx3fc3SFvq//f5UcMUdoGT+BeaR0qhB24G6qj 4pLSYkyj8tDJxznXPmH06BRdmjVRI5cJYkMGfrhSRimNGeNyB/d+371dhROdelGpUmtNo3D0CcED wpWyfhgDV9PoHzQadWOzwZ7H/8YxQZcXfkHn4Ylmi702VRdW6PgRJ6G2gP9W36MM+Q5dt0dyeNFg 4e5CI718tkPez2mE1oAs9Mmeb7B0sAxbJ7RH2fGjfnz4JSNcqYmxu8tSGs6sTT8tNo4P+FRNKq2N x7gJ4mIfd42NsyYZlQqNQr461x2LW7Fz2sqZ7Bl3WWpWgvop3A7k+KkebxKyUsvcQ211dUqVUmnK QGut4qcj8UncH04LzRVNJh2NLMI8jz42ry5TI0+qy0gMnQEbjzvEcN9Li0E6BUX/lOInOvEc3aql tVBadvTs85w6Kdtiy07EJT9zzppGmzR4nCwxDtwYOsrCZ570kat9ya8WCcOKoagaaWsQZoQ19AlP 3ILjzgVv6ExosFkCwkXbPCabVWGzB4Q2j9YDVltWnU2TXKeZcvQjXnLiW8d/xjuuUGghKIe/uzm6 5hNiE8piQ9+1bWGiXDb0ldyYOam0ZJLTKB/6Ct9PmpQCR3Zhqlb2rELxtKhLcTsd7mS1uEEebYyP PvI6/3Qn15oMYmacNVqBg5HJVUbt4FlJScJ6rRFfU2o9/4RgDx6Sv4zjq4brQ6sgJTXGlZtrGIXn N48m1TA62iATx4wxjAsIOR6dRzRMrCuqM+Rr9LVjAsEXtyBzkZ5ofjPGICY46hKmqEJbuvR1VcWI j7tJ7phydG2iYa+UKC+Poc9yvM0T1K4gC+GH3ZCBxMyjt07nCWw14lb+siLqM7nBNr6gYILdILtO EPpk+owJBYXjMXVAJcf54cgqTNGI/YJwp6hLdjscLrNG9IvCHwRtCk4Wt1ktbtRY047aUkhTqQbf PWrZVJsG3/h4YOaG1Wq5YbmZ9erB0zWhlEylRytX40H5M3EXnpFvD73h1XoHM+j1zKgwBITt2yxx GMHJ/95f5TCG9whjgKV61Em1+kxpnWTyvwPyyBtCL4tC3CkKcU3toa9QCvIBN+K5bXj0GW77n2pK OlHMbaNFZ8Ndh9u3jNlC+49N2nqk6cpvhc/4l36D282pokqvZVOHdscmyHEHEWzRcTqlLArX01bW rsITxuLU7ERVRrYrJtWcYhRk+SWpmQlqhSHFVBBnSUkxDA5GxWfiO/eD4BcCyJfgKSgbLDvxpBoA K55Ur9ymkTvMjYYaqKh46/nQ+zS8YMSjB9Hjvo9+h6mTcvAlkaRmyVpLSVZWsUUn19lKs7PLrDqd tSw7u9SmY3eHT0DiFbo4nUKpi9UdnpY9Ol2vTx+dParcrtfby/lnnFXiAuEN+Ypw30yCAjRgExTb suVm52TDZOzbHu6KV3jfwl0Z7lxYg3NW+sBmEh5XmdKTzfY4/FxhzrVac83qodNVcfZkc7opiiUw rpxYIF4Z/mqVPRLemocmHqszmaTfjN76PyOy+ULcPx1f/KlRLI7EH44y64/Ebd+P8pkUFWn/1tjz o/FLHpUlx8SdI2OU+0fj/T8cVdU/Kz56oqguUO8/UdQsj8RI/A+Nu/+nRm1sJEZiJEZiJEZiJEZi JEZiJEZiJEZiJEZiJEZiJEZiJEbif1qUfp/M8OdFvDawtaCASpgLPcFPYS7bFfwYr48GB6AH5gYP 4rUHVNDDhOB6vBqCV+M1OXgHXtOC1+N1efBJvK4J/hdxZwIeVZEv+jrdnV6zgQ0kkcEWFANCQECJ EBlXVNaIwoBepUMSSCAbnU6TYICouA7jMAzjIG7oZNyYQXR0Fp2l2Q0GyBWIiQI3BAXRgAGbyAUe 5/2qzumQAL7LvO993+v6fnXqnFNV/6Wq/lUdDXmVfIkqf6DyWv09zaKt1I+Qh/UD5Ov0Vi2RfiLk C/Q2rRdvj5OHVXmdymv1Fq2AOofIE/Wd5Cn6p+S99I/JF+ibyVdSswAph7SQ6j+k+g+p/hdQPkW+ Tj9DXqt/qy2ht53kidRZQm+HyHvph8kXqHJYdCVfJ2K1ldRsIU/UvyJPoc5Kah4iX6Cer9S/1sLU aSZP5HmYOi3kvdAhTB2ZrxRu8rBIUP9mvMxr9aPaOlp9Q55InXW0OkbeC23X0eo78pXCTi5brVOa rKNVRKul1UHyRP0L8hT9c/JeKl+g7yX/AD/UYu8x8nX6d4zpQEtvEf1X4HNUblUjHa/uZNkinNb+ IvrXCNKsNrNsE0nWFLMcQ3mIWbZTHmOWHSJknWGWnaI/vRpll/BZG8yy27KqXZZHTLGeNMuxor9t glmOs6ywlZvleFHgSGz/WwJDHJVmWRMOxxqzbBE2V5foXw0QPZxnzbJNxLpcZjmGcjezbKd8pVl2 iJGugWbZKbo5HjPLLpHoyjPLbi2zXZZHXOsqN8uxopvrd2Y5Thvn+qtZjhc3eGzyrzfYXKafjbLh Z6Ns+NkoG342yoafjbLhZ6Ns+NkoG342yoafjbLhZ6Ns+NkoG342yoafjbLhZ6Ns+Pkt4RNDxGBx Hbn8l/rzRbYIiGJWeLGYKYI8u039m/4lKs/iST6lIpHGm1tEAcknJvFslsjjXam6y+WaS+0QeQ41 b6NdAXVm8CyfGvmqXhYU0leOqlvEXSnPitQ7o30+Gvggi3rybwtUcDePUhBZsk4ZPQZ5nsud1LmM 1jm8L0Ib2Uux2WuQGoWmTFnDh43FSqaUUqpsuVvZOpMn0sYynueqFgH1pEBpHTTtyObNANVzoXpS oHrMwkfG86iUQvopUB4rMbUs4kmhkmr0Ke0MdtBASixRthj+jnrb0L1A/X2FeZTzTI9LrQqpK/+2 QlDdSYuD7eNh+MyQ4lO6F5l2FSvfzlA1z2nc0SLptXLVzrB6Dvdpaj50HM1rVG+FqocK5Ycyc+Q7 +luOmGF/rtJf2m+MS0DNBnk1JMqx9tFHSbs1ho6zzDql3M03ew9ihTFCofZRylJzJIunhZ3sis7m bDTJUvKzTflpF5n1Iy6w08d+WMx9jphizpp8c35dTw/DWT2d6w9sr//jsz+o9MhRs1PqNKd9XKL+ uth6nGXO9ZL22nI2G7OgiPq5aj6No0a2SFV+7kedHNXfnaptseo/SCrB0kGkeSqlqXXWWV6a2fsg yhVqVs5SWpfQQwVPpRdnKk/I2du51+hzuYIN6+e09zdN2WDMnAo14qVKw6Ca26VqLRqtfcoGuS5y 1ajmKxm5alxnqLZRb90hJmP3LWbbQIc3xprKUT45t07mKVnZah1dTK5xL+tmM4Jlyoc57fMuR72X K9uwIDrXSpSlReZsM/rKVblcPefbLd8bqzSVVnKk5GyY0S7pYloVXdDzpfvoXO/RSOkzY11Q6Z3d KeZcaHs0wpyv18gOHpCWGLYYkTe6dwTao3iOimNFKp5l/ailhp+zOvnUiALFZm5YZZTL1MwrUy1z VEyQ1uS29yNrFqhV838aof9X6+LcmhiktJFrwNgN0tRYlYjyt3xDBl83xDc+PztQXFo8M+i7rThQ UhzICuYXF6X5biko8E3Kn5UXLPVNyi3NDYRyc9JuyyrInxHI9+WX+rJ8hcU5uYEiX2lWUamP9/kz fTOzCvMLKnzz8oN5vtKyGcGCXF+guKwoJ79oVqmvmKrB3EJaFuX4sosDRbmB0jTf3UHfzNysYFkg t9QXyM0q8OUHkZFdOsBXWpiFBtlZJZRlk8KygmB+CV0WlRXmBqhZmhtUHZT6SgLF6C3VpveCguJ5 vjwU9+UXlmRlB335Rb6gtAPNaOIryC9CVvFM34z8WapjQ1AwtzxI4/w5uWk+08xrSn2FWUUVvuwy jDf0DuYhP3eeL5CFLYF8zKZhVqGvrESKocdZPCnNn0/1YDEGhaRJWb55WYFCQ5Z0c3ZeVgDFcgNp 7a4fEZXpu7W4IGcKrsEY3/Vpw4eYzwfK553cHwxk5eQWZgXmSFukXufGcRZeL5GPs4txQVF+bmna uLLs1KzSfr6cXN+dgeLiYF4wWDJi0KB58+alFUbbpVF9ULCipHhWIKskr2JQdnBmcVGw1KwqyzOz ED9H1ptWXIZzKnxlpbkIRyH52pfFWOQGCvODwdwc34wKpdYdk8fdwtuAumGkcsqMMZmXl5+d16Et 1/yi7IKyHJriu5z80pICBEivlQTyqZBNrdyiYJovKru4iCFNze/nyy2cIRud66ooWvmiGqnqclIy QKXBQH62MXPapcsJE+1rpFIgNR8pTF65OgJyiucUzysqKM7qKBSdswxNmQKYi49loSxYUhbE7aH8 7FxZJy+3oOQ8gy5lLNRIDMrJnZnFMkjLKi0pj/5lLT1JPHHRf0ZLowancpEgHLpObjG/iQgtlWuB EO3fcS7+ud3629hYjTra8kutHxcn6ytBl1Q/IUHVL7jU+omJqn7Dpdbv0kXWt95+qfUvu4z6t6u/ Aefke5GsL7+NdhOyhzu4PiR6y4iqWUSGliju1FLEJK2XmK49KGZrBaJcKxaPayGxTFsgXtKWiDf5 Fv0n7QPxL75Hb+Vb9G6tVjTxnepbJJxU6nSSpV2KLD+y5iCrAllPIus3yFqFrNXI+jOyNiBrO7Ia kfUNsk5Yf6sxUzRPZ1mWhA6yeiDramQNRdYYZE1B1gxkzUXWAmQtQdYLyHobWX9G1npkbUfWHmR9 jSz5cwGHdYx2GbL4tq9d21mWdUQHWcnIGoKsW5B1P7JmIiuArEeR9SyyXkLWH5H1D2TVIGs3svYj 6ztkndbWaQ75cwdk9UXWDcj6aWdZtooOsi5H1g3IGo2sLGQVIethZC1B1vPIegtZHyLrE2Q1IOsr ZB3XPtA0LazFI+tyZA1G1k3ImoCsn3WWFVPXQdZPkDUCWWORlYesELIWI+s5ZFUj6wNkbUFWI7IO IeuEtlKzIusyZF2JrHRkTUTWg8iSf++vQi4jJ9+23euqDpB+qNpdtbeqhuR0CKdz88GD9fXbt292 xginveTjcGt50ooSp104HbW1tXeVlw8ebI8RdntrUnlDQ7ndJuwxJWE+Jap+knwqn8sqJQ0nw+Fy l0W4rOGwCKuPqhUONzS0tjY0OOUPDsLmx+hVtm4wW/MpsVuF3dakKjhsusPmb/XzMVRoOCeKQmZJ id0p7K4vvvhi5syZSrHWwX5/uNVp0Zw21QM6WK2aM2bVqlVOl+b0XGi/5nRd3H7lmc2bCwoK0tMv br/LLlyO2NjYStxUW2m3C7ujvPZMOFzZ2QGuGOHCAaYHzHdRF8hGJ2X7WrM9H0NGq+E9m3DG+KM+ kFVqDWkdfOASdncNBu2umsdBLlt08ITLorkMTyhXSE1o5PJorrgmPsea/tP/BWmrfzvJ5dRc7g0H vt/5xSc7tmxwxWguB95oKknHHS6XcLnWVa2rylYibiD1JDnswuEoXyJdUOmI0RzSfeHwxyVuu+Z2 Rl3DK7vmcGLbmfDGcrdFc9vanROWNR1ca5V3as230Y9qaPinNtqJ9JDDpjlMDyn/4qKT0kX+dFWr 1hTrQDtzCB0e4fBsxMqi8Ozww+Hrqq6rkp3YpZ9wlJQbE273lC0GreRkc8dq7vimklY+jWtl2jF4 x+DNJLdLc3v2Vx0jNZK2kbaQNlQp08vPbAyfrIxdcqbczbZ5nuOirpOmncFFZ5TrHOWsnfDJco9D 87jsfEJnmX5nQ4bZZ/DdmcrzfCerOmVhM95rqN3ssWieDs4LOxyaw7VHdrN5sypXqi6NkZJLNTo7 8Z50X3m6qqXqI9gpHM4NG2bOzMhIcsQKR6w0u9hf7L8xfGM42fQe7gu3tkrBUe+Z7vMo93niNE9C U3pTemt5q4oT21ZsW7FjxZakLUkel+bp4MCaDi702LFLurCpvKf0occtPG7ZdVaVTEOFTL1IsSxY zUnVJUy0MwXyxiHbhTeeKY91aLHn/Ig9aq3jgbPh9WcrTVdFPRmWtc+5El/GWrTYjr4Mq+Z7zh5U 3on2pdzpjNGcuNOIWe4Y4Y76E4caAcb0qNNJTJEelS51onzc5sGGU/P9FU2Dw4PDsivHyZNJePXk yViLJdbeLt9wa6xya2y8FtulqWdTz9aM1oyGgoYCOd23LNmyZEPshthYjxYb10TIaPU3+Pf4a/2b /Vv8G/zrmtY1hZuUVzIWrse1GfH2J3CTR8R6wv4wi0AmuS4uFzLFk1wOzYWZT9gXSvVdds3lTK/8 EmW+rEyPc2pxbiufkYsObdiw4dCikSp+ZCw8tEEP7180SjowpoOHw7KBSxa2bN9z8uSe7Vs2xFm0 uPZpY8xG2cU+/cAG9WnvkO4XZqiAFHVz2COnWNTPONoIXuqzRX/4R8KVC5PipY9mrZi1ImcFzmtN 8if5lWFnzsRKt585E2exxJ1zuzQgJkaLc6q9R5gnP7d4zTJVWLMrAgXCOyuQO0eMKMgKFolxvNHu nXSrT/59V07K8hRmF3HCa95pwoFbuxl/cVY9YUPkPN2dZL07M/MucdWkieN9YvB9k8b6xCizjjx7 J6p/h1an7BZd2nu3CY/oyjnIuIthQVwmUsTl2SWlJaJa5W+rfK3K/6zyv6t8/Ry+cIuPVb5d5btU /rnKm1R+UOUt8ouhOC5zza7yFJWnqfxWlU9R+ezCOYVztIUqf0Llz6r8OZW/rPLXVb6m/QT9P+Xa JeZOPGnFB2xIlOV/Nfj/98zCOMT929d4AlqamKR+uvioWCZeE++J9eJT0cw5kkODstRpWtsi5H87 sdLOq/7itvxbzyOM61O7jOtLKzu0Yb4dSul0r8UEO9/bX+5873qm831s1873vUKd7688733vZZ3v B7wpXJYO9wMLOry3c/h+v/P9HRaubuZ0qsjEnnjaPIqrBlsyxSJLteUzscr6kvUlscsWtL0qdsfs tD+lWd33urO0v7mf9Gjax7GJsXdYbot9IPZlS0VcTtxsyz/iFsUtsWyMt8Q7LZ/G/xD/g6VRaI9k St/Yd8atvWjaStoVt69D+tJMWy+Sjsb3bE+9ScNIo0g5Ki07P8VtjX8xfk3iUjOt7JCqVTp1sdTF 1mVMe1rc5dn21Gqkrt0vklJJad7lHdLLRlJvzkveP3jXt6ePu31OalLp7MVS19Tusd1791hspmc6 pOUqrb9oqutxKpqSvEkp7el2M425aMpUaYp57ZyqzFzW26zSrvZktN6X1JrcPzkn+eXkN2U6v/fk NRdLRu/Jf01uNlPkXJJSkk8pWVWSn4zrk9aebu4zuj1NNdNDpGCfh67qSxp2de+r0/s8RN776j/3 /fs1W1X6OnUCKadfCsnXr75fC9T3O97/79cuk6lf/bVrr91HOjnAMsA5YA3p47QhpNvTJgxaaqb3 rgsOTRm6Z9gTN6SShgyPHT5heEH662Zam/5h+scjepEGjAiNrM1ok+mmypvWqPT1qF6jlpvp5Zu+ 5n75qAZ11zDqG9Lyn3pvDt1cfUv3O24mbb4z86ZKozbXBqPW3X1lvbuHjXHj1L5jlo6NVyl97CSV IuMs45LG9R4boZRJmjlejLePzxnfNr5tQs8JB6mXPvG+ifeNyySfIUukvImBiVWZdpUGZE5QyZ9Z BP7M8sxHM8t5H8hsuOf+e/z3HL/n+KTESS9TbwDv1JtJJzPL751xb8Hk7T+7fWr9g0sfXPlg9axH ZzXkTckrj17z3s57O39w0bNFq0ra5oq5o+b6586eG5z76Ny1c9fP/XLu0bknA/aAN9A/MCxwayAz cLQ0sbRvaUnpwtKlpZtLm4IjgvcF3ws2laWU7So7FRocmhkqD60MvT8vZd59894rzyt/pvz98u3l TRXuip4VoyuWVmydf9X80fPz5s+fv3j+6/PXzv/0Ye/Dox9e8fB7D/PlrjKpckxlTuWayq8X9F8Q XLBmQdPCXguHLZy98KmF9Yu8i+5f9Oaig1U9q/75I1Fr7fmRqXPcqfryXJIR5ZH4c8mIJT+y+sac v+Y6rxRjrl80/kRjUIfUOYo8MuxckvHhkVvPJSMyyGiaWJ20ucdyIvKuUQ3ETxWN1ZXI22UMkXZZ /IuJS+O2RqNnl2fjdnVp7TNVto1bG7/sXBQ1vEScHqUisVGrZ/yLUe/Jpyoqy7q75HtV3/Qg/a6N 20dMf5EWu1RvW9FuKdddKp3bJ748b38Y1WFHOLcnvCj1vmAfqD5/HyD228y4vzga8VU/tI4fRXlZ NBYyHm+a40V0MiKQEeHMcSQqEgPlqE1tj4/RESXKJY2R9c+NcJ/R9CPfR3iemdzM/QWzgRi4q0M0 vUiM7RhTL4ynZtTerOaREUFvjsZOGdN5Mlr2y/3opMwbUife1+2ssZOpK7tWj1PsVWe7x7IPmTtP dEfp2r3b2XO7jzEf5f4m63c7K2vQen33WPlGPlF7GU/ku67d47ZG52lSCu+bkEAfPRarO/X83I7a cU+VOqn9M7qDtu+h7JmxF9kzl1+wZ9YZOyV7pDdqC+9PGXooTRaPTe/2edLt6NZpNKQXz1+5UY8b K1L61pgxfabi/TFybKVfkjK9y9XIvylHqsPqTkte07V7+167y+y1ypgPclyM+ZW85ureV/U1MHa1 q/qqnahDkruasaOpPfH/Mql9tEO6sIbaXTskc5dtTxe2ULvrv5XU/nvJqX2X/pF0vqdkat+7fySp 3fySkzphXGI63zvqXNIhXeg/dV7pkORMN0b630sX9vw/a3dpyfCzPK/Ev5jRNsZ909dxu+RJR6VK +SSjTZ5u5N1NlWPc8txjvJOJU9MAeVIynqq96BsjqRPRzeo0Jc9NDaMa1JlInpsaaFGpziP29nOL TAMy7RNnZNrlmUXdDTBPNkZ5AOeePPlEnW5oJ68yyfq0sKve/OrtAJknr6H2AHl+6h47Nn7iDHnW kucsldLVk3h5zlJ36RNnyEhkviPJMCFPZOqEZlFnM5KsTwt5gqOmPI2dO5+NTR/1jfLH19IT9xw3 /JDRpqxBX0PPcZmyZ3Xes8i+jH47r8MLx7PjLLhmq3En7FpY324dr//BOlkkW6eKBGtAP2T9p+gn 5P+F+wl3DarUYp2sHxIa+X8LC/lO61R9J9/NV+ttYqPepvlFHy1LTNZmcM0WqVqO6KXNEb2oeQ81 p1sL9Bqh0c9XwkbdBOr2om4Cdd2qvxZqHRMu7SGRwvuBvJ/O+0G8H0hfQ+grldZvKH08lN5D317W Sn2ddYH+CvoOtR7QX7V+KQZavxJDrId4d1hvsH7Dt92ots3CRukKSr3QZjU97RTlIkFcLxJhhLhS jIQc+s+FmVCq7xVBtCqDEMyDcqjgG+58fZN4GCphASyEx0SyWAyPwxPwJDwFT8Mz8HNYAn/jG/iH cJLyWdBFsiZAg0yRrt0Dk+BeuA/yxURts+iBxdOtU0SG9QERa50OBaLIughLHxF9rI+JXrZX9E22 VfAqfCqSbTthF+yGevgMGqARPocvYA/sFckxiXpDTJO+KeZbYYtpoXwEWvVN9hhxvb0f16HiSvsN XAv0BnshFEExlOl77SHAN3Z8Y8c39vmAb+zviHT7WvgL/CDSHf1FD8e1MF0kO/wwA+ZCACqgCh4B fORYCr+CV+BVkepYzfUIHIVWOAbH4QfAh85syIFcKBM9XEKku7yih5q7R5nXblU6zKifFN2YtVuZ tVuZbX2YbWOZbY8y2+5ntk1ntmUy2+6idpj5cqt1CnPlZ/rbzJvJzJun6CFo/ae+0nqAefaVcFsP 6v+yHhZj1Tw7RK2Dokv7qnhIZHTofzr9l9L/ZPq/hdozzL430uom+l5F36vN/jJFfIde3PQynF6K 6CWDXjLMNTEcLQ/R07309Ct6yaSHfylL/6JKSfTxD/r4B32katP1D+kng37y6Wcs/dxPP6O1fP1T +srQVugf0PIj+utKfxVoVkqfKWhWQW/LrM36MbTbaP2alXWYOfeNuWLjOqzYgfQ6xFz9csXupuVe Vt54/SXmr8eIMPJnujxvFM+Lx/QWsRgehyfgSXgKnoZn4OewBLbqp8UnUAvbYDvsgDr4T/gUdsIu 2A0NsFc/K/bBf0ET7IdmOKDXiS/hKziufya+1/eLCJyANvgBTuq7xX+zpk/BaTgD/wvOoouut2gC NBUVD1rv11ut/6G3WR/i6tfbbJ/qLbadsAt2Qz18Bg3QCJ/DF7AH9sLX+mnbYfgGvoUWOAJH4Tto hWNwHL6HCKCL7SzorNmuep3jZv204w4YA2Nhgr7fcR/XyXA/7x+Ah/RNjul6i8MPM2AO7+ZyDUCQ 8jwohwruK7lWcX0EnqD8JDAOjl9yXcr1V/BrysvhN/Ac/Jb+X+H5a5SrKa+m/A7lj4AxcjBGDsbI wRg5vtDPOvYAY+RgjByMkaMJHfdDMzBGjsP6Z45v4FtsaYEj+m7HUfiOvlvp+xgchwh1GTtHG89/ 4J4xcmZDDuQyXhbxrPAyUqeEVTyrN7bvXjHc/Y27JdwtYJY3WHeI3kLjaZu4nZlZz8ysZ2bWMzPr mZn1zMx6ZmY9M7OemVnPzKyn9j5m2mlm2mlm2mlm2mlm2mlm2mlmUQszpo0Z08aMaWPGtCFvG/Ka rA+yErJghv6VNVv/illTz6ypZ9bUM2vqmTX1zJp6Zk09s6aeWVPPrKln1tQza+oZyTZGso2RbGMU 6xnFekaujVGrZ9TqGa02RqqNkapnVOoZjXq8fhqvn8brp/H6abx+Gq+24NUWPNqGR9vwaBterMeL bXixHi/W48V6tWK3CQe+TGcl29l7X2LvXWGtE1da/1N0tbLbKP8eMv27X/n3ae5u5O42/FsuzxZi Kvukl33Syz7pZZ/0sk962Se97JNe9kkv+6SXfdKLpIHslSnslSms2X2s2X2s2X2s2b2s2ROs2ROs 2ROs2ROs2RPspwms2UbWbCNrtpE128iaZbyJtlNEKuv0COu0hXV6hHXaYp0hBlizoUDkmPvoFeyj XvZOL3unl73Ty97pZe/0snd62Tu97J1e9k4ve6eXvdPL3ullLTayFhtZi42sxX2svROsuX2suX2s uUb2OC97nJf9zcv+5mVf87JWGtnbvOxtKayVRvY3L/N/H/N/H/N/H/N/H/N/L/N/L/P/BPP/BPtf AvtfAvO/kTm/jzl/gjnfyB7oZf/zsv952f+8jNRU/Yic9djI2uaU9izRezJ71xR9H1H9Bd4/xXh8 wNvXmfNDrJ9SZlVad7OPyTH8jNp7qdVApH5WX8hdBW0baSuf5pj74DbaDqTtdtqNFnZqvk7NBdRs puZ/UXO2OmXJmfO26ukB3o/n/XbeyzlyKz0t4e2r9JRKTxvpaYCq36JOiwdU3sb+l8BZ8H4ogEIo hhKYCwEIwjNikOiihdVaf5Hel0npamRXwUdimHUdNHPOPSBGc1ZMYP/2clZMtn7N9TAnq2949i0n Mystt9OiOyfLZLmz075AZLCP3c+56wGRaX1IncHYpdEsFc1S0SwVzVLRLBXNUtEsFc1S0SwVzZh9 yHiAE9tDXKeLItXSS0svLb209NLSS0svLb209NLSS0svLYfQ8hZaDqHlLaplAi0TaJlAywRaJtAy gZYJtEygZQItE8yWY82W8ozyACM2nXUlffyhOimcwlvN8nea2MvvgUlwL9wnXJzgXJzgXJzgXJzg XC75e1A2+RtwtJmNh8ep87gcoy/FLi1VP6D1g/5wLQyAgZAGg2AwXAdDYCgMg+vhBhgO6XAjjICR kAE3wSj4KdwMt8CtcBvcDnfAaLgT7oK7YQyMhXEwHibARFipN2svwIvwMrwCq+BVeA1+B9Xwe3gd 3oA34S14G1bDH+CPsAbegbXwLrwHf4L34QP9ezzSrK3T92rrYQNshE2wmedb9HrtY6iBrfAJyN9j 3AbbYQfr9n5m7kP6Ttsm/XvbZtgCH0MNbIVPoBa2sRtshx16fUwXvTnGqx+I6QbdoQckQbJ+wP5L eF5vtuMD+8t6i/11/Xv7G/AmvAVvw/s838B1I2yiXKfX23dSn3OLvU0/4PiJ3uzoBVeAD67Uv3f0 hj5wFVwNfdk5roFU4lY/6E+9a+E6GML9UN6NZLfJ4DpJ/95p0Q84rWCDGLCDA5zgAjd4IBbiIB4S IBG6QFe4DLx6s7MbdIcekATJkAKXQ09Afyf6O9Hfif7OK6E39IGr4Groi05DODcMhRvZ+UbASJ7d DKPhTpiOvBlcZ/JuFvXyIB9mQxl9LICFsAiqqPtLnv+O+m9Q/019r/Mt7t+G4zw7oR9waXqzC1td l+n1LuxwddNbXD7mULn63VEr2CAG7OAAJ7jADR6IA/kbpl2gK1wGXugG3aEHJEEyyN9Blb+BegX4 4EroDX3gKrga+sI1kEqs6Qf94VoYAAMhDQbBYLgOhsBQGAbXww0wHNLhRhgBIyEDboJR8FO4GWQ8 uxVug9vhDhgNd8JdcDeMgbEwDsbDBJgImfph7R6YBPfCfTAZ+6bAz2AqTAP5u7YLYRFUwSPwKDwG i+FxeAKehKeAbx3aUv2U9itYBr+G5fAbeA5+C/I3d1+AF+FleAVWwavwGvwOquH38Dq8AW/CW8Bu qK2GP8AfYQ28A2vhXXgP/gTvy98Olr/lC+thA2yETbAFPoYa2AqfgPzd4W2wHXbwvXey/iRRuph9 IJnIn8E+kEz0zyBqf2Yj4tmIeDYino2IZyPi2Yh4NiKejYhnI+LZiHg2Ip6NiGdbox+xvQNr4V14 D/4E78MH8Ff4G3wIH8Hf4R/wT/gXhGEdrIcNsBG2iQTbdtghEmK6CHeMV8THdIPu0AOSIFnE25fo R+y/IAr9kvJzlFfoh+zPC7edMSCaHbWv4h222H/PO3S2o7Mdne1Eafs7+mH7WkBfO/oS5Y7a/0z9 v/Dsb7z/ENDXjr529LSjJ9HvqH0Ldbby7hPua2EbbIcdUCcS7DuRzTc8O9/w7PU8+0w/RaQ8av8c 3fhWZz9E228pt1DmjG3njG3/DvjmYj9G/ePwPUTgBLRh2w/6YUe8fsSRAInQBZL0U45kSIHLoSf8 RLgdveAK8EFfToXXQCr0g+t4NoTrUBhG5B0OI/WjjgyR4LSIeKcVbBADdnCAE1zgBg/EQhzEQwIk QhfoCpeBV7id3aA79IAkSIYUuBx6Ano60dOJnk70dF4JvaEPXAVXA3HGeS0MICIOhDTKg4mc11Ee oh8lEh91DqN8AwyHdBmZsWMEjKM8Hiboh5wTaTdNP+Wcjm4zeTeLdnmQD7OBb7pOzpXOebAAuQth EVRR/2nkseaJ1Eedz3FdQV/Pw0p4Ad6gvzfhLd6/Dat5FqHeCdqe1k+5hH7YpQm3y0nkxocuN9cu PL9MJBDNj7rYlVw9eJYEyfoRVwr0lD+RlKvbPEs9zapsVueyf7U/X8zzx9RPUOQZ65iIsdylT7GO lz+ZEm75Uy31boBlsH7QMgyG64csP+V6l77Lcre+yTIWxut19NTAieIgJ4qD7qn6Jvf98CTlp+Bp eAZ+DkvgF/As/BKWwq9gGfwalsNv4Dn4LayA52ElvAAvwkvwMrwCq+BVeA1+B9X6wdhr9YPCiqZt lql8G5b6j0T/CPpHLCP0BvSPWG7j+rS+3/KMvp+45SNm+ai5yX2v3uC+D6bAf0C2vt89GwqgCEog CE/qEWyLYFsE2yLYFsG2CLZFsC2CbRFsi2BbBNsi2BbBtgi2RbAtgm0RbItgWwTbItgWwbYItkWw LYJtEWyLYFsE2yLYFsG2iGeMvt8zFsbBeJgAEyET7tH3Y3uEMRyuf8YINVjUOOofqZ9FXIHtq7F7 teUB/SNLDhTC03oNPqiR30awfTW2r8b21di+GttrsL0G22uwvQbba7C9xl2uf+SugIfhEXhc/wi9 atCrBr1q0KsGvWrQqwa9atCrRtzCCIQYgRC6HWQEQuh3ihl0jBl0DD0/R5NmNGm2Tj77A/ommN9m BprfZgaaPyNsYHYdY3YdQ7tmtGtGu2a0a0a7ZrRrZmRCjEyIkQkxMiFGJsTIhBiZECMTYmRCjEyI kQkxMiFGJsTIhBiZECMTYmRCjEyIkQkxMiFGJsTIhBiZECMTYmRCjEyIkQkxMiFGJsTIhPBAMx5o xgPNeKAZDzTjgWY80IwHmhmZkLgNL/jxgp+x2IEX/IzHDstdIgXrp2H9NEYrjW+vr5rfoYea++og c18dZH4v9jNWOxirHYzVDsZqB96Yhjem4Y1peGMa3piGN6bhDT/e8OMNP97w4w0/3vDjDT/e8OMN P97w4w0/3vDjDT/e8OMNP97w4w0/3vDjDT/e8OMNP97w4w0/3vDjDT/e8OMNP97w4w0/3vDjjWl4 YxremIY3puGNaXhjGt6Yhjem4Q2/cDAXjmFxPyxeiMULsLgbFhZj4QMiGR+9i3/exTd1+KYOPyTg A/nfj97G/nex/13sfxf738X+Ouyvw/467K/D/jrsr0OPOvSoQ4869KhDjzr0qEOPOvSoY63k4+nO 8e64GGi5h1k6lViXT5ybTYybAwVQpO9WP7mIxroFxIxF+ibPw/pBTyUsgIWwCKrgEXgUHoPF8Dg8 AcRGD7HRQ2z0EBs9xEYPsdFDbPQQGz3ERg+x0UNc9BAXPcRFD3HRQ1z0EBc9xEUPcTHeBW7wEPM0 9dMvqXuENd7IGm9kjTfiNw9+86jVU643snYbWbuNrN1G1m4jukfQPYLuEXSPoHsE3SPoHkH3CLpH 0D2C7hF0j6B7BN0j6B5B9wi6R9A9gu4RdI+gewTdI+geQfcIukfQPYLuEXSPoHsE3SPoHkH3CLrL mDVV34O3G/DwR+0xS1q0RwzBomref8X7U4xGG6PRxmi0Ufdz6g6mbgYrxY2lqawUN9amMo9+IWM/ I9TGCLVhZTVWVmNlNVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVWVmNl NVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVWVmNltbgeSyoYm22MzTZLvujO+GzDglxWQAsr4ACW /AJLemJJfyzpiSX9seRZLFnL2G1j7LYxdtsYu22M3TasqsCqCqz638Tde5zcdX3v8d/ObHaTyS6j EG4qIA0i2FLkZlW8FNsaraJoq83BivYYkAACQgIsyEUSuZMQIAEM1xIDJClQJLTZ1KRLICREhiXL biaayW4uzoWdzOS3O9mQRfM9zxkjh3raR08fj/Po+ePlXPY3v9/v+35/bt8xu3RYVYdVdVhVh1V1 WFWHVXVYVYdVdVhVh1V1WFWHVXVYVYdVdVhVh1V1WFWHVXVYVYdVdVhVh1V1WFWHVXVYVYdVdVhV h1V1WFWHVXXI48mNPP6oVay3imf3/f+x9bliYTTeetda71prXWtdB1rTgX7ylPWstZ611rPWetZa z9qoJTGdx5eJ4MtDKTHTp2/XH+bWv2P37p7EzDASNfnf3dGxjtiduMJ7HY33X03cEI1L3OjTZvnE vOhdiXu9f1/YM/69eB8Ow+E4Au/HkfgDTMHZOAffxbmYivNwPi7A93AhLsLF+D4uwaWYhulwf+Mv h3sa757GXxn2NNazx53mE1eHqrUUEneHSuIe939m4hJ17VJM9+4VVtmBa8P6xHX4Ia7HzOiwxA1h RWK24+4IucQc3Im7cG9YY31rxifUsiSaMQYtaMVYjEMK49GGduyHNN6Fd2N/HIAJOBAH4WAcgkPx Hrw3xDSMaRjTMKZhTMOYhjEN4/EfD+vHn4pP4JP4FD6NP8Vp+Az+DH+Ov8BnMQmfw+cxxTrOxjn4 Ls7FVJyH83EBvocLcREuxvdxCS7FNEzHZbgcV6ADV4Y1UbPI2ULFASqWEvPCW2JpZnhDnOyOzuBC jQu1d0RSr45T0XEqjqhQuZaoT2nfCRUdpqLDVHSYig5T0WEq1K9Rv0b9GvVr1K9Rv0b9GvVr1K9R v0b9GvVr1K9Rv0b9GvVr1K9Rv0b9GvVr1K9Rv0b9GvVr1K/9pxH8l+7jC/giTseX8GWcga9ginOc jXPwXZyLqTgP5+MCfA8X4iJcjO+DNtStUbdG3Rp1a9StUbdG3Rp1a9FY6vaL8BERXk5cI4ZnRhOo vZXaW6kdRxfTuIvGXSI978gMrfO0zieulKlXc+Ian7w27BT5O0X+TpG/01la+LCOD+v4UE3MUjHv CNtkwDYZsE0GbJNLr6sNa3nUy6NeHq3j0ToerePROh6t49E6HnXxqItHXTzq4lEXj7p41MWjLh51 8aiLR1086uJRF4+6eNTFoy4edfGoi0ddPOriURePunjUxaMuHnXxKM+jPI/yPMrzKM+jPI/yPMrL kJ0yZKcM2SlDdsqQnTJkpwzZKUN2ypCdMmSnDNkpQ3bKkJ0yZKcM2SlDdvJ4HY/X8Xgdj9fxeB2P 1/F4HY/X8biXx7087uVxL497edzL414e9/K4l8e9PO7lcS+Pe3ncy+NeHvfyuJfHvTzu5XEvj3t5 3Mvj3mgqB8scLHOwxu/lXKxxbhPnqpyLORdzLuZc3f+D+b+Me2XulRO3eu92Ts8OT3JwBwd3cHAH B3dwcCcHh8VJDxeLXCxysczFMhfLXCxzsczFMhfLXCxzsczFMhfLXCxzsczFMhfLXCxzsczFMhfL XCxzsczFMhfLXCxzsczFMhfLXCxzsczFMhfLXIq5FHMp5lLMpZhLMZdiLsVcirkUcynmUsylmEsx l2IuxVwqc6nMpTKXylwqc6nMpTKXylwqcqnIpSKXilwqcqnIpSKXilwqcqnIpSKXilwqcqnIpSKX ilwqcqnIpSKXilwqcqnIpWL0YS6NcGmkkY0zozQXYi4Mc2GYAyMcqO+bhqk7TN1h6g5Td5i6w9Qd oe4IdUeoO0LdEeqOUHeEuiPUHaHuCHVHqDtC3RHqjlB3hLoj1B2h7gh1R6g7Qt0R6o5Qd4S6I9Qd oc4wdYapM0ydYeoMU2eYOsPUGY4+pDKMqgyjqvB2/TyVuNUqbmvEj7v3fB7u9fP7wqiMG5VxozJu VMaNyrhRGTcq40Zl3CitR2k9SutRWo/SepTWo7QepfUorUdpPUrrUVqP0nqU1qO0HqX1KK1HaT1K 61Faj9J6lNajtB6NzqX1AK0H3HHZHdfrV0EWFGRBQRYUGvr/LgNmi/I7VMM5uBN3wQSfqH+z8R9H +wA/BvgxwI8BfgzwY4AfA/wY4McAPwb4McCPAX4M8GOAHwP8GODHAD8G+DHAjwF+DPBjgB8D/Bjg xwAFyxQsU7BMwTIFyxQsU7BMwXo2FGRDQTYUZENBNhRkQ0E2FGRDQTYUZENBNhRkQ0E2FGRDQTYU ZEPh/yIb8hzKcyjPoTyH8hzKcyjPoTyH8hzKcyjPoTyH8hzKcyjPoTyH8hzKcyjPoTyH8hzKcyjf 6PFVU+mW6CNvV6+7VRyzJO3LtP/vqShTcDbOwXdxLqaC59ZYtsayNZatsWyNZWssW2PZGsvWWB5f j4XpuAyXQ7xZY9kay2bcy6zof+dMWcbX1Nt6po+oqSP/WY6Y3S8zY88UxzeI11s9v82sNNvue160 f/QlylUoV2lM5VfjGkfN9Hizun8L7PvkZr07xz51bGO6nev5vWGIwkOiuyq6q6K7KrqrorsququU r1C+QvkK5SuUr1C+QvkK5SuUr1C+QvkK5SuUr1C+QvkK5SuUr1C+QvkK5SuUr1C+QvkK5SuUr4i+ quirir6q6KuKvqroq4q+quircmaIM0OcGeLMEGeGODPEmSHODHFmiDNDnBnizBBnhjgzxJkhzgxx ZogzQ5wZ4swQZ4Y4M8SZocZuZTel1r29b4mjZGNfYyfNpbeir9G2j7Z9/Kvyr6qX7vLTTZwYT98i fYuN+jebS3erKHNNSveaYO8LJboW6Vqka5GuRboWU/XekAh9dO2jax9d++jaR9c+uvbRtY+ufXTt o2sfXfvo2kfXPrr20bWPrn107aNrH1376NpH1z669tG1j659YqoqpqpiqiqmqmKqKqaqYqoqpqp0 L9K9SPci3Yt0L9K9SPci3Yt0L9G9RPcS3Ut0L9G9RPcS3Ut0L9G9RPcS3Ut0L9G9RPcS3Ut0L9G9 RPcS3Ut0L9G9RPdSQ+O67oM0fjPaP7FUJHeFFxPPi8tVYVripfBoYjj8IrEr3JLYE15LtoetyePC YPL48Hjy5DDw9r9T/nr0nuTfROl9/155K7cWcONJGfa86F9lhn2BEy/iJZm2hjPrPM+YRV/nZK/H PhSjAxMlXWyXz434/G6MuloU+pOtGAu90dULyRO8fyJOwilhZ/LUsK3t26HcdnZY23Y+1Ie2izxS o40abepB21Uerw7FtmtwLWZ47zbv3Y5ZsN9pu8t7d+Mez0VP2/3OsSCMtD3h/E/h6TDY9o94xns/ 9XqZR2tq6/bea1iPDV5n8UvPN2HAcTtCf9swdof+9gmh2H4gDsIReD+O8v55YW37Dz13X+03hlL7 7WGwfS7uw6Mmlr/cp+oWHr1F1Q1UzVE1R9XfUHUTVQtU3UDVIapuoOoGalaoWaZmmZJlSpYpWabi birGVIypGFOwSsEtFNxAwQ0U3ELBDRQsULBAwS0ULPyeglsomKNgjoI5ChYouIWCWyiYo2COghuo V6VelXox9WLKVSkWUyymWEypmFIxpaqUKlOqTKkypcqUKlOqTKkypcqUKlNqwz6ltlAqR6mYUjGl YkqVoyMTi8LUxNKwhFKrxeCvKfQkVYqJzeEScXZdohQWiuypiVroFNlnirNcMhmyyZYwP9kWbmpE +oRwfPKI6LzkB8KNov4zyT8O36Ha8yL/i2JuefJT4dHkaWHKvm+kcvv+VfJ5yalhpSxYHrW5eh+f +lz95662nRcZV9vq7GVnHHa2PmeL5dCpcui0aD/3PeJT631qj0/V82PE/Z7o09l9GVh0Xzvc1/uc oc8Z8s7QG7U3VrrK5PRSeNonTvKJLa63yad6rOgtn9ziU0fs+1TWp/qjw0RU1acqImlYJA2LokFR VBNFJdfeJYpKoqgkKkqioiQiSiKiJiJqoqEmGqqioSoaqiJhWCQMi4RhkVATAcMiYFgElDhW4liV W8NqfDE6yr20W+8Cc90i1/1n97AMa8KbjX/DO1kEXBEqzp93/rzz59vu8/rBUHGefNTsU3vc+Tk+ 0Vt3Vt1YFF7meb93e72bSYiuhn6b1YsJtPta6HXe3miyq85y9HVyKe8TT7v61a5+tU/upsQuSuxy hg2JdfbmGdd5nSK9HvuQDYudcakIWp8oi4YUJoQrknpqUk9N6qnJiWFG8ih8gMfHeH0sjjNfncz3 T3t+Wqi5m8+7m8/LuTx191B3j5zLU3hP28XRhLbvw6RGhavbrvL86jCLErMoMUve5am9i9q7qL2r bbaf3+W9u3GP1/fiPp+737ke9PgPlHsSy8OMthc8/hyvIION+AVyftbvcQu2hhntUXi+fUxY3N6C Vhzp9dE4L+zhwCy5l+fmrvZ5HLkH9+LHeCAs1pG7GpG4ldOfVXX2qjp7VZ29XP8zGb5Xhu+V4Xtl 897offyIaV+mfZ72eZ9qf2dtsvbY2mNrj607b915666vNW+t+bfryr9TU9xr7D7z76wRTSlXnC4C fsT9Tu7P4P6MxM84ugJdsvWF6KDEi3hJDVknTtd7v14/srriRrvvX+CX2IQcNocbE/0et2Kb+Nvu 8VcooBj9ULQ8k3jD80GUnWOHxwqqrrsTsedDGA5XqEk9KnZBxS7I3qn12pR4y3u/xm/C64m9HoOs bkIC9brVLNrGeN4SnhKR05LjG1l/rawfSKbD3cl34d3YHxPCaaL1TNF6pmg9U09dknxPeDj5Xj97 H46Ivpk80uMfYGI4XSSfLpKvSR7t9QdxTJgsoicnP+T5H+G48FW1cZqq8grXFnFtEdcWifYz1MnO 5Ecc8yf4aPhp8mMeP45Tw4LkJzx+Ep8Ks2TFmck/9fy0cJ3MOEc93aKe1v9l9pXJM6PDk2dhani1 /h1529Swvu08XBztJ0v2kyEzZMh+omS6KJkuSqa3/dDPr8dNuBm34LbooLbbMQuzHT/Xe/Nwj9f3 4j7nme/1gx4fCne3PYJHsSAsaftJeFgXW9C2yOvFWIJ/CJNl1WSdbYEIXCQCF5kLluhuC9qeDT9t W4rnHLfMe8vD6W3/4vnPsML7L/ic2Gpb47wve28dfu69V5BBt3O9hvXocfwGx2ax0c9+gV96fxNy zrs59MjcybrnAtl7puw9vW2b98Rgmxhsy0McthVRCr1t4rBNHLaVIQbbqtiJ2LqHMOL5m+H1tj0Y 9fw3EHNtYk5VmNYu7trFXXsyvN7e7HGM91rQirFej1M9UhCD7W2ht70d+3mexru8/27sjwO8PyEU dPiCDl9oP9j5DnHMoXgP3ov34TDHHuHn78eRrvEH3lNhVaNp7deG9TJ8evuN0UHtvG7ndTuv22/F bbg9LGq/Kzws8xepVJNVqskq1WRVYJFqNbl9vvM84DwPOeejzr/A659gIR4LMxqTxLmqxE9VhbUm iX4V4WcqwS9l/M0y+1KZvVjWLpG1XfptTcb+k4zdLis3yMYXZOHTsnC9rPu8zDpbJj0qY26VMT+V MVtkya2yZJ0sWCH65+/7HafnRP9zjf9P+5LwavQ/1auF7mShjrUm8ZQevTSsU7ceVbcedVf16vnP qucq1XOVzvXEvh7epQcW3e123atL9+pSv55w5y+qU3l3nql3MHddUG+2qzfb3flm9TrnzkfU7Jya ndvX4R5TC55QC55wl7vc5UX139LQvda0/Z0Z9+zQpYN16WBrdLCut2eEy7y+Ijy6b1ZYKD8Xys+F OtiaNvuOth/hVtwWVqnqq1T1VY3Z4S4/vxv3eH0v7nOO+533QY/LwxPi/glx/oSYzusnOf0kJ27z ekpOrOb3da8nxOUT4vIJsZgXa9vF2naxtl1s5cVWXlxtF1fbG93tKJPkbztcl5haqMOt0TlWiY8n xEdefGyPpusSq3WJ1eJhpVj4CaWrusNqsfBl1bxHNa9X8RepmqPqeqquFxPPqNz9lO1WqXso203Z brERNyr0QeF11fh11fh1MXKiGNmjym5UZTfum9e6VdblKutylXW5mHlVNX1NFV2jcr6uIq5WEVdT vUr1KrWrKuBqFXC1CrhaBVytAq6mbFXVW63qrVbpVqtoa1SxjarYRlVsjSq2XBVbroKtUcFeU8Fe U61eU602qk4bVaeNqtNG1Wm56rRcdVquOr2mKm1UlTaqSstVpeWq0UbVaI1q9Dp3ulWWHpWlh0vd HOpWXfpVl34VpF+16FEt6pWhR2XoURl6OLWeU+s5tV5V6FcBeji1nlPrZX4Pp7pl/moZv1rGr5bx q2X8ahm/WsYvl+3LZftG2b5Rtm+U7ctl+0bZXs/y9bK8R5b3yPIeWd5jH1w0Gddn6pPDaHSKLKvJ qG/LqLkyaq6MeonPC2TNbr4u5OtCvi6ULQW+Vvi6mKeLebpYRtRkQY0XC3ixQAbUJ+UFIr4myueK 8rmifC4vFojymiivT8pzRflc0bybXovptFg076bVYlpVaFUR1bvpVRHJu+mzkD4L6bOQPhXRvFs0 76bRQhotpM9i0VsTvXNF7m5rXmiNq8INInaXFTzl1bB73xUeFJvZ6D1WVvVqo5X1W1m/leWt6mV1 oGBlL1vZy+6uvjt72d297O6q7u5ld1V1R1V31O+O+t1Rv7upupuqu+l3N/3u5mV3UXUX/dERrjTc 2JeMuNpujJoSf2NOjhrTS+xqPa5W71bDrlaPmR5XG3a1elcapsWwqw7TYtiVh115oytvdOWNtBh2 9WFXH3b1ja6+0dV7XH3Y1TfaI2wO91v5q1b9qivHrphXy/5exd2g4m5Q0x5QcddFLY4a2bd/ivf9 xtJxycnRxOgYWV6Q5QVH9Dti++92147st5IRK8nI8rpuGSvJWEVGBhRkQMFqMlaSsZIRKxmxihEZ UJABBRlQkAEFGVD4Nzvfgx1zmPd+twOe6PlRISOaC/XdrmguiOaCaC6I5kLD21+6szcb3o7xaqjx ncoejKokLfXfRjJVfSRZ/4u/4/WE7frADj8rq/U71M4daud2tXO72lmvjTvUxR3q4HZn29yIm9cb Z0o2FIyjo51jqZ8s4+6gc3U6YufbupghaDJIj0F6DLpG575/Y9nB5UH6DNJlkMuDtBnk7qB76HQP S93DUvewlNOD/0aT93r9PvxOkyMdf5TXR3t8wPEPNb4zKUdNVh9HB7u/wX19bpN72lTPXPe01d3/ yn1tdV9b3cdW97HVPWx17UHXHnTt+nU3ue4m193keptcb5NrbXWd+jU2RUc5+2NW32nly9/RA+p7 /U5XqjRqfqrxL3Xu2hdpmxqT7SXq477aaMXLXfUxV33MVR/7d+tivQ4e6bh6DTzaY72ePeDY369n 49zNP7mDzY1vG1oavxd7niu/6sqv7vs9odXRie4768hVXMvYteTd/xoqraRSJ5Xq9/6PIrqu1LO8 rk8FFWo9S61nrWeNsz7ibJ1czJgs6534WQo+y8l6lD8ryguivMDRjPWtEe0Fa8xaY9Yas1zNmBDz JsS8abDeoTsp3UnpTlFf4HKGyxmqd1K909rXUP5Za19j3VkuZzjQGb2X6t1U77bmtVZQte5/ddd1 5bvdccUdV9xdhdrd1O52lxV3WKFyN5W7qdxN5W4qd1O5m8LdrlShcDd1u6nbTd1u6nbLr13hTtqs p0dJhOkI8ul4PfuU8GaUNCu90vh27ZSwOTrSq12Nby0nqnFH4YQwpI8P6eNDjhjRwwdNVNV93zIO 6sOD+vCQPjy071vGwca3jMvVvd9+0zik9w7pvUPv+KZxSN8dMhUN67uDJqNhfXBIHxzS+4aicSaN 3e7kfpNF3PgG9+RQdNX6byQ8zsHHG9/ajjWLxMkJ7vm4xveD2xrfV5zi01+L/kL9Ozxqdo5tjXMc H96qf+9qtfxz/FbHbqHCBCs6Jexu6LHCs0p0oGfx733TWEmeafI9K2yx4ooVV97xzWDlP/hmsPLO HXz0fleqfxu8g67b6br9974RLrrKDprucIUdrrDjHd/c7nCVHTTdQdPtNN3xe9/e7qDpjre/vc05 ZsDrrSrhO76RjZqsuhYdlWxvOP4TM9ywGW7YDDfsnp5zT89Rarc5rmqOqzp6qPFd36f9/LTGb/kt pfxSdfj96nD931MXzGJVs1jVfT1n5qqauapmrqqZq2rGqpqxqu7nOfNV1Ww17J6eM+dUzTlVc07V jFONWt3NM65ca3zDWHfwNFf+Wuhyta5oop9uodtm97jJPW5yZP0b9TfoV6JfiX4l+g3Qb3f9eyoa bqbhbhrupmGJhiUabqbhbhpudq+baLiZhiUalmhYouFmGm6mYYmGJfe8iYa73e8mGpZoWKJhKTqI av1U66daP6VylMq5703uO0upforkKJKjRo4aOWrkqJGjRo4aOUrkKNFPhRwVclTIUSEXvcc6i9ZY tMZiQ43jnfkEHflEnISPypen1al/xLOeL8XyUDTvDllLxloy1pIx3w5ZR8Y6MtZRtIaiNWSsIWMN mcbvcNb/tfGh0b3RFJXgbJyDS8Pj0ZXhjugq/ABX4xpsCz+JtuNXGHLMnjA7GsVb+DV+E2Y3HRN6 mo7Fh/CH+CMchz/G8fgwTsCJOAkn4xR8BH+Cj+Jj+DhOxSfwSXwKn8af4jR8Bn+GP8df4LOYhM/h 8/hLfAFfxOn4Er6MqVH9v/q4tqkrvND0PFbhBbyIl7AGa/Ey1oUXmh8KdzQ/jEfwitcZvAprbd6L EGaPeVdYOGb/8JMxE0LPmANxEA7GITgUA+GOMWXH7MDOcEfLsfgILggLW76HC3ERpofHWy4D3Vtm h56W7vBCy0joaT06vND6QRyDY3EiTsIncGb4Ses3cFaY3XoPFmDA6y3YCp61lsLjrW+g6mc1r0fC 7LGJ0DM2Cf197Bi0wPw61vw6Vv8eq3+PHY82tGM/pKGnj9XTx+rpYw/Ax8ILYz+Ob3l+jsfrPD7m 8XHsCj3jnGvcAeGF6JvR/iLuAEzAgTgIB+ODOAbH4kP4Q3wBX8Tp+BK+jDPwFXwVf4Wv439gSlgi cpeI3CUi95Zomj3CdFyGy3EFrgxPiuYnRfOTovlJ0fxk8y0h03wrboOsaJ6F2bgDc3An7sLdkDHN 8/CQzz2MR8KTXF8yZkPIjJFdY3Lox4D38x4LKPv5Duz03m9CpqUF5uqWcUjhEByKD+Bo0KGFDqLj yZaTPX7E46keJ+GbOAvfwrdxQVgicpaInCUiZ4nIuUXk3NJivS3WK4KeHHtRXZtojpnqTtyFuzEX 82Deiurz1uN4AovwMtbh53gFGbyKbryG9ejB6+hFFtvCUjVhqZqwVE3oiex5ohp4H4ndyN5HnVip TqxUJ1aqEyvViZXNxdDTXMIbGEQZ9kzNFZhDm82hzebLZudsds5m52yuf24vQlgp35a2qgWtcr9V rrfK9VZ53irPW/8aX8OZjvkGzgorW8/3ehqm43JcgR/gBtwI+dZKo1YatdKolUbyaWXr33tc4PEp j8tBh1Y6tNKhlQ5ybalcWyrXlsq1pXKtR671tFpTqzXJuZVybmkrPeTdyqY/jppNI2PQglaMxTik ML7xh/MPj9pR/5vTH4+Oi07FlDBfjM8X4/PF+Hwx/rAYf1iMPyzGHxbjD0cd0f7ifKY4nynOZ4rz meJ85n/hb0mdGHViW5jH0XkcncfRxRxdwdEVHF3B0RUcXRG9Gb2bq7O4Oours7g6i6uz/rt+Lz7x 4ejQxAnRcYmTPX4anwvzE58P8xJfwFeiQxJTw6LEeeH6xPm4IFxvZrsw+Y1wk7ntwuS3PE6zk5mu T3dH6eRr0YRkD3p12b7o8OS2sDK53etfRcck842/6jAx+YbHwSjdPC06vHk6LsPluAIduBJX4Qe4 Gtfg2sbf0ZqpXsxUL2b+V/+OlmifJdpnifZZas38xu/k7x/mqTEzxwxG+6sv89WX+erLzDFvRYe3 JCG2WvbHAZiIY8PMlg95PAEnRcepKTNb/sTzC8J89WO++jFf/ZivfsxXP+arHw+rHw+3iKWWKyGW 3v5d/56w9f/4vf367+J/KayQafNk2jyZNuvtv8P1u7/BVf/bW/d4/7d/f+tE2TSr8Te4Bhy/BVsh 5mTOYpmzWOaskDkrWndE726toOr4mp+LPxk0q/53uv6f/Y7+O//W1zt+177+e/SpyWFeyrpSV4fr U9dC3qTkTUrepORNSt6k5E3qdszCbNwB603dibtwN+ZiHu7BvbgPP8Z83I8H8CDok3oYj+Dv8SgW RIeOvyo6ZPwPcDWuwbW4Dj/E9ZiBmfgRbsCNuAk34xbcittwO2ZhNu7AnbgLd2Mu5uEe3Iv7okPa /jA6dL9x0SH7pTA+OsS0+Kos2Nb4KyavNv7yyeGJy1WztGqWVs3Sqlm68V9MGIf6f49sPNrQjv2w v+n2AEzAgTgIB+ODMEGbAHImgJwJIKfyTVT5JpoECiaBgkmgYBIomAQKJoGCSaBgEiiYBAomgYJJ oKBKTlMlp6mS06Jz7bSm4jycjwvwPVyIi+r/Vh3fxyW4NHT8uxX1yjBJNZ2kmk5STSepppNU05Rq mlJNU6ppSjVNqaYp1TSlmqZU05RqmtJ38/puXt/N67t5fTev7+b13by+m9d38/puXt/Nq7wTVd6J +m+s/8b6b6z/xvpvrP/G+m+s/8b6b6z/xvpvrP/G+m+sWs9Rreeo1nOiQihHRZTwBgZRxg5UUMVO xBgKz6jsy1T2ZSr7MpV9mcq+TFWfoarPUNVnqOozVPUZZvqsmT5rps+a6bNm+qyZPmumz5rps2b6 rJk+a6bPmumzZvqsmT5rps+a6bNm+qyZPmumz5rps2b6rJk+a6bPmumzZvqsmT5rps+a6bNm+qyZ Pmumz5rps2b6rJk+a6bPmumzZvqsmT5rps+a6bNNZ0SHNn0FX8Vf4a/x45DRiTI6UUYnyuhEGZ0o oxNldKKMTpTRiTI6UUYnyuhEGZ0ooxNldKKMTpTRiTI6UUYnyuhEGZ0ooxNldKKMTpTRiTL2Ep32 EivtJVbaS6y0l1hpL7HSXqLTXqLTXqLTXqLTXqKz6edRqukVZPBqlNLF0rrYfrpYOmG/o5OlE/Y0 utky3WyKbjal0c2+EcqJKZga7nlnV0t8r/HXXSbpbOfpbJN0tvpfSXoqeWl4LLlcF1sRtSe7wo3J V8PTulxal0vpcgVdLpXcELbqdIv3/e2iwxt/5/IN7w9GY3S5tC6X1uXSulxal0vrcmldLq3LpXW5 tC6X1uXSulzaJF0wSRdM0gWTdMEkXTBJF0zSBZN0wSRdMEkXTNIFk3TBJF1ovifEzffiPvwY83E/ HsCDeChM0jkn6ZyT7Ls67bs67bs6ddGULprSRVO6aEoXTemiKV00pYumdNGULprSRVO6aMqcGZsz Y3NmbM6MzZmxOTM2Z8bmzNicGZszY3NmbM6MzZlx865Qbh7BbryJPRjFW/g15ITOPENnnqEzT9OZ MzrzHPu/rP1f1v4va/+Xtf/L2v9l7RJydgk5u4SCXUJOB580ZnuI7RRydgo5nXyaTj5tjHsa4550 9Ek6etquITdmr9chxC0RmpBAMkrr9Gk7ipwdRc6OImdHkdP50zp/2s4iZ2eRa3mfYw/DRO99wOuj odbaZeRMBpNMBumWD/v5CR5PiibadeRMCJNMCGk7j5ydR87OI2fnkbPzyNl55EwO00wO00wO00wO 01rU0RZ1tEUdbbkU0zA9dJgmOt6eJtRQ+9msSSJjksi0PBilWp6KDm15Gs96/k8eX/TYHTpNGZkW Xtr3Zlvqf5HzsJAxcWRMHBkTR8ZeuNNeuNNeeKW98EoTSMZ+eKX9cGfrqVHKnrjTviC2L4jtC2L7 gti+IG9KWWZfENsXxKaVOaaVOa1/G8qt38RZYYb9Qdx6gedyqvVCXISL8X3nvATWZe+Qt3eI7R1i e4fYhJMy4aTsIWJ7iLj1Fsff2vjLhrGpJ2U/EdtPxPYTsf1EbAqaYQpKmYIm2lfEJqEZJqGUvUVs bxHbW8T2FrG9RWxvEZuQ5piQ5piQ5piQ5rRud+5fIQ+1vlWtNzU9Y2p6xtS0zNS0zLQ0w7Q0x7S0 zLQ0w7SUstfP2utn7fWz9vpZe/2svX7WXj9rr5+118/a62ft9bP2+ll7/ay9ftZeP2uvn7XXz9rr Z01dGVNXxtSVMXVlTF0ZU1fG1JUxdWVMXRlTV8bUlTF1ZUxdGVNXxtSVMXVlTF0ZU1dm7Inu6SR8 LHSO/Ti+5dzf8XoKzsY53vuux3MxFefholAwoWVMaBkTWmbsdT4z2/uPOfbxsHLsE54vwq6QHRdF h5rgMuOsbdwBoXPcgVEq9VehJ2VfmPo6JocpJrspqb/1/IpQTnXgKvxu0vuh5z/CjVHaxJc28aVN fGkTX9rElzbxpU18aRNf2sSXNvGlTXxpE1/axJc28aVNfGkTX9rElzbxpU18aRNf2sSXNvGlTXxp E1/axJc28aVNfGkTX9rEl/7/OPGl/83Ed2A0K3y26azozKZv4++iK5r+Z/R3Td+JzmiaEk1JfC76 TGJq9Ink18LXk5PDV5KdoTO5IkxJbg09ZsMJye2Nv/H6SLIYMsmSvdQb9luDYSQ6Ipq1txgtDtuj F8J2Z//kvr9Ie4azn+bsp+37S7Ij9b8V7SqHukrKVT7pKpNc5Y7kv4SXkz/DipBK/qvHrrAt+byz rwoPufojrvxW8leNq3/Z1e939ZSrL3X1nmhsMuOIbvdkJ59c7957wtrk697r0xE3OKLNva1zb+sc +W29M+PoRxx9k6MPdPRiR39dH13pE9f4xIzoyPrfl3S3D+vmf6R7T02crpNPDbclLqz/287oyMSq MD3xUngksTk6NbHLfnSC+fn48FzyX3TfFdGHrWCNK3Xaj6aS6xt70YwunXb2t6xoQKe+aV+nTu3b k6asLE6WrKrxlwZDtelvouawMBqDFrRiLMYhVf/tbLShHfshbWf/Lnw8ZKJTMSPcHM3Ej3ADbsRN uBm34FbchlnhX6Nl4dmoMzzblDD/JNGMMWhBK8ZiHFIYj3a8C/pk0/44AGpJk1rSpJY0qSVNakmT WtKkdjSpHU1qR5Pa0aR2NKkdTWpHk9rRdDQ+iDNCT9NX8FXI7Sa53XQ1rsG1uA4/xPWYgZn4EW7A jbgJd4S1TXNwJ+7C3ZiLebgnrE18ONycOBmfxle4d3PIJG7hzIrwVa6UxdmIGHuaE+Xf/s1Hr0f2 Pp/cHSYk39ybS+7Z25Mc3bso+dbebPLXe5clfxPGJ/d6P+wtN4/Z+3xzS5jQ3Lo31zx2b0/zuL2L mlN7s83j9y5rbgvjm9u9v5/jpoWFzdNxGS7HFejAlbgKP8DV/4u6L4Gvosj6PVXVt6vvvd1JCGEJ YNgX9cMZMoy+cRmXUWdGVGRcBkEBBcQFRdlUZHEdQNmVRUEEQZwxDDIqIjsMiOASlsgiEpEECMGw NJCwBFLvX3WbEJYACcj7Xt/f6a6uruV01al/nVPdfS6oL6gfCLqtBd3Wgm5rQbe1oNta0G0t6LYW dFsLuq0F3daCbmtBt7Wg21rQbS3othZ0Wwu6rQXd1oJua80AfaEyrFmg2aA5oLmgeaD5oAWghaBF oP+CFoOWgFargVYG6HvQGtBa0DrQetAPoA2gH0EbQZlqYKhQTbEFCPJrh1SanYhjRVBd0GWgJqDf QS+4CsdBKsMeBRqDc9yn/QHCuB8b92Pjfmzcj/0x4qaDPgF9CpoJmoX42aA5oLkg8G6Dd/trhL8B fYvwd6B00ArQWtA6tdzegGs5oF9APmgvaB9oPygfdEBlyDhQPCgBVAFUVS2XyaBqoOqgGqCm0FOu Aj2jBsquoBdBL4GGg94DTVSfyTQcD6iBTkOV4VyOOe4KHH+L452g5gjfr5Y77XG9A6gjCPLojEH8 26B3QGNBaaBCtTxMKiNcAUeMrzDGVRhzdBjzc6Q96HFQZ9BToKdB3UEY7xGM9wjGewTjPYLxHsF4 jwwGDQENBQ0Dgd/ICNCboLdAI0GjQKNBY0Bvg94BjQWNA70LGg/CPUYmgCaC3gdNAk1WA6O3qfRo M9DtoDtAuNdoc9BdoBagF9TEaG9QH1BfUD/Qi6CXQC+DXgG9CnoN9A9Qf9AA0EDQ66A3QINAg0FD QENBw0AjQG+C3gKNBI0CjQaNAb2tJrqXq4FxYTUxLgKKqolkAf2nA/lzxBrMZeswj42kXsDPF0C9 QX1AfUGHgKWHQYWgI6CjwKpGyof97MN+9mE/+7CffdjPPuxnH/azD/vZh/3sw372YT/7sJ992M8+ 7Gcf9rMP+9mH/ezDfvZhP/uwn33Yzz7sZx/2sw/72Yf97MN+9mE/+7CffdjPPuxnH/azD/vZh/3s w372YT/7sJ992M8+7Gcf9rOv/YGxpSoTNmsebNY82Kx5sFnzYLPmwQ79AHboB7A7M2F3ZsLuzOST VRZmtCmYybbzArWTH1A7zZdNi2B3rsBstFJlYgabAhsuDTZcGmy4NNhwebDh8mDDafspHfZTOuyn dNhMPmwmHzaTD5vJh83kw2byYSOlwQ5Kg52SBpskDTZEGmwIHzaC9iDqww7Igx2QJy9TmfJy4w1U ewLVunw69Ox06Nbp0IXToQOnQ//1of/60H996L8+9F8f+q8P/deH/utD//Wh//rQf33ovz70Xx/6 rw/914f+60P/9aH/+tBX86Cv5kFf9aGjag+dmdBDfeigedA7feibPvTNvHCSyoSO+QF0zA+gU2ZC p8x0+6gsty+on8ryktROrxKoMqgmqBboJcRPMm83bVFTMK9DxxSz6XdiDrUXC6ieWEjV0L7fiv9S JbGYGop0aoa2bmbs+tV0I2z7ePE9paLd8/QqNvScLMRmU2PoC83MGrb+niEXWktsLTsVNS1Ss5B+ lqlzOq71JYH6GiEuQ6ekKLuLIqwF6G+gu0H3gB6jVFhvEVhv2nKLwEqLhPW/rlrgJwWj41rjExnz IXiIxaRgtsxBbCPMlmmYLTOMPghrHDVnQxPKpRvNmqJOmwoe9P8hbAPHMf/Jxqu01on0cxPjf66l WiW6o20WQYauo3jkbalW42wjUs+DLrhQ5eMsC2edkW+hOoSz1dSQLJQeAtkgCXJAYVAEFAW5IA8U hxrvpQqilfpKtAF1RivOUWtR0iaUtNLqTqlWD1BP0LOg50DPg3qBXgD1BvUB9QX1o1TY8qmw2VNh s6fCRk+FjZ4KmzwV9ncqbO9U2NvgxfA6GzrdHLTVPLVZLMAoWqh+QI1zoN3uwr13p8shExVw1dey gHtPokS2ki5hq6h+8F5aR9EKqWKemi/XnppFZ/NN1zeiJ/TbUXSpGA2arXLR03WgyXxi/YEus66m +mit1hSHHHGo5zfoze7ogXlqF2r6xtTkoYZfUEO6eAD1PwgNtB2OD+HYHbWsVBuhI+dBPz5i5Gct hZArQrb+NxakTkbKZKRMRkofKfKpMmUDRaFD0daY9z5TY08cgRPo9RAQdz3K2w/UzUcOX5epNeJQ oiqADV8AG74ANnIBbOQC2MgFsJELYPsWoM57ca8tUUp39Fw6cunS9IpplRPqfADltwM9SczUvQIt vxLxq1DfarRzBiRnDTTztRQ9p3qjQb1ZKC0ed1GIErNQYh5K9FGiHay+hcz8EYfUvmhp+MgEH5mi q+njuuBYCu25OcZLAXJGwUshcmsLxacrKJuuoi2graBD1IAOgwpBR0BHqQFKbmespQcwzh6ke0U7 HB/C8UlYMl1Rck+1WPRGT46CpI/GiIXWgzaqZ/pmtfrE1Pa9WocxlwQr5whkJBUykmqhbKsIpKhB KJGukq1ArUFtqIEcDZoM+hnnm0FZIPApdyNuP44F4C0MzgrAUWNw0xj3mhT0DmZXjADdx+sgM1rS FoD/BWiZHKROQuvkIEcScqQidRh87kTL7AOvPng9qNvV5Eo38ok+gizXxdgtgDzXFT2AhFlUJaav Q15z0Dv6O61ctdj8k4/us0ykiiAmH3wc8xAXvB0jukFGnsX43w55yEX724FP+xzkAbbhDraBclUm JVMHcNIR9Aiom/kHgwLwkw5e0pE6yaTORo3GisO1XCCiWXfFvHgdpYQSVE4oD7RT5didQU+CngJ1 AfUA9US5ccH/ImhPnJkoOVN0wx31wJ1mod+y1Q7c6aHYnaoD4LoQtSw3tncV8OeDPx/8+cWjpBVK agPqBt56oF+ykDMbvGs7OmZt6rv7Wf8HEvjzwZ8P/nzw54M/H/z5tn6m0phguVNH0COgXjh/AdQb 1AfUFyXH/jXpUmBUXOCHXiPOjcCo0WjlGWjlJZDL2ZDLayGXt4qPIK9Z4Cwb92a4wTyVgz7brjIh k1dBJq+yrlPrrfeosTUBNJEahxLo1tDPOObhuBO0hxrbl+pnn6DOdKv9JOgpUBeQ5s8J+kjLTCiQ mZDpq21GInyz+pAGvqcEqZKDVMng20fKVMOb7n9bdC76UBxUu2HrZVpS7YYtl2k1KloGnjsX/YzY AsQUWI3U/6DUzkXrRAF6qhC5j6CkoyrLCqlDVkQVWtBHkDILKZuYvNNwdT1i1qO0fJM3XRwGTui8 RyENCnnCJE1eFzZYHI6NVAolIuUy1FIIq9QHZ3lCvxVeiFqPqMPIuQo5C1BrIaxRHxznWdCKUMoh cHAYJa1CSeC3aDN6qjPs2Fgp+SilEKUUaZ5N3bHc+chdiNxFhvcYDyGqjJydwUOWOIA2O4jjIbQf tOTgzteLoxjTRWorSjoEXrIsm5JRWhZKK7DCmOVjLYL7p7Dlqa0o+RB4GqxnzaIslKjbIEcUYc6R 5v5zLA/hRopMio9Njxw2qWK9EjapdM+sRuue1F/QJ4J+Qu6z9I9Ja/oFac/SH5Rwvv1AblnbH1J8 gdsdMl5Ke5srp21nirOSyLEqodSqFLGqgaojTw3kvwRhaKtWTVyrg3A9UH1ca4BrDbVWaVVGGdVx tRaO9XUbWEk4g81gVUGaauaqb8pKQXxNhGsjXM+k9nU5ZJvUVU2t+SZFHVNLPiWCrxCu5lmVEVMF VJVSwF88UuahzBTwh3JBNXFeC9drg+ogvh7S1EdcA4Qboo44lJIDXvUdhqxk1F6NRFCKzp0D/vUd hqy6uFYP12K5Q5QAHiLIvdPcaVWUWw2pqqP1aiA+Vn8EJew0LVAH1+shrj6uN0C8rht3gfIr4Wpl tceqou8VEmd4QF/WQL2XIC4FaWoirhbS1NZtgDSGF6RpgDQNgXS6n+JNu1alpKCfCsFHEviIAx/x pm3r4DzWT4XgIQk8xOleMa0XCnLtP4F7fd+xHPuLuY4vr0xg1H6P0ElygdFek7yyygZy1cUoLUU+ cJVTxQslIyitEmLKKSfI7VKF85UVlFJZ39GFkRf0xGTTj+WSGXNHXlnlBnUehDZbULQKWNgYiGMB 1ZqIw0XzgWrVxZGixUCfP4iiokKgWoIVKloFbGwMNLKAak2scNF8oFp1K1q0GMj0B8srKgSqYQwW /YAWqYYW8dAinlW1aBlapJJVrWgbuKqHVrHQKtxKQbqaSFcLaWqD6iBdXaSrh3T1ka4B0jWE1IRh qcXDxrpV6H8RWmy0+iRouSnQKlL1uj20vWTzT0azWRu6hrWjW9lD9AZ7GMf2yKX/d+g+9aX4O7Sh lmqc+Xe8S8+Q6kuT6tg/Lo0rPptefMaZBwu4MRFdTdfTZbC5b6TfUjO6m5rQffR3xN4Pve1aepQG 0W00hD6iLjSb5uNsIX7D6WtaSyNoPWyO9yiHxdO/WXVWndayFNaY1rHb2R2Ibc7uoVzWij1Au1lb 1pb2sodYB9rHOrOn6ADrwcbQYfYOfilsHH412Xj8arF/sY9YbbaQrWB1+W95Kvsdb8qvYlfyq/nV 7Gr+R349u4b/id/MruO38lvZ9fwvvBm7gd/B72A38xb8bnYLv4+3ZH/hrXlr1oy35W3Z7bwD78ju 4J14J9acP8afYnfxrrwnu48/x/uz1nwgH8ye4EP5KPY0H8PfZs/xyfw/rBf/lH/JBvCv+Fo2lq/n 2SyNb+e/sJl8N9/D5vC9/ACbxw/xQraYK0FsqeBCsGVCCo99LeJFIlslkkQSWyMqi2psragt6rAf RT1Rn2WKhuJStkn8j2jMssRvxG/YFtFEpLKtoqm4kuWIq8U1bIe4TvyR5YkbxA1sl7hJ3MR2i5vF zWyPuEM0Z764R7Rk+0Ur0Z4dEp3Fk6i6q3iWh0Rv0ZtHRV/Rl7tilBjNPTFNTOPx4jPxGU8QM8VM XkHMEot5okgX6/glIkv8whuKAqF4EytkxfFrrCSrEb/Fus66jreyulv9eWvrdWsG72J9Yc3nY63v rBX8fWu1tZV/YG23FJ8VioQifFXIDbl8dSghlMgzQhmhH/ja0MbQzzwzlB3K5lmhbaFtPDu0PZTL t4R+Ce3h20J7Q3t5Xig/dIDvDB0KHeJ7QoWhQu6HjtohvteWdhwvtBPsBCHsRLuSsOyqdopw7Nr2 70S8/Xv796KOfZX9Z1HXbm7fK5raD9ovi2vsV+1/iIfsgfYbooM91B4qOtnD7RHiUXukPVI8bo+2 x4kn7An2BPGMPcmeJLraH9gfiG52mv2p6G5/bs8VfewF9n/Fq/ZSe6kYYC+3V4qBdoa9Rgy319nr xVv2BnuDGGX/ZG8So+0ce4d42/btI+JdSZKLf0kpa4mpsoFsKpbKq+V1Yo28Qd4gfpB/kn8WG+Rt 8k6xSbaQLcQWeY+8R2yV98m/i22ylWwrtsv2soPYJR+Tj4k98gn5nPBlL9lXKPmifMmy5D/kG5Yt h8oxlivfke9YleU4Oc6qIsfL96yqcpKcbFWTaXKOVUMulsutxnKV3Gs1lfsBcvc5DZwG1sNOI+cy q71zhfMb6xGnqdPUetT5g3O19ZhzrXOd9YTzF+c260nndud262nnTqe59Yxzt3Ov1c2537nf6um0 dzpZzzpdnGes3k4vp5fVz+nj9LFedF50XrZecvo7A61XnTecQVZ/Z6gz1BrojHBGWK87o5yx1hvO h84/reFOmpNmvelMc6ZZbzl7nX3WSCffybdGOwedg9aYMMDMejtshS1rbFiGpTUujM16NxwfTrDG hyuGK1kTwsnhZGtSuHq4hjU5nBJOsaZE7o60sj6MtIu0sz6OdIh0sKZHHo08Zv0n8kTkCevTyJOR p6zPIk9HnrY+j/SM9LRmRnpFellfRHpH+lmzIv0jU615kYWRZVZ2ZE1ko5UX+Smy1dofORStZh2J 1o0OC6VER0QnhgZFP4/OD42LrojuDX3gSrdqaLl7uXtL6Ee3pftoqMB9wn3alm5Xt7vtuT3d5+wE t5fby67o9nZfs5PcAe4QO8Ud5g6z67sj3LfsBu4od4J9qfu++77d1J3sTrV/737sfmb/0Z3pzrFv due58+y/ugvcBfZt7iJ3md3M/dZdbd/tfu9+b7dy17rr7dbuBneT3cbd7O6xO7j73IN2d/ewe8Tu 5RZ5ZPfxuMftFz3Ls+2XvLDn2a96CV5le6BX1atqD/OqeTXs4V6KV89+y2vgNbDHev28fvY47yXv Nftdb4A32H7fG+69af/TG+mNstO8t7237X97Y72x9jTvXW+i/bE3yfvQ/iyOx8XZs+IS46rYS+Oq x11ifxt3IO6wvYJ4+GXMKBSdnTCXGlJNuiCb+kltosawrEitOu31QjVETcOvQD2Hs7aqo5qqZiCU Za5mqRzsNwdpC07Jra/mKB+/49eSTkm1G/TqWTkdAPpPifP1KL2SrqHULaIOa+7UPoT1O7J/pgY4 zywuYXtxKOs09a1SG1Wu+ga/LLUH2vr5blVQ5gRTcrbKU8uP1a7yTqk5z7RanspE6z9E1dFil2rO g6uFZ6tI5atdaq/arrYWR1VE7C5z7TP0Xrz6HKEtp82LVGonai9QuaRbLYXq0g0x7nFlrVoLadmk Q6XUPV6N03epeoDuVDepl1R/hDYVX/+l5F2elLcQbf0T6l6kvsTd++ipUHDlh5NSLj1rG+ynQNLU MLP31W6UHkhhiZY5lj4fLbZXHVRrkO42c7fXoOUDLtUOtQP73CDtwVNy70abbdMyEoyLAqpmjhml 320pfGeecPZEifDccysB2xXHa0SPZVBIrTlLrXoE7ghOLqOmZ0w7Rb2j5UTLUNk3tVXfIaRr4ylX Np817x7QKyY09eQe1Oh0ltzZoNkGkTYcH/nnukGq880+4zQX48+phL2gn8tab5B3YXCcUY6875r9 Un3/F3i7+qx1b4/1qzoELN1VxtLP3KpXge41dWyO7WO/4OrpZsdL8auJ36UncDjF7FfEfmfI3eS0 ubeZ/U61H9i1vzRWcU2j2g71ox6HOk8Mw2NzHtBuifpafVVq7hKzqhpItYHId1BzhP9lYjIwT81V 60vNXWLeUiMwDyTTLbA8MYJMzI8YC0uOo3NpdesZFHKkczeF1RrEq1lqJubYUnHpONYHWzzarxXi nzdX56kv1EI1P0i785TcJWZ2tFS8mYf0rHK7iVmC2mer2aXWXYpeUKQ1gm/U/aqFekLdG6Q9BcnU QLTrMvWd2nQCznBqQ6/AQifY60P1Vyc0lVyaRjOpEc2B7Z5qbPcraTFs96voB9juzWClM2rJ2rF2 1A3W89+ou7abqae2mOlZ/jh/kp6H7bue+vAf+U/Ul2fxbHoZdvB2epXv4L/Qa9oapv68gB+ggbyQ F9Ib2hqmQdoapiGwhqM0TGifRCPFA+JBGiXaiYdojPW59Tm9AztS0dhQYiiRltsz7Bn0tT3Pnk/f 2D/aG+k7W9mKVmj7iVZq+4nWyLtkC9qg7SfaqO0nytT2E23S9hNt1fYT5Wj7ibZr+4kKtP1Ehdp+ oqOwn4YzId+UY5itrSjmaiuKedqKYnHaimIJ2opiidqKYnW1FcUu01YUu90RToi1dBwnwlo7rhPH 2jgVnIrsIaeSU4V1cKo5NVgnJ8WpxR536jr12ZPOH53r2dOwnDqyrrCQBrAesJDeYM9qG4g9p20R 9ry2RViv6AvRYayvtjDYW26CW5V94U51p7JFbra7h/1X6/hspdbx2Vqt47MftI7PNmodn2VqHZ/9 rHV8tlXr+CxP6/hsp9bx2R6t47MDWn9nB7X+zg5p/Z0VxYXjolzEVYqrwu24g3GHeRhys8bIDTNy wyE3o6DJj6Z3oN+MpcmI+QA/SVPoI3IoDVJlG6myIVVzKUzzIFsRI1sRyNZyxH9N31MUpa5B3rX4 eZC2jRRHmZSFMZYNyatFOeRj1OzFrzbtowNUhw7iV5cO0VGqR0WQywpGLmsYuRRGLl0jly7ksjMl 8Cchna6RzkRIZyZV5j9BRitCRrOoCs+GpFY3klrNSGoVI6mVjKQmG0mtyBVXVFEQ5DUJ8sqxx0aV ILUSYXQ7VRVhSHCSkeBqkOAHqL54EHLcAHLcDuGHIM0NjDTXgDRnErN+srYSt7ZZOWRb261dFLV2 W/vpEivfKqB464B1hFKso5D7ekbuaxm5r2HkvoaR+xpG7mtA7v9ESfJmeTNF5S3yFrLkrRgJIYyE 2xDTTDZDzO3ydpLyDnkHOfJOjJA6GCF3IW8LjJOwGSdRjJP7yJN/x2iJw2hpTbXkA/JBipdtZBuq J9ti/FQw46eCGT8M4+cJ5Oosn0aaZ2RXxHST3YjL7rIHaukpe6LkZzHGohhjLyBXb9kb8X1kH6Tv i1HnmVHHMOr6I80AORD1vo4RGI8ROBQxw+Qw5BouhyPNm3IUYkbL0eBkjByDGIxMiuiRSXpkjkeu 9+R7iJ8kJ6GcyXIyUqbJNMRMldOQ92P5MdphuvwMLTNDzgKfs+VstMkcOQdcLZZfgtulcjnKXCUh k3KNhDTKdXIDSvtRbqKa8meZjTbZIrejrly5g2rLX2QeWnKn3EV15W65GzXukXvB8365HynzZT6u FsgCxB+QB8DJQXkI5R+Wh1FyoSxEyUfkEaooj8qjqL1IFiGvkoqiGkeohsYR7IEj2ANHsAeOYA8c wR44gj1wBHvgCPbAEWLAkf7YD3AGENdoQpZGE2IaTcgFmvTGvk+kHyVoTCEBTFlLbnRddD150R+i eylB4wsJjS9UFfiSTRXdLe4WSnK3ulvJc7e526iym+Pm4Op2dztVcXPdXKru7nB3IrzL3YX0u93d SLPH3YM0+9x9CO938ynZLXALkOaAexBpDruHcbXQPUJRt8hVVMXD8KeKGrmwtzwL+5BnUyLwK0KV vKgXRRrX86g6sKwiYpK8ypSsEY0qA9GqYV/dq4E0KV5NSvJqebVQQm2vDsJ1vbpIX8+rhzDwDvHA O8S8641H+e95E5BrojcRJU/yJqPMD7wPqZJGQDIISAkaASkBKPXvAAGH4SeKEXAMwmOBfcJgXwjI NxXhafQF9rNotkHAhQj/F7gn6EtgnwD2rQFWrqV1CK/HTxrsEwb7kgz2VTLYFzbYV9lgXxWDfVUN 9iUb7IuyeBZPLmvFWmHfmQHpWBfWFfvurDv2r7PXgX0teAviBhkdIGMH7DUyRgwyOgYZPYOGFXke 1/8boRGwgkHARH6UH6U4g33xwhIWVQDqOQhHRIQSRCvRiqqL1qI1XWJQr4ZBvRTRRrRBfFvRFvEa AWsYBEwRD4v2VK0YAXNIAPv2kwTqHaGwwbtkg3eV9KooxudN8iYSBtckEK0Z9hrLhMGykMGyKrK5 bI4YjWVC3i3vxv4eeS9SahSrZFAsbFAsGSjWDmP7Yfkw9u1le6TsKDti30l2wl4jmjSIFg4Qrbvs jpgeQLSQwTIpn5fPG0TrhfQa0SQQrR/CMSx7Wb6CsEY0aRBNGEQLy0FyEHINlkMQo9FNGnSLBug2 Qo4gYTBOGoxLNugm5LvANRHg2gQ5AeGJciLZ8n35PlJqpBMG6ZJLIJ0wSCeBdLMR1ugm5Vy5COHF ciX2Gt0k0G0DwhrXkgyuVTK4Fja4VtngWhWDa1UNriUbXIvKfXIfcml0q2TQrYpBt+QA3Y4AxYRB sajDHEYihkeR5yLPkxN5IfIC9n0ifSgS6Qf0iUReiryEmNcir5FjkIhHR0TfJm4wpaK7E2gS7/ou 8NQgSLzBjorAjgMIH3QPURxQowgjWaNGgic8QXHAC0mewYsKBi8qAikSEdZIkehV8aogjcaIit4l 3iWIrwmMSARG1EYJGiMqGIyINxiRYDCiAjDiXZT5nvceck3yJiH9ZKBDBYMOnHjjlno1s8nha1+F RXJPaXr8/+ZN7VVZmkzYP3HlpjhNgdp6xjXK0srWK7I/gZabs5+OxWnrxawOFuoVsth6EbjwT1zB LN0eDK6vDo6PlJ2zC7Wp1mqcOe49p9RZKl1be+e6jlZqOXknhvU6a/Fa2V5YfVkqU7emWlec6njv BSvXps21N4AUitepTdwpa9+/6hYJOClZazz90cT9fHLvq12nrndBer5Ty9WB8sjm2Te1MjhmB5K8 p8S1fce4N1ycpj/VxtOPpQvCWZlLVhPUaHMsUCshGStA09RbanXQ78X8m5XFlZChZeUa73lU4ilE 7LlJiauD1B7gSF7Qots1JyUyH5OG/HOo5yCd9mnH+W7oyePc70db7QLpVaMDJ6TacWrO/21b8ZpX 7rnJyvki0hnLPt1qc+mpl6oZaomarnEK4djKZkawRplbnGrbcWwrQ9k/6vXLAPt2mCdAPhBEPxWZ Fisf54tx/EoTwiesZ6o00viUeuyugLoZQKnrqbZaF3sSoLJVujkOObbCd35byadbsadH6t/F5++q x9VA1U4tQPiB4tibVGc1y8w0J7X66VAKdzBbLYCMl7p2Wk6+9xqkCbjXnJgWLzlr+SVXxtWGM5a2 7MJyV5YNaBQ8f1PdT7qyRL1WHC6ewSARGi+2YGY94z2VUptGTN0Xpm2MfO4I2gl71cPUI83z4JNn 6iTzllbJsrQG8BPmrIguKdANDgXX/LO1+TnwehwpSzwFO4aNMX0EGJ9j6jpB8sx4yzllfs8r73Ol 8m4xrbTEeanaT8knmCVi51xYfkqUfG8ZEpvnPGpA8EyxACN6m35CqKartNiTwhPmdz+Qss/VJ+Xg ay70gplBeBkw2jzP1eNTywB0jKzgmUqBQdb1gXYRQ1HvpLIWGOyZYXB+QewZiPr6hBRHy85hkHM1 lXjaHiDnaoNBC0wYWGhwc1FMCmJPJGOjI7hyi7rZnM1Tj6AlHwe9rAbj+KmJXXJCbZ+i1burv5WD zy5qnMZu3P9mhFoj9BIshHHqI8yBw1QLNUJbDIjVNsPHalJszKhOJnPSseepQVkZGO3Q/KmRCces rED70k/1zPsjWj7K8Q6IkZriJ9uxuTgIZ1Jg+xy34+hE3azWye89/PpbSR1SP5NTO/Wsf8YcJ+n3 F2c74bmmebKudp5ZEzOtfHGtNCrZnpCfg0aPyj+zfWAwphx8lv78uQxlXNT2UePVq2qI6mnCWbBG p6i3gyt56ntz3Akk3nlccytXLTep8efJ54+wvdKDlZgtaq36tsQ7ZEavhsWzQu0rfn+gfLWcZc3m jHmzte6NYxHoW+jnwWxg3jfQ7/YYjb+0d7Yu3gbUbqe0T+Oq5uxZnHeDpWIsZ90CqlDNVMPV1ZhD 0oHhE8rXc2qMOdQ9L05j/bo4OAus2NhKAJWwps5/K8N7XaWVsMe0oMbhXOirp/Qyrm/QVt+FtlXK ukGzygUXMXt0B+R0T4lrZpaBHH+LEfb1abNftA18ppV8dwW4tPj/HTen21RH9YBGSG3PYD8E59PV dyYcWHyQg5nqLjWItP31c/lk7GL3A6Tj0MWtsWzbMdRXv5z6/mgZSvlV18ACjTIPc9bu81vnK+/a gX4+cY4pPzZvG5/8llhZt9rnmf+cN8zx57HWp4ZfOE5KqSHAd7XrfHr+Qs5tpdaRqQ5f7DWLsm/q C2MznG97NLwgzPxq2/l+2YCZphxPa8xacvHql3lH+NjYipQ+yoyOXJdakSxHjXnlQW3d+8fttWAt 8NzeHnfNO8r/P2zJ5cmk1/DLkWt1yZlFf8eBearg13kK+Wts0F/3n33GUkfKUXJGed7QN5p/7gln x9oyfIZcWoKTqRlk9CJv2hotDucaO2DzmRHIrIdf5HWbklyeVzmbA/rylEuXBt8SJJX47qAsJa9A u604VosOGTr2LcSx+q4xNZ3AT4mz/sdLC2hK7Fhi0988NNFHNTv2vkYZ+ZyCfFOCsAmZte/ZwT0c 46DJSXxOKXtNxXl/Pv2XjGfJ9UPJO9clnPr0pdStXCsN6KVtZ091Sq7cYLybZ/7medCx9ykiZ/gC Rd9HMt1YnvGutp1tBfi0uTYEFHuqoVe3d1HwdOMMuWKrpcknjj+1Xm03X3teSjVwNM9GMfsYrcNI 0/1l5++MvC8y+2KbX/VS7dRENdo8HT4+Zlqr982x8NT3Lk7zhaCvdv46q/nmjZDYs6r10HEyYJ2u h35d/GWMeWKjV/JvUPeZ869VV6R6XC3DHc1UTwfrmic80zLzSEd1Zzm46YxSmwdhEzLfDY9WM9RC NVK1VUuMRCSbJ9urj1lU6kkdR/X10yHVTXUxcQVo801qAu5lhpqu/hU8wTlhDcvMDUPVm+Xgc7Ja Wryat1RNxP6jQB/JVp+oNxG3J0gaLmH5xxCwXtnru9jbxXgiY6Qq9r7CKfJ+EWrPLNfzuFwqsQIT SN/Zy6kASqRbTbge9Pq6VEffP0aW/oef/0ONgEdZoByMvhyMnNuBE/HqdyZ9tLi2PurWIBh78ryk +HtOGXv7JUj3RSm8xxBvNPDezDiqn2qhngG9RnXUNSZJgO/mC+zr1E2qk3oQoXmawN8E9ZFabt69 idVWixpQHI7m23JIfNpZ2+FUnqbHKDibjXsq8RwjeLsmFZpmTdL/xXfsO/L5JdJULtqrXPUntQW4 tEB1QRlj1BDc12w1uGSr0LHvuV+O4UMZ+Xwe8hL7RjiEUBf1mBpsZGi9eePTi2F+CUvIfHkeezPg nPWAE2vcceo3jeeQyw/GrrFwzbObfWSbS/FnmN91jmS6Fv3P6cuz+B1qFfgdepn+yjirRB2MT6Hn jE+hAcan0OusFXuQhrHH2GP0lvEmNJL1YK/TGDaIjaZp2qcQzdY+hWiO9ilEc7VPIZrHFrEVtID/ ljehdN6UX0krtU8hyuDX8+vpe+1TiNbwv/JmtI535d1oA3+OP08b+TD+Jv3EJ/PJlMU/5NMom3/O Z9IvfBafRTv5XD6fdvEl/Evy+XK+nPbx73g67ecr+Soq4Bk8gw7ytXwtHRKu8OiwSBCJdET7BSJl /AKR8QsUEvVEPSaNXyDH+AKKiivFlcwzvoDijC+gBOMLKNF4AaooWonWLEm0EW1ZZf3tBauqffWw atpXD7vCmmnNZ620rx72sPbPwzpq/zzskVBCqALrFEoKJbPHtJce1kV76WE9tZce9oL20sN6ay89 rI/20sP6aS897LVQfqiQ/UN75mGDtWceNkp75mHjtWce9p72zMMmac887CPtmYfN05552HztmYet 0J552FrtmYcd0Z55mNKeeTjXnnm40J55eEh75uG2PcGexF3tk4cnaJ88vIL2ycOraZ88vLb2ycPr a588vIGdYa/nV2hvPLyp9sbDf2/n2L/wq7Q3Hn6t9sbD/6K98fBm2hsP76i98fDu+msM/pzDHc6f d2xH8l5O1Iny3k68k8D7OElOEu/nVHWS+YvOJc4l/GWntlOHv6L95/DXtP8c/g/tP4cPdJo4Tfgb 2osOH6S96PDB2osOH+rc6NzIh2tfOnyE9qXDR2pfOnyU9qXDx2hfOnys84jTiY/TvnT4eKe7051P 1B51+Pvaow6fpD3q8MnOQGcg/9AZ5Azi/3SGOsP4v7RHHZ6mPerwqdqjDv9Ee9Thn2lfOnyG9qXD Z2pfOvwL7UuHz9K+dPgc7UuHz9W+dPg87UuHz9e+dPjCcHK4Bl+svejwr7QXHb5Me9HhK7VXHL5K e8XhB7RXHEHaK45wtFcckRC9J9pepOovOcRN2iuOuM2Vbry4W/vDEQ+4rd1HxbPaH454TfvDEW9o fzhiiPaHI4ZrfzhihPaHI8ZpfzhikvaHIyZrfzjiQ+0PR3ziTnbTxKfaH46Yo/3hiEXaH45Yqv3h iK+0PxyxTPvDESu1PxyxTvvDEeu1Pxzxo7vZ/b+UnH9clGm5/+/59cyADyMiIiISy7KKiIhILIuI yBprRKyZmcdMBhiGYRxmhmEYhmGYeWaYXxoZkbFkZmbmMTKXiMzMY+Yx47gej18zM4/rmvk1M4/H POaaa3Q+9zVI1vevr7yuz9xez/3czzMPw3W/L14vPjcVv+FuNorfcjcbxS3uZqP4PXezUfw3d7NR PORuNopHWrlWo/iTVtRqFc+0SdpkxV+5g41Srn1f+75SNZ1NlykFJpf9FBVKi0o0nSUyGfbWGUyB 3XU2sqlsLipvOnsF+fn4UrMFbBHTsDxUtDicsRx7XxlbgT21HNVNpOomUnVLQHXbgLM+ja/pqHGf xdpbWCPO0E/WOzuu046vFczBXGwm68JXMnMzL5vFfKiGKaiGIpstS5BpWSr9ddgcWSLqYxrq4wJk cmQ5bLFsoSwX+UWyRRjnoW7OprqZj7r5JnQtqmcFObLNln0WNXQJ1dAlVEMLUEM9yPfIImypLCqL Ys1tqKpzUFW/wApl/bIvs2WyQVTYfKqw+VRh86nCLkaF/TbGw6izi1Fnf8ZWy87IzrBXZT+XvcNK ZOdQeV+jyitH5S2Cfhj1V6D6q6X6K6f6q6X6m0T1t5zqbx7V3yKqv3NRf7/NMuTD8mGWLv+O/Lss U34YFfklqsgvUUX+ECrycei/oC7Po7r8MtXldNTlf4eeR3X+EKrzBej/QY2eRzV6HtXoLNRokWUr ElCpX6FKvYAq9XxU6lS2UDFHMYflKtIUaWwlr9oYo2qzHFTtBdAcxUKchdrNFvHajbNKFaXQ5Yrl OLpCsQJarijHHNRxKOo4Mvzv7Crp7+xep7+tq6S/rXud/p5uFWq6j5UqJWWEyVDZ+1mC8ovKQfZh 5VvKITZD+RXlHlas/LryG2yWcp/yu2y28rDyBywV1f+HbAn3a2NL+R7ASvgewOL5HgBNVCWyMtUM 1QyWz3cCtgQ7wSWmUP1S9Uv2IdVl1WWWoPqV6ldMqbqi+jVTYYe4hsy7qneRua66ztSq91TvMY3q huoGm8l3DjaN7xyYc0d1h01X/V71e5aI/eMPTKa6p/ovXOu+6r/ZDNUD1QM2i+8ouNafVH9iKarH qsfsNdX7qvdxV09UT3Anf1b9GeOnqqcYf6D6gJWq/qL6C1aeEORshqAQlKxUUAkqJsM+pGYo44KG TRPihHiWIEwTpjGFIAoiSxEShAT2mqAVtJiDvYpNx141E+cmC7NwbqowB/PThLksUUgX5mHlDCED 574kvATNErKwwsvCy5ifLWRj/itCDuYvFBayWUKukIv8ImERUwp5Qh4ThcVCPtZfIizBuQVCAVZb KizFnEKhEOcuE5axeL4v4lqvCq8iXyKUYuZyYTlWKBMqmEpYJXwEM6uEKqYW3hDewD2/KXwC72ud 8Cms/1lBh6vXCw24SqNgwDrNwla2XDALVlYm2AQHrtghONkKoVNA3RC6BDdLFrqFbtytR/DivfgE Cev4BT9WCAgBrBAUglg/JIRwNCyEsT72ZjaH781sMfbmL7KlwoAwwAr4Ds1mY4d+C0eHhCGWKnxF wM++8FXhq6xE2C3sxnPeK+yFfkPYx5ZwZz3Mxy6OFb4jfAd6SMAnUzgsHMa5bwsjrEL4nvA9rDwq fB9HjwhHcO4PhR8if1Q4hpk/Fo5j5k+Ekzj6U+EUK+R7P/L/JvwbZp4VzmL8jvAO5pwT/gNzLggX cCe/EH6Bu7ok/BL3eVm4zNKEXwm/YsuEK8IVnAVWwPzrwnWs9p7wHub/Tvgd1rkj3MX8Pwh/wPw/ Cn/CnMfCYzyB94X3cT9PhGdsNucJVgCeSMBYq57BlqqT1DPZHHWyejYrVKeq09ky9Tx1JssHbSxg Jeoc9UK2Wp2rXsReVeep85BZrF7CXlMXqAuwwlL1UswsVBdizjL1MhwtUhchX6ouxVWWq5djZpm6 DPkV6hW4Cv8bUhmnFraEUwsU1AIFtUBBLVBQCxTUAgW1QEEtLJVTC5vDqQUKamFpnFowBrWwEk4t bDanFswHtWAMasFRUAsU1MIKObWwZaAWA+Y3a5rZa2AXK0vQ2DRtmAOCwbkgGORBMJgpaSSs49f4 MQ5oAsiDZnAnoBnM/4LmC2yppl/Tj7PANKwATDOIzFsafLo0Q5qvYvzPmn/GtQ5qDrLVnHKQeah5 iBX+R/M/mAPWYYs567A5cfwXHxVxsjgZm82JBxkQDxT/2GIQD/bHuMS4RFYI7pnJSuKS45JZQdys uFnsNe4nyJbGpcWlsbS4uXFzMU6PS8c6oCK2FFT0SaaNXx+/ngnxn4r/FMYb4jdg/On4T2O8MX4T S+LMhEwkfj+Tx38r/hDGICeMQU6YA3LCnD9PkzH5NPm0NFbO+YkVxf4SlvMTk3N+goKfoJ8RP8PS xc3iZvYh8bPiZ9l0cYu4hWWIdWIdyxJ1oo69JNaL9UwhNohNGBtEA+Y3i82YYxSNmLNV3IqxWWxl L4sW0YI5VtGGOXbRjqPtooPNA5N1Iu8SXciDzKAe0QPtEb1srugTJZYp+sUAZvaKvZgZFEO4YlT8 HDJ94g6sDHrDVQbEAeiXxJ2YMyi+hXseEoewzlfEXRh/Vfwq5u8Wd2P8NfFrWHOPuAdHvy5+nc0X 94p7WQ5nPrYAzLef5YrfEr/FVooHxG9jPCwOY853xO/g6Nvi29AR8XtskTgqjuLo98UxHP2heJQt FH8kHkPmx+KPkQEpQkGK0J+Kp1i2+K/iacz5mXiGvSL+XPw5Zo6L47jKOfE/kLkgXsSa4Eisf1m8 DP2VeAVzror/iaPXxGtY513xOsbvie+xpeDL32C1m+JNNp9TJpsHygywuQm9CUH2UkIoAU8JxBll ixK2JeBZJfQl9LGMhM8nfB6ZLyYMsNyELyV8ia3kJIoMSJQt4iTKkjiJMjknUShIlBGJsiROomwJ mCiPSPR1IlE5MWiMOGOsOe0Fskxg/4SvBGLKjxBTvvECU36UmDKZmHIWMWUKMWXqC64HKnI9EMj1 QEWuB6pJxxfueqAi1wMVuR7Ek+uBilwPVOR6oCLXA5FcD1TkeiCS64GKXA9Wk+tBFbkeJJLrwRpy Pagm14OPketBDbkezAbjTgNxJsgSiG7ngG7xxYqIcYvBuG+CJjnFvin7lOyfkOcU+5rMIDOwD4Nf O6BOmZuVyjxg2Q+DZaNsOSh2G8afk30O8znLfhgs+xZbAYrdzcrBr2PQH8h+wFbKjsh+gqOcXz9J /FpB/LqK+LUS/FrAlMSvSiLX6USuSpArvkMg14+ymfKPgV9nki9DzLFGS74MWvJlSCJfBi3R7ceJ bl+Vb5NvZ2XcdZitJcZNJ6JdJH9b/jZbKD8Kon2ZWPYVYtkF8nfk74BcOcW+JL8ov4j8L0GuL5HX w1z5r+XvgmXfk78H5b4PueSCkyO/Jf+/yPxO/jso98KZR34QWfL/kt/HmLtCZMv/KH+IMfeGmC// QP4MY+4QkSGfkP+VzSOfiEyFTCHHmLtFZCtUChXG3DMikzwjshTTFNOQmQ5uXkzEvJSIeRkRc61i riIdec7NixUvg5vzFfPBzYuJm5cochW5GOcp0EmBoZexQjD0qxiXKEpYnuI1kPRiIukCRRlIerFi pWIl1uckvZgY+hPE0OuIoT9BDL2O6Pl1cPMguPktsPIMYuUUYuU5xMrFyiNg5dfAyqfZcuXPlOfY SiLmVS84WajIyUIkJ4tEcrKoIYZ+gxi6nFwtqoikS4ib1UTMaiLmBGJlNbFyiuqW6hY4+Lbqd8hw Pp5FfPzGC3ycQnycqnqkegTlBPw6EbD6BQJ+nQhYLgggYDWxr5rYN5UY93WiW/ULXJtKLPs6Uaya KDaFKPZ1kOtiHP0bs75OtDpNKBKKMLNYKMZMzqyvE63G2FRNPKomBv0IMegbLzDoR4lBk4lBZxGD phCDphJrpgp9Qh/I9fPC51kRsWYJ8WWpMCgMIs/5Mo34slzYI+xhlUSWRcI+kGUpkeUcIsvlwgFh mK0EXx5GhjPlm0STy4UxYQxncaYsIqZ8E0x5FOf+CGQ5h8iymMhyufCvwmms8DPhZ5j/c+HnmM/J cg6RZTGR5XIiy1XCReEiVuB8WU58WUR8uZz4cgXxZSXxZZrwrvAujnKyfM6U94QHyHCyLCayLCGy fFOYECZYKTFlKTHlcjDlbIw5Ta4gmixXv6R+ha0kplxFTPlJYsoKIshyIshPEkGuIoKco35V/SqU E2QlEeQq9Ur1SqzJ/VZE8ltRkd+KSH4rIvmtqF7wjqomvxUV+a2o1OvU63B17rqiItcVkVxXqsh1 JZFcV2rIdWU2ua7MJtcVFbmuqMh1RUWuKyK5riS+4LoikuuKhlxXRHJdmU2uKypyXRHJdUX1guuK ilxXRHJdUZHrSiK5rswm1xUVua6I5Loy+wXXFRW5rojkulJDrisqcl1RveC6oiLXlXhyXRHJdUVF ris1L7iuqMh1RSTXFRW5rojkuqIi1xUVua6I5LqiIteV1eS6UkWuK4nkurKGXFeqyXXlY+S6UkOu K7PJdUVFritV5LpSTa4rNS+4rqjIdWU2ua6o0AOAYkH8r7By4vuVmgWaBWw5KD+HlWoWaRaxYk2e ZjErAvHnI1+gKZjk/iJNoWYZqyT6L9IUa0qgvAdYpVmuWY51KjQV0CrNG9A1mo9htRrNxzGnVlOL nuFN9APLNZ/WfBp53g+s0NRp6nAnDZoGzI95U/EOYRU6BBOuEusQ2jR2rNCuacdZHZoOVqHp1HQi 06Px4f55n1BCvcEc8rIqog6hVLNDswPK+4RK6hNKNV/WoD5Qn1BEHcJyzdc1X0fmm5pv4uq8W1hF 3cInNd/WDOMs3jMs13xX813MeVszAuX9w0rNI80jrMD7hxLNB5oP2ArqH96k/qGc+ofSOE2chhVR /1ASFx8Xj3EC+ofSuBlxMzCfdxGrqIuooC6iMi4lLgU9xuy4VMycg16imLqIOXGZcZlsJbqI9Ww6 dQ7T0TNsZDPjN6FzmBm/OX4zMo3xjaws3hRvgprjzVBLvAVqi7dBHfEOKHfY0ZLDjpYcdpLIYSeJ HHa05LCjpQ5EST3Gx6fNnZbFXp1WPe0TrGyafpqbrZ10AuNdhwKdxiKmpF5iEfUSC8Um6iVaRBNI l/cPL1HnsAidgxVjm9gGgneKTmR4z/Cy2C12I9Mj+kDzvE94hfqERdQnLESfsB2Zz6FbWEjdwgLx C+IXMJ/3CYvEL4uDOPoW+oQF6BO+gtV4n/AK9QkvUYfwMnUIi8VviN+AflP8JpR3CMuoQ6gVv40O oQAdwiHkvyseZkuoQyigDqGQOoRl6BC+j8yY+AOWJx4Rj2Dmj8QfIc/7hHzxOPqExeIJ8QSOnkaH sIR6g2XUG9SKZ8V3cPSceB553iEUir8Qf4GZvDdYJv5avIr8f6I3KERv8C5Wu44OYR51CEvEG+IN XJf3CUupT8gXfyuCtcjzKJd81HLEu+I9ZLj/UaZ4X3yAMXdByiYXpExyQcolF6RMckHKIB+1eeJf xL9AuSNSrvhXESRGvkhZAGSQGLkjZZCn2jzySJqboEnQYMydkrLJKSmXnNVyErQJ05HnrknZCTMT ZiLDvZPmk3dSRkJqQhqOcgelXHJQyiYHpfnkoJSVgC8c5T5K2eSjlEk+SlkJpgQT+h/eEb2CjsjP 0tER4fOQEEmIsAXoiPqQ511QIfU/teh/vozxYMIQW0JdUGHCroRdGHM/pmzyY5pLfky55Mc0n/yY smNubUw292G6hFdRsZ29x5huE0KHMCDMCDvCNfUqazuAV+9kLojYjuhHDCJ2I/YhDiIOI8YQxxAn EWcQ5xAXEVeYPGChYLrrFPKAA+HG+BbiLuIB4jHiGWP1coQGoY1duz4ZkYbIfOF1/gv/z4utVV+I KEGUI1a/8FqNWIvYMHkOf92MaEAYEbivesfUqzwgUcjaDiFGMQ5P5WLRhxiYHLsRQ5PjPZOxfzKG ESOII4jjiFOTc8dpPqvn98xfw4g+xADdV2zueZrH6ocQexD7EcOIEcSRyetdwvg44hSCzz2P4Lmr k8evTsYN5Hjcxvs5ijgx9V5Y/T3EQ8QTxARjDUpEPCIx9twbUhDpk69Zf3udmp8T+wzwV5qfGPv/ 1PF8RBGiFFGBqELU/O2Vf/8a1iE2vvC6BaF/4dWEsE29ygO3Y/fd4Iy9twbP5DqB/7+gz/WLEYwF v4+/W2/dP0QUsWPyNfr/rCMP8HvbidgV+9407EUceOH1EGJUOaOu1FLlc+iuW59xtclJNdBbNi30 ri0Z+sCWBn1sy4Q+s833OfhZ0qN6uS1PelpXYanxueuqLOt8Ur3GVkhaMjXW2sp9Ej/qZ3U1lo2+ cH2ybbUvHBtP6jrLFl9ffZqtmnTtP4wzbRug822boXm2Bmihzejr42f5hbqNFr1voG6LxeQbqi+x WaDlNgd0tc3tG+J5v1int9h8e+qrbRJ0rS3sT6ozWZy+/fUbbH2kA6RD0M22PdAG236o0TYMtdhG oA7bEajb4vSn1ku24/6MOpvF4xuuD9tO+YbrnJaAb6S+zxLwZ9d5LFHfkfoB2zh0yHYeuscS9efW 76f8Hq51AcsO3/G6qGWn71T9sO3SlI7YrvpO8by/YFJ3WHb5xuuP4CjXG1Pj47bb0FO2e9Bx20Po eduTKb1km/AX119tU/rL6nZa9vrO199oi/edp9UuTWZutyVC73HlGX9l3S7LAd/V+od45lyrn495 3r+mbq/lkO9G/ZO2FN8NPvbX1k+0pWN8wDLqu92gbMsizZkax7flQxPbiqApbaXQ9LYKaFZbFY1r oDmWUf/6ukOWo757daOWE76HDflt6/yb/k6L2jb6N9UdtZz2Pak7YTnrm2gobdtCqp8aV7SZfBN1 py0XJGVDVZttSmvanJKy7qzlshRvGnHfJ31E+hR6pJtBj3cL0FPdInS8Owl6vjtViudnBWtNl7oz IgfrLliuSYl1ly03pRTT1e5s6I3uXFI+vt1dIKXwo5HDddcsd3wjpnvdxb6R2HhSb1ruS+mmh91l pJX/MH7SvQY60V0rpW9Vdq+HxndvktL5WZGxujuWR1JW3X3LUylna2K3DprSbYCmd5ulHJ6PHKt7 ZGVS/tasbjs0p9sVOVn31CpIRVvzu72kQdLt0KLufmhp9yC0ons3tKp7H7Sm+6BUxM+KnNm6rvtw +KaO6dZIpVs3do9JpTrBKkoVXCPndKI1SarauqX7GFTffVKq4pnIxVh+UpOsqVKNLtWaIa3bauo+ M6W27nPSOp6PXJnUDGu2tHGrs/si6ZWpsaf7OjTQfQsa7b4L3dH9ALqz+zF0V/ezyPWtez3yyC1d tjVX2rL1gEcjbaHV9JOZQx7tc+WZyF1drrVAMm0dxfcO6kl+Pub5yANdgbWYvy9PGu4f48jFrUc9 mRgXW8sk29YTnvmkeVPj055C6FlPCfSCpxx62bMaes1TDb3pWSvZ+LmRx7oya6Xk1FVa10ierXc8 G6b0Pukjz2bJg2dbiye8xrpeCmx96mkgNT4fm5nHIgXq7lg3SVlmweOYUtHjlrJ0tVadFG1Y1+Yh DUyNN7ZFoVvadkD1bTuhprZdUFvbXinKz/LrGpxtB/wG3XqrQdqh22Q1SzsbPG2HoAHSKOmOtlFp Jz/qN+t0Vru0S6drO8qVjxt2tp2QDukMVpdvoGFX22nSs/8w3tt2AXqg7TL0UNs16GjbTd8AP8tv 15mtXmmvzm4NSgcajrbdgZ5ouw893fYIerbtqXRA57Julw41XCC9bGd+l85r7ZdGG67ZBVKRNEka 1XntqRjftGdA79izofftuTxv7fd7Gx7ZC5B5ai/2B3VB66B0tJHZy6CCvVI6qttu3S2daBStu/3b G5Psa6QTun7rPmm0MdVeC82wr8c6yPi9pP2xo7pB60HptG639bB0qDHbvmlKc+06PBnk/YONBXaD f3dsrNtnHZPONhbbzaT2KS2zu6CVdi90jT0IrbVvh66390M32Qf9+xp19t3+g1jnmHSh0WDfJ13A +CT0oPUM7tBsP0h6GHeFDO7zsPWcdLnRbh/7e+V5/+FGl/2Yf6zRaz8pFenGrBela41B+xnpGh/7 j+nG7OcwPma9Qu/oIunfxrn269Dt9lvQfvtd6KD9AXS3/TG+Rzvtz/DecS7e70nrdd9V3RnrLelm 4752+ZQeJD3crpFu6s5Z70p3dBetD/hnoF1LmvxcG8fa0/AZuGJ9LN1vPNaeOaUn2+dDz7Tn+U82 nrNU+c80XmwvBJ9wNjjXeKW9xNfXeL29HHqrffXkDn6R74P+K41326t9440P2tf6xmknut74uH0D 35XaN/tuNz6znPXf0svbG3wTek270TdBPy939dp2C352+Of2gT653eEb0Ke1u6GZ7dLkZ+wx//76 n+nnt4els7p97X1QPIeAXJ/XPsCfSfsQlN6pvrB9D7Skfb90gO84kWfmJI+E3QeVPyo3p3rCUro5 w9MHzfYMxOpzVMOrXFRrzvUMSRvNBZ490kZeZ6LJ5mLPfl5zPMNQVJJomrnMM4LqUek5IgX4J9/v 1Ze3D0s1+tXtIwGNvrr9SECrX9t+3HdDv6H9lE/Sb24f94X1De3nA8mYcwlzjO1XA2l6S/sNf5Le 0X5b2ql3t98LZOql9oe+IX24/Ynvnr6vfSIwXz/gUAby9EOOeN+Ifo8jMVCo3+9ICZTohx3pvnH9 iCMrUK4/4sgJrNYfd+QHqmO8oT/lKAqs1Y87SgMbOFH4a/XnHRWBzfpLjir+XXDUBBpiO7v+qmMd 9IZjI/S2Y0vAqL/n0Acs+ocOU8Chf+KwBdz6CYczIDUpHZ5AuCneEQj0xZi2foMjiu8+sVOMUpoS HTsCU9zo2Okbakpx7MJOjc9GYKh+3LE3MNSU7jgQ2NOU5TgU2N+U4xgNOJryaWaR46jvVFOp40Rg uKnCcRrjKsdZn6OpxnEBus5x2dfXtNFxDbrFcdO3v0nvuAM1Oe77xptsjkdQp+Op73yTp4NBAx0C 7ifaIUJ3dCQFRuqrO1J9e5p2dmQEjjTt6sgGe+AJBI437e3Infxs65oOdBRgnUMdxb6JptGOssCp pqMdlYHxphOcMJtOd6wJnG8621EbuMR/LgJXmy50rAelg9UDN0hvN13u2BQj8MA90oekT0gn+FV6 lTFtutah8w003eww4L3f6TDj3u5bbL3xTY867JPjRNIU/vPVm970lD9JzsO9WaQ5nHt78w2sw9Wb T+Mi0lKD0OH1HTeIHUHwMKi4t8KQ1LE9xsC9VaQ1pOvqb3f0+84bUjsGoRlcObX2biTdYsju2B0j 1V69Ibdjn++qoaDjIBR5ZIo7DseotddEaiN18p/6Xg9pIKaGso4x3z1DpeVob9SwpuOY76Gh1nKi d4dhfcdJ3xPDpo4zUF3HOd+EwdBxEWyJ70vvTtJdBnPHlYC20dCBqmiwd9zq3WtwddztPYAMqqLB 2/EYdx7seNZ7yLDdKe8dNfQ7NdIJw6BT23vUsNuZ3HsC+bTe04Z9zszes4aDzvmo6lS9DYedeb0X DGPOQlTji86S3suxSmg45izvvWY46Vzde9Nwxlnde8dwzrm2977hIjHANecG7AWxXYbqdmyPNlxx bsaOj92295HhOt9tDbecDdjpULV6nzaucRp7nxruOi1BZnjgdEhHDY+d7t6bsX25Mdsp4b08c4Y5 Szj7pGiz3DnA93TnkG+gWePc83y3bdY69/P9yzksnW1Odo4gk+Y8As10Hn++UzTPd54KCs15znGM C53ng2JzifNSMIm/u2Bqc7nz6mSltTevdt7AOtXO29KB5rXOe8GM5g3Oh8FsPJknwdzmzc6JYEFz Q6cyWNxs7IwPlvHnFqykddY0ss5E6WizpTMlWMtreHD9JO1Ag5tIdc+pxmoPGkiJc4J2Uhe/h6CX NNjs6EyX9jZXd2bhTtycRpol6/aAvDncmRMbB7eT9vO9IDjIq25wsLmPnjDoIribdB/xw+Pmgc58 7BcYBw+SDjYPdRZJp5v3dJaCKMAVwcPN+zsrYhQRkHMNjpH2N2Z3VkkXcLQGOty5bnLHf8w1eKx5 pHNjbJcPnmw+0rlFutx8vFMPRR6ZU52m2C4fPEN6jvQi36eCV0j7Sa83j3fasHdjB+/VN5/vdGKn xj4evNV8qdMj3Wm+2hmQ7jSc7ozis3Gsc4d0n575XdIH9BzGmm907pSuNd/u3CXdbL7XuRd7OlFo 88POA1KReY3neDTTXOs5FXxmXu8Zj843b/KcD42bdZ5L0TyzwXPVN2I2e27QnNuYY/fcA/e6PA+j hWav50m0xBz0TETLzdt7lNHV5v6eeKww2JMYrTbv7kmJrjXv60mXKswHe7KiG8yHe3Kim81jPfnY N4/1FEUbzCd7Sn33zGd6KqLGWHdgPtdTJVWZL/bURC3mc57MyEXzlZ51UYf5es9Gvqv2bIm6Jzn8 Vo+e1AS922OLSuYHPc5o2Py4xxPtMz/rCUQHWuU90ehQq6ZnR3RPq7ZnZ3R/rAPdmt+zCz1XrNOh nqI1uWdvdDjW5bWm9RyAZvYcQkfA9/qRrdGe0eiIWeg5Gj3SOr/nRDTcmtdzOtq3NZFmFvacDY+2 lvRciB6P9VmmkR70vK3lPdfQzz7suSmlt67uuYO+Mr/nvlTUWt3z6PnVW9f2PMU9UJfUusHL0DHF 7mezV4A2eMXoqa1Z3iQpv9XoTY2Ot1q8Gb4B/gSi51sd3uwYq0TGWt3eXKwmeQukQGvYWxy91Nrn LYtejfWDrQPeyuiN1iHvmuhtzjnRe617vLXY19BZRx+SPmnd710f65ejE1x7c7j6s7luU/KrbKNr bUs0i148/9ZhL3rh1hGvQcrn/e+2lNYjXvPkOJ00i/PStudPEt3rtnzSIn5X20pbj3vt20ppXEFa 1XrK65JqWse9XnSv6GG31bSe9wZjHeu2mG4kRV/p3Y4ndsnb/1x5j+l/xnWbvvWqdzDWV24ztd7w 7pZMrbe9+6DII3PPezDWY+LqXCtIqdPcRj3jNiepp/Wh9zA6R/SP2wKtT7xj6BPRRW6Ltk54j0kV FqX3JDTeewaMJ3jPSVn8+7JtB+nOukfei9t2WRK9V6QqS4r3uuSxpHtvSQFLlveuFN/8pPOQFDVs 7xxF1ZroPApGdaEqHjIqO0/0XjPGd54OPjYmdp71DxpTOi/4Xcb0TvRuU3ot+MyY1XkzJIfeIb0P zel8FNIY8zufhrTGos4LIHbq6QzbXQwrl7qEULKxwiWG0oxVrqRQpuEgr59ccZUaV2povnGdvSCU Z9wILWx45EIHZ9ziyg6VGPWu3FC50eQqCK022lzFoWqj01UmneYaWsvrZGjDZG9FavS4Kn1PjAHr WGizMepaE2ow7nDVhozGna71IYtxl2tTyGHc69JBd7kMIbfxgMsckkjDxkMue6gP6oKOuryBEWgw MMJraWjAeNS1PTRkPOHqD+0xnnYNhvYbz7p2h4aNF1z7QiO8ioaOGC+7DoaOG6+5Dks2403XWOiU 8Y7rmO+q8b7rJGpgtetMaNz4yHUudD62Q3ENXdJdcZ4KXdVdcV0M3YiRW9NZ15XQbeNT1/XQvRbm uhV6WLfDddc33iK4HoSetIiuxyFNS5LrWWiiJbVLHtjQktGlCStbsru04fiW3K7kcGJLQVdaOOXF 1VqKuzLD6dD54ayWsq68cE5LZVdhOL9lTVdJuKiltqs8XNqyvmt1uKJlU1d1uKpF17U2XNNi6NoQ Xtdi7toc3thi72oIb4Eaw/oWV5clbGrxdjnCtpZgl9tvaNneJYWdLf1d4bCnZbCrLxyY1N1dA+Fo 7NPS8KhrKLyjZV/XnvDOloNd+8O7Wg53DYf3tox1jYQPtBzrOhI+1HKy63h4FOucwjpnusbDR1vO dZ0Pn2i52HUpfLrlStdV/8GW6103wmebJ7puS2dbbnXdg97tehi+0PKg64nvBnQC+titDF9ueeaO D18zyd2J4ZsmjTslfMekdaeH75uS3VnhR6Y0d074qSnTnS+ZTPPdRRFmynOXSpdNhe6K0BNTibsq IpjK3TWBEdNq9zrcG13FVO3eGBFNa91bIkm69W59JFWnc5ukXaYNblskQzfodkaydbvdnkguNCBd MG12RyMF0B2RAt1h985IsanBvUvK0l1x742UmYzuA5FKk8V9KLLG5HCPRmpNbvfRyPqWfe4TeErQ yKZY12+S3KcjOlPYfTZCv7eJEKtE7KY+qzfiiv3Eccbw507+puLvfzqOxX5XEPvNQGjANOC+EPHy /T0S5D14ZPvkZ5J+O8R/t+AfNA25L0f6YyRm2uO+Bt3vvum3T/72hn6vYlRazZFB/tMR2R3r+k3D 7juRfdR1PmZyNlv2QPZHxmR/kuF/sqeyD5hS9le5jAlylVxgcfJpcpFNkyfKZ7AE+Sx5CpsuT5PP ZTPkWfKX2Ux5jnwhmyX/mvxrbLZijeKjLFVVpXqDpansqnaWrvqp6qcsQ4sv9iFtpvbjLFO7VruZ 1WrrtCH2Ge0XtT9hAe249h77nva+9jG7jLv5BFPS369q2XQWx2aw9Wwa28Aa2JtMzz7HNrPPsx0s yPrZL1iY/ZL9hp1lv5X9L3vfAxXVee37nZkzw0jIhBCCaAhFRUIIQUOQWGKJMWiNwWFmIMRYpJaw Zs6cmfOHYf5jDKWWa63LZ6zXcL086+V6rc9aY13UGK8x1lpDrct6CddrXV5LfJYa6zPWGkPV0rf3 PmdgRFLtuvet9dZq116/fTbf2d8+35+99/fN55kxmf0Hl8Ldz/7EPcA9zHHcRC6fs+D7i9x4bjHn 5rI4D9fOFXArufXcfK6D+5/cy9yPuF9wXzH+wPgDLsQH+CAX5lv5Ni7Kr+S/zS3j3+Tf5Fr5t/h/ 4L7Of5f/Z24Fv5PfxX2L38O/y63m3+ff59byP+U/4N6kb/+t53v5D7m3+LN8P/cP/AD/MdfJf8J/ wm3mP+U/4/4J32bjtpgeMj3Efc/0oWmI22Y2mXO5PvNj5se4a+bHzUXcp+ZnzGXcTfymAvcn8wvm CgNvnmdeaDCbq8x1Bqv5a+ZGQ5bZZfYbcsxB83LDk+ZvmdcYnjGvNXcavmT+rnmrYQF+D8DgNO80 /9xQbT5uPm5oMp8wnzL4zWfMZwwt5n5zv2GZ+Tfmi4bX8X0pw9fNvzdfM7Sbr5uHDCuTWNL9hjeT 0pIeNnw3aXzSFMM/J+UlzTDsSno+yWc4mNSctM5wKenvk/7eiO/6dBrvT/p+0k7jQ/j/wRnHJ72T tNeYlbQv6cfGbHxfx5iX9O9Jp4wlSaeTBowzkz5O+sw415Jn2W2ssfx+3CTjR9ab1ps8fuPLx1YC T2HZ+I3g568AbjE2pxiQx/LkrhdFeZu8U+5+cYe8Tz4oH5GPyb3yKcXiCChWJV2Z6Nij5Ch5SqFS rMxUyitvLMz+cpdtv3x2IZPPyxflK/J1+ZZiWJj90mrwKh58/Ar5+KeM4/7E/YkZwKNTmRHuPUpv hDLD9w3fZ5zhB4YfwL1dhh8yo+E9w3vMRG+Emg2/MPyCWei7TOMMHxr6WDK9C5pCb4Heb/jI8BGz 0vufDxg+MXwS/9+/jJyRG/7fDk1GM8ug7z5lGjOMGWyCMdOYySbSG5uPGPON+exR+l5TtnGWcRbL oW8xTTLONj7PJtN3PHLpnY2p0P4ULo1GDjmTsxjsH+TJcr5cJJfIZfJseZ5cKTvlRcDr5UZZlFVA SF4mt8kr4d4aeb28Ud4sb5V3yLvlvfIB+bB8VD4hn5TPyOeAX5Avy9fg3jX5hsIU2JUpsN9SYLer wK7pNjqowF5IgX3PMNmUGmWxsjSBXIpP8SsRZTnojtAR5RjwFcoqZa2yQekcpi5lm7JT6SbaB/Z6 oaxUOQXSWeU8SBeVK2CzVLmu3FINyiroPzfOp2cN/F75gzQmmUBGlgXEszz2GDOxQqAkNg3IwsqA xrFZQMmsHOg+VsHm0vcHX4Kso31z8FW2mL45WA/2GoEeYgJQOmtmAfYwi7IYG8/eAJrAvgE0EfLR m+wR9hbQo+wfgbLZv7Ct7Avs+0CT2E6gyexdoCnsX4Fy2XtAU9lP2GFo31GgfPr/Ox9np9gvWQH7 T6BC9r+BnmS/ASpiV9nvoe2D7A/sKTYE9DRn4JJYCZcMua+M3uN+FnJfKptF73GXc9ncJPYcN4Wb wl6gbyxWQDa0s7n0/9zN45ZwS9mXuQaugb1E73RX0vcTF3I+zsdsnMIprIoLciFm517n2pgTcmc7 WwTZ81vsVe7b3Gr2FW4tt5Ytoe8n1kMm3cu+yu3j9rHXuIPcj1kjd4T7gLm4n3E/YwL3c+4Y85D/ eiEL5DOfpcBSwBR6e061PGUpZk30xlyzpcxSxgKWcks5C9L3ZUL0flzYstTyNRa1vGZ5jbXA3A6w 6+T7pfh7N1IaIBOQDcgFFOiYrqMUMIu9ImVK2VKuVCBNl0qlWdIcab5kk2qkxdJSySX5gPyAiLRc WiGtktZKG6ROqUvaJu2UuqV90kHpiHRM6pVOSWel89JF6Yp0XbolG4AsslVOlyfKOXKeXCgXyzPl cumIXCEvkO1yrdwv18kNsiDLckCOya1yu7xaXid3AG2St8jb5V1Ae+T98iG5Rz4u98mngQbkS/JV /H/RTA0mDyyCS6z14LEG8M//Lv9eCPQAeXkqefmD5OUPkZenk5c/TF6eQV6eSV4+kbz8EfLyLPLy bPLyL5CX55CXTyYvn0JenktePpW8PI+8/DHy8sfZMaAC8vUnyNcLydeLyNenka9PJ19/inz9afL1 GeDrBlZK/v0M+fcXuUe5bPB79OxZ5NlfIs8up+8pPEfePJu8+Xny5jnkzS+AN78OMfAG9wbEAH5b 4cvkzfPJmxdw3+G+A/GAPl1J31NYSN5sI2+2c8fAj53cce44q7a8bHmZ1VgWWxazly0eiwe/cZza mroK5ikFxv4+xgV2M+ZbBVgL2ADohLK9cO0CbAPsBHRD2QH+Qd/qwAY598+DdApCRb51gU5fR6BL nn47sMy3KbBNLgXMCpUgfFsCO+U5fx6o49se6PbtCuyT548A//btCRyUbYCaUJlvf+CIvPjPg3SW hmb7DgWOya7AMV9PoJdwPHBK9gH8oXkkR0KV8vKQ09cXOOs7HTgvrxgB/b0qtMjXH7gor70LNoTq ycZA4ArhUuC672rgltypAWXfYNAgd40A//YNBS3ytqAFrwiJD1rlnXcH6knJwXQpNThR7r4dUkYw R8oK5sn7boc0OVgoHxyBlB8svhc0r48dk4qCM6WSYPmYKAtWIJo3xnoR0uzggnvCvKBdqgzWfh6a N8dOSc5g3b3AvyV6RloUbCDUBwVCY1BGNG+NncWrvy+W0rwjdl4SgwFJDcZGw78rekEKBVvvhubd sYvNe2NXpGXBdkJbcLW0MrjuNqwJdtyB9cFNt2FjcMs9Y3Nwu7Q1uOsO7AjukXYH99+B0WO9N3jo XiAfCTVKB4I90uHg8TEB9+RjIVHuDamkdzTYd084ETw9pu+gvVOAs6GQdDLYfy+Qz4eWSWeCA8M4 F7w0DLx/EXAl1Eby9dBK+VZojXQheJXaOwqKIbSe5MvBwbtBsYQ2KtbQ5ttsXAsO3YYbIX40lPTQ VmViaIfMQslKTmg3XfNCe8dqz+dBNodS5ZRQxh1IC2XJmaHJdyA7lJ8IpTB0IJ7bb8vFeq6M5zil OHQ4noOUmaGjiXlk2E8S5zU+L/ExKg+dGB7bitDJxDZRLjkAOQX8sfmw5pfNR/UYxrg6ATgZu47+ 3nwGcC52K+7PzRfgCs9RFoTOKPbQOaU2dEGpC11WGkLXcH1RhNANLKe+wRqhyGGGa4kSCJuVWDhF aQ2nKe3hTGV1OFtZF87F3I59VjrCBcqm8HTMz8qWcKmyPTxL2RWeQ3kZcjqOhbInPB9zp7I/bEO7 yqFwjdITXqwcDy9V+sIu5XTYp/SH/cpAOEJrJK5BuCbgGF4KFSlXw8txHVMGYf2Jj/NQ2Kby4RVo A++pyeFVamp4La098bU2YY6GbSL0NSW+FmC7cG1UM8Ib1Kxwpzo53DU8z6gPc4dzr+aHt6lF4Z1q SbhbLQvvo7LZsIav04DrNa7bt2GLti6r8wLdtB7Dc+JrMV4J4D/Ut1FrLF4RamXgLALXx/i6Gofq DFxBDK+RuGbqa2PiWpm4RsbXyTjURbAOwlpIax+sh2p9MAdBfovr3GQNamP4IPqlKoaPqGr4GMmh cK+6LHyKfBbyh9oWPquuDJ+ne2vCF+m6PnxF3Ri+jnGrbg7fwniifm2NGNQdEYu6O2KluIjHgZ4X MZeqeyPpmOfUA5Cb9BhRD0cmYt7C+vEceEdsjYqr4fyixxbawLypHg1dU09EcrCNw/VBH+NNPRnJ U89ECtVzkWL1QmSmejlSju3GnIR9UK9FKtQbEW1tuFsO0tvVxPQ8Hs9LpxJ09DZTX0fl4+H+YB6O 4/Oe9Tn5tMmsX1NCyTgXcdyRJxNzJebHeI5MyIeoS3ZQB3MTjEFTWmhH8+UWA85x87UWC/az+UaL NcBa0gPmlolYTjlLjW0LpLTk0P4F/A51A2ktebTfgH1HILOlkPYUkNMC2S3FtE/T9wSB3JaZgYKW clz/A9NbKjDXBUpbKBcGZrXYERijgTkttYH5LXUBW0sD5uFATYsQWNwi054M8mVgaUuA6rpaYsN7 Jtzz6HsUsqXbwHsBX0trszO2itoV39vF9wbOkRxMiO9h9L0H2iIb/pZ2/8Sok+rE66M+5mj8G/0C xwD7FmlZTWW4b4xD3yfehnvZC2Lb4nu6hH3dMHA/F8fofV18jzbG3iywXMNd92a490rcf+GeK77v StxjYVuxLurEx0SPrabMiJ2u2ZHaptxIHfkq7nnicVUQaWiaHhEIpRG5aVYk0DQnEmuaH2ltskXa CTWR1U2LI+sS/b1paaSD4Ipswvhq8kW2NPkj25sikV1NyyN7xow3+HzQtCKyv2lV5FDT2khP04bI 8Xi8NXVG+oblrshpwrZIP4Jib2dkoKk7comu+yJX4zHYdDAy2HQkMtR0LMoPxx/EVVNvNJnacyqa ijmr6Ww0A9eeOHBP2XQ+mtV0MTqZ+nwlmt90PVqEuQvzR9OtaAmuKXF9vyFa5rdEZ/ut0Xn+9Ggl +qM/J7rInxet9xdGG/3FURH3Bf6ZURXt4Pj5y6Mhf0V0Ge1tYf79C6Jtfnt0JaE2ugbHHMfOXxdd 72+IbvQL0c1+OboVc7c/EN1B+rHobn9rdK+/PXoA94D+1dHD8dzsXxc9Gl+X/B3RE/5N0ZP4ecS/ PXoOP1P490Qv+/dHr/kPRW/4e2IMx9F/PGbGzyO4dvtPx9LQhr8/lonz7B+IZWNc+S/Fcv1XYwX+ wdh0/1CstJmPzWpOjs3B9R3vNafG5mPMkR60uzkjZmvOitU0T44txrY358eWNhfFXDjnzSUxX3NZ zI/9ap4dizTPiy1vroytoJyg51zMk82LYmtxrWyuj21obox1NouxLsx3zaHYzuZlsW70XRwvlJvb YvvIn8EXmlfGDjaviR3BcWQGxlnbrWsZ+9u/oPwV/QvKJXZ15N8BPJXM51E9Ic8yT5tnpWeNZ71n o2ezZ6tnB/Ddnr2eSp1ChAOewx6nTkc9JzwnPWc85zwXavd7LnuueW6ITDTXDogpYtorGWJmbb+Y 7WnUCDQAYq5Y4BE1qu15JVWcLpbW7hFniXPE+aJNrBEXi0tFl+gT/WJEXC6u8CyKE2isEteKG8RO T71GYpe4TdwJet3UPmwRauI9fCI8Ac/5798Ovv3if8s56EKIjSqgB+kcNI3OQR+ic9CH6Rw0gwlM ZOOZD2ginYY+Qqehj9Jp6BfoNDSHTkMn0WnoFDoNzaXT0Kl0GvoYnYbm02no43QaWkCnoU/QaWgh xNwxVsSOAz1Fp6HFdBr6NJ2GzqDT0FL2G/Yxe4b9FqiMzkSfpTPRL9GZ6HN0JjqbzkSfpzPRF7hs LptV0JnoXDoTnUdnol+mM9H5dCb6Ip2JLqAz0ZfoTLSSe517g9m4r3NfZw46E3XSmWg1nYm+TKeh tRDp77BXuHe5d9liOhP9Cp2JLqEz0a/yq/hvs6X0W3kN/F7+XdYIcX2EufgL/MdMgPi9znD+Imz5 iK8K6axYSBcmCjlCnlAIVCzMFMqFCmGBYBdqhTqidUKHsEnYImwH2iXsEfYLh4Qe4bjQJ5wmahAE QRYCVL9QiBFvFdqBNwCtRkK/MTwBfvOk7jdp9Hz0GAPM0WPgPegrPIx/MXgP+oqZfCUJPGUu+BCe mY8D71gMPoT+cR/5Rwqdk98P/fKCJ6E3pIIvvAn+hH6QBl6wFfwJPSCd/RDoYfKADPKA8TD/h8Fv 8Tx8Asz5L8HDcNYfoVnPojPwR2HmL7JsmuMcLhXmeBLN7mSa1yk0o7ncV7mlbCrN6GMwoyrL50Iw owV0yv0EtxpmsZBm8Un9dyTxTHsa9w63l01nnKXUMmtkPty1/IPu2tEktAkr3XXuBvdqjYQ17jph PZJbGE3CRrfsDmgkbHbH3DFhK5SMImGHe5O7FagdSLO5m67r3B1xEvaCzh0kHHBvAQvb3bt02qOR cJj4UeD77yThhPuQu2eY2l1H4jRsuX00KQe9a9zH3X1xUo64T+vUP5qUY9CqAY2UXvcl9yUhGUpG kXJKOeu+qpx3DwINISkX5RPuIYEXkuOkXBFSRxOMzkr3Fs8sd5+QoZGrVyPlupAlZCkXhayRdia0 +JZrrTA5Tu5BIT9OYFGzXSScHEVnhHPwnJJhuiCUIbnW3tlr4bJ7ojB7mFAvQ5g3iq4BbgiVRE7B 6WFaucfsSYHrIs06kifNkynU30mebKHRkyuI5C+tngLsMZJnuqfUM8t1yzPHM99jG7GTYLHG1Zvg T6oQ8izWSFimkWcp+rfHRb4re3weP/qCJ4I+41mO/uFZIZz0rKLezvOs9WygFm0g651CSAihp6gG Go8tqkW14qiq6Tj66kQcaU+XZ5tnp6fbs89z0F3nOQL1joHtXs8pd8Bz1nPec9Hd7rkC7dvkue65 JRpEi2gV08WJYo6YJxa6N7kOisXiTLFcrBAXiHaxVqyDFsvQyv1iA0VZuyiIshgQY2KFOyC2iu1g C6OWekSamyhOoEfiandMXCd2iJvcteIWsH0E9BoglvaI20GqE3eJe4DvFw+JPeJxsU88TbEc00js Fwewt+Il8ao4KA55eYhWpA5vsjfVm0E+Dk/yZrn3eCdjNHrzAUXeEm+Zd7Z3nrfSfcjrdPd4F6EV jDxvvbdR81ShxCt6VW/Iu0xwetvcAe9K7xqhUcjyrvduhFFe5t3s3erd4d0N/joPZqDMu9d7wHsY fM7pPQp0Qqj0niQPLBKKtLkivXr0GJwr7xnAOe8F72WhyHsN7oS8N2BRN/tSfGlCiS9T3OTL9uX6 Ctx9vum+Uqzhm+Wb45sPZCMfL/OsotIa32LfUsHpc/l8Pj9QxLccfBipzLfCt8q3Flrd6G71bfB1 Clm+LvRT3zbfTl+3b5/voO+I75gPotZ3yt3hOwv+qGLffOd9F31XPHPAQ0NCke+65yCMzR7PHIi4 02oO5K56+YSapxa6B9Ri8Och96A6EzJFqlruOa9WQCz3uY6oC+QT8gmMa3eFahfy1Vq1Tm0QF3iy lRQY7S3olZDNMD8N4mNBCzTgrx5VhkyF+Y48WNPEDEPzUuG+pAZca9UY+HgrlOeDXh/kqywVaxxX V6vroI0d6iZ1i7pd3aXuoSx4Sd2PGVA9pPbA046r69Q+otOQ53gt14l7VHoaerDa4epVBzCbqQNg GTUvqVfVQXXIfUhdrWUuyl2pqgGoA8Z0MrbEe8F3S8KfeLNIVikdMtQ2aaI00bUNfGWzlCPlYU5y N0iFYkAqFsqkmVK5t02qEOZJCyS7VCvVCYukBkmAO7IU8F6QYlKr1I4RK62W1kkd7lbvRmmTtEXa Lu2S9kgd0n7pkNQjHZf6pNMeJvUDBqRL0lVpUBqSebFQTpZT3dul094L7v1yBmjXufu9K+kOvZPj DuBbOd7dnm34Zo570/C7OfVyo7tfFuntHP3dHPcQvpsj9XnO6+/nrHEfGvMdnQvyZalPvgaxNuhJ wbd0PCmKGfzUCf5qg5nfJYSUNMiN+a4jI2/ueGC1UEqFVCXTm6q/taO/rSM0KjVykf6mTja9qzPy Zk78jZx9Pj/tpp782yfMv6JPmAJT6a2GDODMdZ5x7mKW7uoHGnANLKlbUue6BNTh6iD5quvqkv4l /a5BoCHXEJa5eaBkdzKW1S2vW+5OBcpwZ9SX1Je4s4AmuyfDcwxWm7UKnpFKn2gYfaIx0GcZI+15 efosY6JPMWba8ybRpxgLfYoZR59c7qNPLim057XSnvcB2vOm0meWB+nTykOMS21MlalP9N6hq5Fx rpVwhc8orjX8gwuGXG33gspOV9tLPCD5c5CqoXKnhpcy7hFZgMljIF9D5RG4Ft0bKnvhWqKjTMds Da567Vp5EXAF5HmAyjtReQuuzrtjoUW3sUgH2m8cBXEMqKMQ+guwDNA2BlYC1oyB9aOw8d7gNMN1 M2Dr52CHBmeKhpd23yP2Ag58PpxpcD18b3Cg7xzVcULHSQ3OTO3qgPlxZoN8BnDuTjjQzy7cHc5c QAHIl3VcA9y4HZVsDJhHIeUvAIxFZeYYgP5U5t6J0WNdWXBvWDgTrtMBpZ8DuLewHFCh6826R8wZ 23fIBtq0w3X+vWFhLVxthJV0rUlAXKdBvwoAGeTFI89KxMKALi+9OxbGAK2jbLhGwXcnFrYDVoPs h7zTqF0Xdozdns9FBLB8DKwArBoDa2/Hwk0jufu2fBvPl/E8tmUkvyzcfnv+GPaTxHmNz0t8jHYl jO2e29s0nFMSfTMew/HYQlu6zztrRvk1zud+wCFAD+C4q60K2wDry8LTWjn2CdeIhf0uWktckGMX XgJcBQwCoP82XLcqtf7aYK2y4VoF82KDujaoY8M8oOo5HcbBlq/lS1uRZtcG64kL7ttg/bBBTrGB LRvaWqSPb3w8oS6ukzbM/WizbGSc0ZYtpNnAezbI5bY2rV13zNOoORpeT/R5Qlu4Ntog79tgnmzr E+o7tbnDv20w9jbI4zaIO9sOXYdPQOoYGL0u54+BItfI+pqwxg5jXgJGr7Hx9fK/sk4uc92+Fq50 jayBCeud7aTmlzbI/7Zzugw+Z7us+yz4mw1yue2G9ncV06+Qq6tStLitStPiCftVBfm3CvJvVa4e F/E40PMi5tKqAj3P1YzESFWplr+w/nAOHB1bo+JqOL/osVWl52L0/6o5WhuH6y/V4q0K6lfhc+DZ VZD/qpZq7aa8BH2oAntVPr3e3fLPqDw+pk68zWPk42EsTsDnPesu+RTn4TaMzpOJuXJFQo5MzInT 9brL9XsFWo52LtXm2OnS+umE5zlBzxnRyjFnOcB3nFCP9i/LNF0nPIP2G7DvcGKuO6fns7W6b+p7 AucGAOQEXP+dXXqe26bZde7UgDHq7AbsAxzU8rATcprzmJ4/IV86e/W6p1wje6YTCXl054gN2kud hXYf1ts1Og+PysHDe5h4Ht6p2zjvarOv1uvE61/QcjP9vVUbA+rbRb1scwJ2jIF72Qsedo3s6U64 hvd1wziTgNH7uvge7b+yN0tz3b7/ynYN77tuW8sO6HUzR8YkHltVq/Qrxt0G18ieR4+rKvCJqi4d 4A9VMOZVMH9VMH9VB3WAD1Qdu93fq3p1nNLiqwrmuQrmqQrGv+rK2PGGubHqOgA+29gNAMtIvNmt CXK6jokaMPbsOYA8/Vo4EoP2YgDkO3t5QvxBn+0VWnvsC7ScZbdra08cuKe0w37OXqf12Q77Nrug 5S7MH3ZZW1Pi+nbYr9lhH2aHfZi9XfNH+zoA7KfssMexb9H2Bfbtuh0YPzvsSex7tHyM82+HPYT9 kI4ebcxx7OxYrw8Aewl7v5a77QO6Puwh7LCHsA9qe0D7kGs4Nzv4kXXJAfsJR6r2ecSRpX2mcMAa 6YA10gH7BkeZNo6O2drnEVy7HZWaDYdTm2fHIi2uHPAZ0gHroQPWPwfahrXOsUxb3+lemxZzKGO7 HTCvDljzHOu1tjvA/xybtTl3oN4OrV8OzGEQb44DWk4YzrmQwxxHtbXSAXHmwM9MZ7R858D2XNZ8 F8cLZcc1zZ/RFxwwrk6mjSO+jXH/oft/+re3Mf6azsr4Av4w/ouq4Sh7m7GkHEAeoBBQDJgJKE+4 VujXBQA7oBZQB2gACAAZEADEAK2AdsBqwDpAB2ATYIuO7YBdgD2A/YBDgB7AcUCf/qzTgH7AQML1 UsLfVwGDgCHGLDwgOeGaCsgAZGn6eLVMBuQDigAlgLKE62zAPEAlwAlYpOvXAxoBIkAFhADLAG2A lYA1gPWAjYDNgK2AHYDdgL2AA4DDgKOAE4CTWr8sZwDn9OuFhGtc/7I2pnQ9rdcTEu5fA9yg/+Kb jTMDIF7HpY1ccXzGZQKyE665gIKE63RA6cgV2zxuFmCOXn/+Xwaas0Qs0IDPv81e5ijYADX61Xan nXGLAUu18R7nAvgSrn5AhL3tWOVY69jg6HR0ObYhzBHHTke3Y5/joOOI45ij13HKcdbsc5x3XHRc cVx33HIanBYgqzPdOdGZ48xzFjqLnTOd5c4K5wKnnVDrrKO/G5yCU3YGCDFnq7PdudpxzLnO7HN2 ODc5txC2O3c59zj3Ow85e5zHnX3O01Cv3zngvOS86hx0DlXz1cnVqdUZ1VnVk6vznYHqouqS6rLq 2dXzqiurndWLquurG6vFahUQwjrVy6rbqldWr6leX72xenP11uod1bsJe6sPVB8mHK0+QThZfYZw rvpC9WVzpPqaTjeGJZRv1DCdzEApzsGaNCg/o1FNZk02ILMmF6gAaHpNac2s6ms1cxA182tssCZM GPMXF5j+iwsW+sWFZPrFhRT6xQUr/eJCqgF/cSGNfnEhnX5xIYN+cWE8/dbCBGuO9Sn2iPVpawV7 0vqaVWDPWX3WJjbXGrBG2UvW5dY3mMO6wvpNVm190/qv7GXre9YDrNXaY/0ta6NfX9j6/3HLOC6N U+l9lX3sCcamnNQBkT7lnI4LOi4nyAiI7ik3dPkc/sftmpxr1pGiAyI9FyIoF6I7F5RyCzTd3Om6 PpaVJvw9S7/O0TF/5Jm5Nu3v3Br2hMMMlOJIc2Q6soFyHQVE0x2ljlmOOY75DpujhmixY6nD5fA5 /I4IlC53rABpFdQo0KNRi0eMxC7HPpirB+iXNhj9xoaBfmPDaC22FjPeOtc6j5msL1oXsiT6vY0U 61etDTAPHquXPWr1W5tZjjVmfZ1NtrZZv8HyrPut+1m+9X3r++xx6yXrJVbw/9g6N/QV/lngi00i 8PtITia5hOQSkp8m+SnehtzUSnIAeLHpLZKfJVkk+QmSX6JahcCLdGvVZG053iX9Oj4fucmJbz2Z YiCn87nITUHgu0nnu1j3jyT/8T2y00blXq1VetvKyXIzyfOpnGTT15Cb36LyL1HJa2DnI2zhH/tN i6i15dQjre4TpPMVau0MsvkayV8k2UMtf4F6J1BdlJ8y/olKniT5I7JwH92dT+USWX6ByptIfoDk 50iniJ5eR095gJ7yHMkvkKzpl5K+C/h0kqeTXMyXES8lC1RC/Gkqf4ZG6RmTl55SRjooP23soFpH SDNAlrtI3kzycZJXk7wf2zA0m/TLqXwG8RXApxF/mubraX4u8S9SrUZ6rof4u4wz+ExrgJebVgL/ pgmebgiRPJ64kfgp00bg7ajJPUh8I9UqJs6QG98gzS7Tt4F3m/4R+CQs4c6jzN2ku52kv4T0N5Nc QjydbH5MOlP4nwPP4n8K3Mn34VNQ5v6N+AdU7uL/A7gNNTkL8XqqZSD5PeTGXNJ8jcol1OeGyMI7 JL9Hd2vp7kTSn0t1B4j/gVegvNKEmoO8DLLZ9CGOBpZzDaajwH/Ng+cYpqIOu2l6D0qsxH+rlwA3 Pk92phLPo7o+4h3EJ5keo7tfw1FCbrhJ8knivyb+Fl+Hc5T0KHEDcvMt4n1UMpX4EnjWcm0GSfOb 5j/iPJI8XuNUazzVGk+1xpPOLrq7i0pOUUk7lfwTegL3IMrADcjRAvA+KplK8h/JH8A/DY2kv4zq FlMJI5mZzhHHknziXVTeRX3pJrlbk6mF3dTCbmpPtxmyh/EX1K9J5IGTSH8Gteo88ZsaN61D76K7 nWStk6x1krVOstaJowQeCG0w0nON2hPTqVY69e5jsvYx9esPsNwBN50n3kP8beK36C7EmnECzeMg aZ4mfpn4oKmXfOM6+gyWQBz1EH+b+C3ivTjLpP9rsvlrrQRrcfdTq6ajzG6iDnhUD/G3id9CzkM2 MHCa76HMWcnab00/QY4l7GbSYtL/CNtDLZmKPTLcojbkUUkeleRRC/OohXnaXWp/Hn8ZevpVzZNN 19CH6SkdVHcmtVwkPskcIp0e4m8Tv0XPnYG+jfpGk8ZpPH9N/C2y9haN2FGMLMhIXeTVB8hXNU4e SHK3xslyJ8nppJ9O856OJTA7Eo08cewdjKFE/aWYRQ5PP0/jjyU7yH++SPxFyoETTN8D/rG5Evga Kv89co44RMf3aJb/F0YrlZwizSUUBenES8hOMXLjGpK7TBuo5VDLOIPs/w+qO5v0PyK5iPi7mj9T 5nyHsuivKAqSsNx8A33DvA3HzfQo1uW9OHrmX6FstqFs3EueP4/8+d+RJ/HYX/N6vh9bS961gsat GdsD8WijMZ9GfAKN+TTiE2jkpxGfQOM/jfgEisdpxCfQXEwjjvqfUvvfJMtZ1Hcf5ZZu4ula7jI/ QZmqBHg2toS7iTL3Y5rZ8qTHMYORvpHkU1SrXctR1PJ2it9iLc/gXeMbFNdvkE4X8UnEn6OIPq/x pB8hh8/q+ES8u4Q8Zwllhs1YAmsT2p9Pd0u0LEF1P056hTwEosAwjXgZ/0vKTqjzJSqZyv+KYvAz 4LMpXq6aYeU1/ATLISI+o8wPEcG9RvIPMcObBiguGOqbaigPfEIlEyjnfECxNi4J8iH3PsULT7N/ A2cTMtIn5OefUKR/QpH7CcapzikGSe7jKTbRjkEy/Q74A8jBQi/V0vIPZpjL1Jfl2GajzfQ+8Cot 19H6KFG/GpJgB2V4Q+s15hyw/CL2He1D5pmKKyD14nk9H/ZSe5B3aNz8HeLXKHtspt0C5qKbdPek zjFLVJu/QTlkBsUs8heSJtNK/SvKUb+ikYSVmjvMn6Vn/Y7y52c4MnT3R6T5CMkFlDmnmf4O5Iv8 AuBXeC/NHWbRGfTcGSQnEf8O9fc4cYPpU+iRxaTS+o52SmiXkktjVUFP+ZD4MdL/OVn4uZY56el2 4p/iXHD5lDmXUD7/KcnriL9mgh2mYRHZr6VZyyE756mEMj93mngL6e/AXnM3+GbqYwvwAv4k5hPS +Rfq0W+xndwmsrAZ+26agaNkykNufAt9EvISWDN+gjIfJjmMLTc6aJYnUKb6TM9U6FcPoTXjF7CF sBpir9OoX//JnwH5Kf5nIO+iklJqye+Iv05tOE39KiO5hurO5XcDr+BxpV6PMqw7OFZnSDPP+DDI /4es3SS+ncpfIAvP8O3Af0f8JRPEuIGntj1KT3yH9HfyH6C/kc0bxNup/FOyUEbWekn+GpUfMZ2l NqPnfxN3a7ArCwPfgJkcyivA/ivmp0G/iceYEpHD/hBrzaXx2Wr6GcVdC3kg8p/i7t0wxfwK8WeJ FxBPJv4q8TeBa3tdJ2mWEHeaCzHjocz9m84LiCcTf5U46rhIfw1ZW0MlNipZasIca6G6Fnw68ALi ycRfJY76z5BmPWm+p3Hay71Gdl6jlkskS7pcQDyZ+KvEaynP1MMoPUd77yGyOUTW3tFs8tvRw8lO LdmpJTu1ZKeW7NTSaNSiNeNc1DRWEX+VWj5AdgZI/oDkD6j9U8wf0mhoXOvph9Qq4qYUsvkh1X2W OJa3mOATn8FK/GH4TI/58AXKcpAlDFX/l7VzAdOxWhv/etZ6nuedxlgOjfOZISbHMY5JksOIkDRb KhvDRI2ciYRsOVWihKT4bJXdnpSSymkjIR10mJBKKtkiOjgk8c637t/z7uvKfN/13+3//3/ta//m fu51r/tZ615r3etZz/t6Q/+E0NuJPDTowOoW5qPZi2UZelrZf8lxsshaC00Wcg4cJrVMKaHbfaRu aWptwv/3aEbIStTZQUvmsMRwnkQsbCc9DbcL/aeklv+LPCEHx0UOp/PU0YIYTiS2Gvt21N3P+m3O 2aennGddrHKIUg5RyiFKOYxUDlES+S3aMwB7g1yLOA8Tuugxe4MeMkvl5O56IXvBE/4Wp6mcmLfR zExmNkZzMp3ZlSznNcY0DX0OPuPwtQRlp3stNg57sakoo+bmQ316FzGaD/WxSad0Ppr5tHasy7HT jVuP8e7mlDCoobyLe+S9x8U9wf3O/kk5oZvdQX8Xz1aS4f3BIps18DH0q4JRjsvE0sPe7f6OfjXq dhWGd2G5Vd5O+Dvl3YU5hIeb5X2IX5LSV6j1jDBWCX1ZPFyA+dj352Q6WcbdvCrZ2xxE7gybCv3q cp71a7Ivz8L+H4zsp8JgJTZNRfYriqWZTVY5gXwnpfUoLS8MO+AhOkHnwyzudY3kQLNM3niYTrLP mm94KpjFuWC7PLebHXIids9OzsabK/H0VhDVSWgekCeE4CR+NsMC+An8FD+H4ftwvF+IfoA8zQqD rciT4Rucl89yOn5Fnvr8a3j225CQtVCe3BwL0NSm1O0sYQviPwzLFNgqnOC4BQ8PwRMRxYNjARrx sAbLJ6l1QTT+BTQ8eQaPsz8+zhPpdngvPMAT5oc8SW7nOXYZJ+i4PFW6uSRPyEe4Y2/4qmTaoAI+ K0jdYCLyxEgWP44FaJyf4C9yUo5p+mWCso434OcY7ewq691/AQ82QfFj8WOJzwv05QWJT9BK5NjY 8Al4j8wN/EyISFQvw3++9N2M4xlvX0R5fnPcBV+EF7BxeSy8jrGehmWnwJ04gkVhNeftajlpmnWi 98tFFA+OL8ILsLv0jlJO0GaHaMwK6h6VVel9znPyfXAh3Mbz5FTOpDM5k97P89Jcng04p3sn5QlQ L8dzeeQP5NRs2gZxWTvom4of/2tpv8+ztz84IvrBtHYwrR1Ma+dKq/zRcnYO36OW4omxMn3n3G1u gq/znPAKPVrICXo+T2Lv4r9BRO7SgLs04C4NsH9XourPlHuFmcEkuIs3G1KrTEQ0PYjGWSJ2LviS tdCaWR1R5mdDOTu7+eY04YiAuYE8lB5NYE1NwH5f8B0jElEiXFXO0b4vmmCgv5EWijwVuQztL4Om NLNxMewTpDpvh+UsHFwbznWaj0UfLKW0o9BsQD4lNn4pzs7bsSkQ+yCZtVMN3sJZ+AVOwT8Kgwry nBZMlFphW+7SDp9vsz9+gec1eJsGrZy4/XWUPsNqSoWXS+llvClK6svJq1CydJAj+S22lRzeSWT9 GWfzFqypC6yXZdEqRhPi4TfxmdTXf9rVKsUu8Ku00EVeRueinKNdvqrAuDSCcr5+mvP130V2lo1g BVZ6I1iB8WoEpe4zoeSBQ7SBNxV+77Cy7HHkq51wAjkkTU7i/ldy+vZfFrp9UGbX7vAZ5rms8e3I F+jFMuoeIje+KprwI8kV4V3ot8JB5IdD1L0Znog1gTNkBxRNEJMZFauEfVn4DD7JqGaVnLX9znLu 8AfAVHbkPwXLmF2nkZ192Af9AM5fGzjx5bDWvgkrsPc5fcBJ1q1BOR+9xTPVD2Lp308emC5P+7El rMdzMo5hN0bzcdGE1wUSn8pyqnUzXHIa7/r0MmFsiexB5iNZfWacnLIdpRfrkNexumeJ7OpGlNIG lFZjZUXyBGmD31Tu4vZWdyLz23Au28f7nAKhW0EvspOeZg+VE9N46UvwvuywYW+y6088CazgFDOE U9uvck73efdolssJXc+UDB/eKW0OTpITNpNdBxCBT0TWh+H7lN4UloAj5I4yi9xYHJYdmdLJ8CR5 5g1q8RbUlJMzu8tIa2j5GslyoZvzfnHGogEcyKhN8iXfvgUL6fu3jE5VbDjdm/lwNrwRfTYnuALp qd8FTS3kZv4e/Mu5j7h5nxGNFKJRhZP4dDnF+/f637sWDqZWV3m+Co4yW7b7t5KLpL8bqLuBul2Z LZWJ/HE4i/asZ+wqcX58mBF/g11mFWPdFs2Lco7wOY36m7HvhLdXhMHHyGvJ7SHyZM7UkYfWcJqc 8f0vWMuXy1Or31PaGQTBUskYtHMJs2U9z4pTzA6nPyyRDD+RWep2IuEMof+NL+PyDHn+XpGD7wLZ 619lt/oSmyFkwvPkyYGUlhaaJ2SXDOZIC8MbiMAXtHa/nPr9YnLqN6M5QZ+gVd3pdTX61VFaFbxD BP6E/mXphdnmu1OD/5R84uYvNZ/SBieH+/C/F/vBjPJgeQ/g5rnc8UP0tZCfTNiIz4fkPUCohP5y eRvg9xJ9OJ42zMe+srwN0D/ivx/shf4rPPQUOXgMuXZ0F97ONWBVsj+GnxGr9ZAnYfM8nASj9ViG 59hNxNP4nzk5XXYls53oLeL9Z2nu0g22I2K7yQwXyWbniM9s2Jk51pCz0nrYPCFfBdNhMryFUnf2 CR7mGf57LB+ErwarnP/WyA3g3ATTYTIUD52xrMpJc4po/CloyqI5yQl3DmfM5fAW+AFnedqjn+PE 9yjvFk7L6cytNVdLP4vlae57nzzx+ivwuULq+g8gH0nwKpgOk6G05Cd5J+BOvv1cJBvQx9fkE23z T3ymw/5wq5x8/bp4m53gVTAdJlN6C3QR8/eI53CLfOrn+Kzz8Ca10hKUKL2M5yyJhotzDyImfIS+ V5X3Ca4XThN8IW8b3F1E/hw5jbunicZfTdvaCM0p352vzUj/H7IugofIbFJ6jtIz8E4098nJ2qyG d4km6ID9PcS2GjwtdJnhJdmdkVfAI1IruCj09+IzR/RmJp6rw+/JD7P9tY59KW1GhJfD+WKTVEci kEQcgkc4b55i99wrcmw4e+hqSh8mwlOI3tXwAebYQjzUEZ9JL8sTUfgop9EN/gZXek9ibrtztHkx MT9zOEPJzJkpsvOTw4jnEGGRm8nbCX88d3la/LjnxoYyE5i3FWEa7VnGvQYFpRwzhKY78ZzMmB6E d2E/BfuayOMZ/ZtFE6bJDAlWom8Ky9PO2SLrE3h4MLwN/ixjh819MvphB0o3oWmDz3w0N9Ly8cR8 q+jDLWFx2lycaMi3L5oWul1AmcK3kV+Q7w/AjMLnkOvBWfJthETp3yDfJSiciByxPJyPPqq7Gnk1 3vLhF2i+QN6PjdPrvEJ559kWPgDHwXLQwP1whtArJVRxNBlQCc0U5BVwLawRyXF5X32Yur+hWQpv p9Zy5EyYis13yLVgZdgL/YdwJ5pc2B1NEu05gUaj2YTnNDQ5cBj6qM3DaM9ryNmwIvYdsTkCf0Xf DfkccohcH34bl3xYm/vSI8+KxjuOn2uxrwNro1+MTdSSyH4vXIQmL95C5moUf5F1Obgf/lcUc+RB UcyRFVwB18ZlLe+JYi4abwH8jdKl+F8b9Qu5AvLLlBrYOOoLshf1BQ8lEr0Q/VdRv+LvOQ9/xkMu +pZR77DPiFd3moHxbHqRTcuzaWE2LRGmov8VuYbQ3Tcbz9ncS9iKe3UhnpXwfwpW5C7RPGHOmLmw Hv1qRq1HYLu4ez7xojY3hG/AkjAmjJUXhguE/nuwlfQ9/Cv6JJHN64k53IKZOVg+gY1mZlw+tzqD PD+e5uSz8eaM5hHG8QjxF94bjfLFA7LK6F3b+EhZZcjjIvnibuRixE04g9IZ8ZtgMSIp+p7oM6il kFVCLiZrEM2KBEdCqXUTmptE4x0m/r8lOBIWY3Q6QZFvl1KzHJvvEhRvjYj8aXp0dbR24vIGrB36 nxOzxUVGvxnNiou/OXk8M2qNaILz2KwXTVCeddTlIt9bIMKL4iXlaT/eUtbpRXlWZwZ6T0lsvXVo JgudZzk9kQFMD/yfI9qLsVzEzKyFz18vyicCDeOy13SjFyHRCCOZyFek18WhgbXjXWAx5qdoLiMO x6WWIm7m2sSMlRj+GS7G5n6Yg2Z8wpvEthJyFPlFCYrN9rjbU7Slp68Sn2jOp9P+Y8Tkx0RsWzmZ ee4ob9GZyd5j8H2o6fs2iaFrYSsoGvKh6YCfj+G7eCP/e5+KjTrJTK4Vr+XYE/1i9G+JRh1FXwKm MAqPJ9a+jFcffFaPMiQ8AI/FL9DTllA+r2EH8bbCfPTRrIjyZC88H6clT6NvLHPMZ/74h8U+qFPo YmKi/PmhtMf8IDH0xyOPp6c3Uhrlul+iPCD9dZTWXo5NNfSlsfkCuQnyS4l86FrrNUfzE4xyCP3S rWFvyN6ho9iST7zPIbuS9zz662ALiDfdNe6elDT5xFTBcjVkn9UfwQFwFvp5WEZt2IBmPrwA307s TTI6C6M2i+y/gDyJWiPhndHuxqwImWP1YUjdw8h7KW2GvCYxB0SGOtqFq6P5EE1b2J97JaE/ADeh Z3dwO+8Hrv1kdS9O6b3osxOrNRtv2XjIJm9kUyqaI8jRrl0GRs8bQ/H2Doz2xFHIPDl464lYFpZf sEeUikZcdgddFXkEll/CQ2T+IZBnHv8uyN4aEPmQJyUTjeMwerGzMJfV3VHiE41apE/0S3aEXmSn TfAabGpdPMo+kg1HktVF7kS2/xZ+SMbojr57/BpYjPgUI/6iTyeHbCJKmxKy7AWNKM1JcCStLcZq EpvXErHtBEXfH1Yk8/fA284Epe51MI9PRk7xCciTvK19MiY7fmPkxuFxV7cJ8hU8Az/Hd4e68Ull 66BQ+sX7nG9F1p8i/4Mze/TtjjjfwajF56c7OXX24TPWPuHNkhPQHxdZR/KpoKPkND57rSCnA5Wh Wzt5TiBvrjL9oXLG9//quFtk/YEv3yd5WWh+9uU8WCCW6ojQG0KtLGGwWeiHsKEvbwWz8NYLP6t4 N9IWPxfEJuxN3V7RfYX6AOzgV3Q8Z+6F7qnb5CKPQ99HaEaYg6IXWX0k9OpTekAYpGIzHeabhx01 Hjr4Hn0R/USIt2BhdEd4EE6FLxt5m5ou1AuQqwd9nXxYZO+0fKPYtdCdCEyKaNQu406O6nOh3ih6 tUvsg07ULRt5EL1OMhtkTZl1ku3NCvRS66SUBsnYrIIn0dcROr14yBQGy2nVOdgaThU/uk+izc7e 84X+fqHpBfNpodGeUN7qKI2stRaNt5lSzlne13xr+nuZw3qO5Cs9U/ql5TPlp0X2Tmn5nt5eLe+W H9KTHWdol5+9UmLvLYRLoBGaKXhYoWc7rtUyw2sY+fZROzNbsqhovN+wWcodb6fWcuRMmKqTnM13 2NTSMtsr68tlZLV82pglsrcT5st/w1F318mwrGQAOArOg1Zo0vCQI7IepqvKmtJururhIuvS+gtZ ++g3YZmNZUXqdvTkSUzj7Yj3d3l28uo4TW3vmJMLPLe6dSlPvnloRPbq68a00PVFnfdTZceUUi+A c3Rz0ejXneeu1K0N6yTkA44xoTqDt8WwMf5re98QQxcf/Zs3ScYFzbd4XoRNTKhOSi31i7REf6oU /8ahiTC8XSjfn3eal5DfRj6DPBT5cTejPg1XOk6CbYRBMaH5J8xHUwGmCHVN+Cz2/bEZKAzj2HSE Qyltj3wf8v1Y7oJn0bdCv0EYa4c8BNbF5mPkzrAlmneQ5yM/AvugWUp7SsLovgHyBVqVhWYnPECt i8gHYW00w+G9aOiv34y6c5B9St+Dp9B0Rb4FOca9Zgm9X5Cj6O3DwzRsbkC/H30T5B3IbxMHomFe gLthQ2p9GsuTzx2icRE5KAarRKODXAGmwOui0RHZfzsaI5HNQDgSjsPb5GikqFUjGi/kUdFIYbkL nkXfShhrh+e66D+mbU2xpy/+w1FksBmAbKKYiEaPpj2VaXlUeh72JUqbkUdgUwoepdZe7KNxrArL 0VrGOiBKQTQHopY/BqNWfUbLozn8E5ajadt6/OfCaL4NYgbStvBOLLmX2QO3YXMbHIzmOLIVJh0U n0nM5LAedYfhDZtYT/SZtKRetF6I3nFqvYVNKvoj1K2FjDfzPXIn5AeQk5GjGTUJP/mMQpx+tYcb 4BD4KJZ/ptY6ZGZIeDd9j9bjYe47E7k1+hNYEo3YBGRNrWzkMdHc5u5/i+IMq1F3JTLjpYle+BRc hibKFfOj9YKHJozyDliKNnfDJgeypoI0ZMbF7wFb4OFm5H7wemwK4CFK74KR/gpIDtGsZf/vsAv+ t8Ln4GJsyId6ObWOMYdPomEsNH3x10DWrH8tlmvhJ3A13hogn8GmN7wdDTk2xD4kF8VuxZ686ofI 3CUkr/qnIWvE/IBMj4LxaMifPpaGCGtmoPkamVUWvIrNKhjltNnoo0z7BmQcTRTVGZCsGHyDvAhe RquuwpJZZFgXhhYadgd/LLWimfAleuIQIwMEvdBvRM8aNFdD1n74Im3Og8wcn174jKxPVHXUi2h8 2R1CMq0fjRd1fTKDie71OvwIRrMoyjBRJoz2owdpG3uKH+1rzApTHLkMZKWEUWbuzOx9hHlbknl7 gDWOH59VGRBn8x6lZHj/ShjlAcY3YD6bhbTnHvzPg8wEMxFGu/NXyL9CPCeRXZNoc/AKtVhxsSin PY+e0Qkp9d+kLrnRDJdWKVXYGpaHL8iOE5dP9ybBNsKgmND8E+ajqQBThLomfBb7/tgMFIZxbDrC oZS2R74P+X4sd8Gz6Fuh3yCMtUMeAuti8zFyZ9gSzTvI85EfgX3QLKU9JWF03wD5Aq3KQrMTHqDW ReSDsDaa4fBeNPTXb0bdOcg+pe/BU2i6It+CHONes4TeL8hR9PbhYRo2N6Dfj74J8g7kt4kD0TAv wN2wIXUzKa0Cr8MP9mYkHIdmMqU14ChqNUWPf/9hOAAa7jsaVsZDpD8P+1J3M/IIbErBo3Av9lE8 q8Jy3JGYB7Q2iMaCNviPwagln1EazaWfkGmDvx7PuTAa90HMBNoW3okl9zJ74DZsboOD0RxHtsIk RjOJGRXWo+4wvGET64kGfdJbaFKpewR9LWTqmu+ROyE/gJyMHI3jo/DPaNYhMy7h3fQimuGH8TkT uTX6E1jSr9gEZE2tbOQxWP4NuRr2K5GJtqbv4VNwGZpoxbEK/G7IOZAZGKQhEz2/B2xBrZuR+8Hr sSmAhyi9C0b6KyArTjPz/b/DLvjfCp+Di7Ehe+jl1Dom9E6iIYaaNvtrIDPcvxbLtfATuBpvDZDP YNMb3o6GjBRiH7JyY7diTxbyQ2TuEpKF/NOQmWx+QKZHwXg0ZBsfS0MkNfPEfI3MWghexWYVjDLA bPRRXnoDMqtNFNUZkBwSfIO8CF5Gq67CkhlimL2GFhpyqT+WWtGIf4meOMRYI0Ev9BvRs1LM1ZAV Gr5Im/MgM8SnFz4j6xNVHfUiGl9yaUhe8qPxoq7P+jXRvV6HH8FoFkV5IMo2UfZ+kLaRgf1oF2BW mOLIZSCrIIwyQ2QfRZJc518JWY8+YxcwV81C7nUPdedBRtlMhNE+9RXyrxCfSWS2JNoTvEItVk0s yirPoyfyIaX+m9QlO6k9xih5JybfXUkLknkbI/++O4s3QrlGPvVewXukLpQ+HQRK3iClOi7mTZoW jf4O/VzR+6FYuk0okDcn6G8TBh8J/YboT+NhBKVHheEo5FyYhc+TkSV3nyP/Ft6kyBsz/TSaBxLv u+Tt3xnenl3Pm7Tz0RszNCullv4Ajcb+JFxFH1OEeio97c07sR28rcpEzjSvSS2xUYWi9y5PvCVz VF/xTiwDP72o1YE3V61F413uL1XyrixfVg2lT8M+wviIQvmXuT0L5ZtCGwvlzWQfeYOhPxDZq4/c l9IOyJuQ92M5SWQvjoc6lL5Jrb3IpSNvaL6Or0AjdRvDgejjYumdR/ME9mnUfYbS5sjplIbIdyDP xLI1d/8Uy2OU3iNyvJe0x+8W9ULJ913PiWxKcK+ayCMUb1bR+Gh2Y39AGPpK5gYtMenYlEfW8CCW ScgpyN2Fbg6JvIo7voy8AHkVlmXhCt4OHUHOxWYcdfvKHc26RJuldCL3fZd27kc+nbijzMbGyLdh PzC+Qd68iV59FJe3uFn4XEjpVOpeJvF3GY/3omjmMSJ5+O8Wf442iP0AkfUOabmpL7Kb0y1kN6RW R9G4uk+50qfi61ysmCHe63F5O7paSl3ueo7+So/S8fC1SuYd/jpyoPw7zZrRXeRbEK610vLn0Zcn 8mXo4wfiM7gH/zb+uLNZi828uMz8Svi0lG6DTaRV3pIoetI7bwbMEHtdJ76F++6W0RFZb0SuA5Ng Y6G710bkLdxrmcxD7jhdpcrakfvqjaqEvJkkYie5Yy/0h+EORnk5tfJp2yHYjtnFXAoGoYmLvTlY KJ8mVC783vEUPvOiu0Tjxfo6l1hlEpk5yDGh/PaXy67MIn8WbC9zIGwupcE+aUPQs/A8Y7EG5rMS pW6lqCUiu8hIrM4UfsfT0QJWKPclVpVl7LwZtK0DmnEydnoOcVuF3DreVuITz8Uml9Lp9GK6+L/4 A5qjfO4mHlJgB9HoevLJjt+SCJ9EsyM+UWav9MU7xlgcwj4J1o7LrxAEfB60VNpmUuN/5V4jWBEF 8hkBrVW0sEpcPhXKLZRvAiTRx5fo9WUyr7zrmau5EgH/pWi85O7e69HsEsuQOeZ6t4WdXWKYRp75 OsobsgZd7ySGp6U0XC138Qrw2Y1W9SGepanbmLVQWvTu1MYnDsIgWVpoerA2+8h4qfMSAReTfEbh BiylR93j++BX3DGdmSx+7o0/Ql2J+SiJieML1D1I3aPMcJnnFSUmXvk4n+NQemv8DLJ8FuMT823Y rMZ+ZURisoTvLy2i9HE8tKJHs7lXq8R3PLbwZCV+Xo6+74T/HNqcRMz/xIisEnrziM+7qpeLSUny Q2M0U4Vql0TDRWwueexxWWvknHbix43Rb7QtYPcRvov9SYlksBxmMHYVyU79xd5FW2ZCyF0OEPMF 5Ddf5r/LaWQzxrcP2WaGaBTfJVOfw7XEajWrsg7zcC72G6Na3GUQ7TlGf9smMnAbYit32cScmRf1 Aj9Jonc7VMA3VWQVd5L7ho/KLzi5GS7/zu4t1VbOgNzlMKt7BDMtDf/5cl83w39jfpYga6Wy16Sy K7GzMP8t88QnC/XD/izZbC4tOaAyyHsP0WaRF7sdyc1zolGeuarFv7mN+L8eZadEVuzELtyCDNaS /Vr8L8XyNNG4Cw/TE71wchjl83nRWkvsbvJvDKfqd5BlR9hFrJrT04L4HrL0blbfBuIg/7K1tzD4 ke+krcPDAmZ4Hpq2xHCWeHNreQ1xk7E+CucyryahL8m6m8qsmCiy+oUd7X00k7AvSKzofPasKOdn SFZhPqRIzNXn9KtfNPrs1yujUvLqXlZHebLoVJiHJs7+WJaniNbsKZvRkPOD55khGURyIp/mj2MO V2ZH4GktxvOM28F5ruBe5SVWpiAx2wvIHuvIgYpeRJm8gDwg7IfNlvgSJZ/Rj6BVkmduwkN3bFYx h4egqYP9uwmOYFxGMNsL6OkIereOXXgFbXaa+K+FXzMTetHfu53l36Idk1qjEk9l0ZObzMO3qDtV VXXyFvq4nvZ/KYw3EW+FZ+W3sBwHOpuRvN87yhs53oIm8dmTShYbx4F8WicahYdbA/luat/wjPxO GnIychPkJsiZ4QE0y9EUIM+U77WG+cgFyBcpLS5yrJn8QhqaTDd64uETbHx+G22fMDwnbYiJn9Sw ozC2UH4hTf41X3xZbJX8QprIFzeJHJ8WLpFfSIv9IJ8sx8rBc/wS2rfiP5Ll1y2c/Ct6fv0s9jfk 9shD5HfSgp3yO2lRH8PDYp9UWuRYMpYXaG1T/AzApiKlWfSrJfyVXs+ldCPyOfR10LwP5d9KZyTV wGcb7n4nn4kXIGts/oLnNUSpgDtq7j4b+TXqtpZvI0eU9rsYHhJ9kkVujYdIn0Eb+iO3Qr4DD19h X4L2QNqTEbUnXEB7tskvm9HrFoleN8XzAGxuxX42cksYo9Y1yPwGXewuZPob60Ev5C6Zipbwq2tN w4DSPsg+dzlBTGaiaUqpG514I9g0ZuBD2HwLP8ayEH0T2ryeNjN2fHvQXDyJ3AJmy10u7pA2XNyD /KUwPhD2RXNULC+ulQgn9GNhMVgGP2WQ74UtqLWeWt8g70RPfC4u415voH9H5LjGAyOeaMPP2Byk Vo3oU3SV7M1KOqZMzoRReSr1jlGD71KT8waMuVu9LDvQTb3aV1cuLxYWqjIqRYWqsqqlSquGqpmL bzt1vfqTut35uFHdq+5XOWqoGq7GqpkJ++IqpqqoNHW5aqSaOy/Xqq6qj+rn7tpLTVLT1CB1pxqh xqlZ/PdrozpWJbmMU9tl9MZuX7tKtVfd1C3qz0qrm9R96i9qsLpLjVTj1WxVVpkuPXtmqet79bih uhrYu1fX6moxXsrxe9TVXE6v4zw2cU8C16nO6gbVV/VXxu3wvdVkNV3lqjw1St2j5lDnMlVdXeF8 ZqirVQfVXV2pHkRfXpV0caihKqq6zm9T1dI9FXRUWaqHulUNcO2ur25WU9QD6g41TI1WE9w+HrWg lCqmaqpKqp7zkKmucTt1F9VT3aYGur2kgcpWU9UMNcRl4TFqovxOdk7G6ByTDfvBXHg3HAcn5wzI G2NmwHlwCVwJV8PXcwaMHmy2wV3wfVgAD8BDOTnDRpgj8LTQ17AkrArrw9aD8obe4XeC3WCvQXcP H+b3gf3gIHgnHAHHwUm5owbk+NPgQ3AhXA6fh2vhZud4gL8Lvg8L4IG8u8cO8w/BI/B7+DM8B+PC wM8bnpMXJMOSsDys6gpHBWkwHTaGzWEb2B5mDRc/3WFv2Bf2h7kwD44aPmrQ3cE9cDKcPkL0c+A8 uBAuhSvgKrh6tBujYC1cD7fBXfB9uHf00Ltzg8/h1/AoPAlPw/Ojh+WMCBVMhqmwKqwLM0aPbtwk bAM7wG6wN7wNDnLMCPPgGDgJTocPwQWOTcOlcCXMh2vhRrjdMTN8F34E98OD8DA8NnrswNHhj/As vCCMaZgE7eixI0bHUmFFWB3WgfVhxhgXyVhL2BZ2gNfDnjAbypsb7XJP6n/w17h1XklV/r+SPH5k +//MQMl7r9DlxaT/b1c+V5HsqWr/g8X/II3Lc8X4Pf//F8lz2ft/Z+k/TM2IaOdVrrzEPiVM/sMs 9YdZ5X+w5B9mdVpq+Ov9jtKD3+vsv6VxO1VZVf4/lMohabc/1fyP/tbi55//+N/aqs5/8NdzO+m/ 57+Pied28H/PEn+ITdzTxhi36y9QK9VatV0VqMPqtOd7qV6al+l18Hp7g7wx3nRvgbfSW+tt9wq8 w95p7euqupueqOfoJfp5vV7v1gf0MX3eJJuKJt20NtebvuZOM9HMMUvM824Nyr2Sojlruhe5Hljk +qEi13N/d+0XKQ/dMt+vYt7vrpMzL71OWXFpfXv2Uv+pfS+9LqMu9V8mtch1nSL2WUWubytyXaQ/ ZQ5cel22bpHrnkWu77m0/ZWXX1peZeOl17XrF7lu+Ltrt/5qNy5SPo1r7fJD6aiHV/SM/taNeu67 OVfW5ao6Ce0Hib8HEn8PJ/7++L9Zp2cm/rZN/M1K/O19aSvS51zayyubX3rdMH6pfaM+l143KTIK GRlFrjOLXH9Q5PqjItffF7k+eel109K/m2VOaJ5a5Lr5pfbNWxa5Llp+fZHrbkWuu186iq2ud7Qu Mjne4yrXW0q2Hej+p9xKXSDfyAhKsVeUVmFKF7sjJctut1vsNqcJvRPeCWf3o/ej8ryfvZ+V9s54 Z5Sx19prlW+vs9e5fVPmgzYdjYyX1qV1Gadx9zZW2mOKu5oN3XVZdxoZpZaqHeqQOu+lujYkuVal ptyodEpWSi/HLik3OUrvSrqcXN2dFhq7M08be1QZXdK16Tv+7rDupKXLuOvj/N1h9yrtrvY77rAH HHcpnxlaUdW0h1xbt7jSr/i7w37t/m5z19/wd8fvLA8nLL9NWB5JWP4zYfmv9nalvd1o7w20918l 3SnpQUnP35fY3bTwXVr4Pi38V8kHlHxESQElWsW0+59bZsW0/CuTkrqki2oZF1WT0imls4v6FrtF ha5N21yk3Clb1qLh80L3/7qu/jTXq2nusoRXQk3xKnpV1FT+W8nTvb7ebeoBL88bpmbx30ee4430 xqgHvTneHPWIt9h7Qs3zfvJ+Uo96Z72z6jHvN+83tUCmhnpchzpUC3WKTlGLdCldSi3WZXVZ9YSu pCupJbqWrqWe1PV0PbVUN9Y91VN6jB6rNuvxerza4rL/RLVV36cnq216up6utuuZeqZ6Sy/QC9QO vUgvUjv1Sr1P7TLF3ay5YDJNpoqb9qaDKjRdTBdPm6fMU57xx/j/5flBTpDjZQSDg8Fe0+CO4A4v MxgaDPWaBaOD0V7zYGww1msRjA/Gey2Dj8NZXqvkm5IHeD8kzyzmefGUkikd9YSUW1Oe1i8WH1T8 Tn2q+JTiD+nzVtskk2Rr2BqmhK1la5mStratbUrZK+wVprStZ+uZy+2V9kqTahvYBqaMbWQbmbK2 iW1iytlMm2nK2+a2ualgW9qWpqJtbVubSraNbWMq27a2rali29l2pqptb9ubaraD7WCq2yybZWrY frafqWkH2UGmls21uSbNDrFDTG07zA4zdexwO9xcYUfakaauHWvHmnp2vB1v0u0EO8FcaafYKaa+ vd/ebxrYB+wDpqGdZWeZRnaOnWMa24ftw6aJfcQ+YjLso/ZR09QusAtMpl1oF5pmdrFdbJrbJXaJ aWGX2qWmpX3aPm1a2eV2uWltV9gV5iq70q40beyz9llztV1lV5m29nn7vLnG5tt8086utqvNtXaN XWPa21fsK+Y6+6p91XSwr9nXTEf7hn3DdLIb7AbT2W62m02W3Wq3mi72Tfumud6+Zd8yXe1Ou9N0 s2/bt80N9h37julu37PvmR52j91jetoP7YfmRvux/dj0sp/YT8xNdp/dZ3rbT+2n5mb7mf3MZNsv 7ZfmT/aEPWH62B/tj+YW+7P92fS1p+1pc6s9a38xt7nJO4D8pchcnnfeO++yWKFX6LJHoN05gHUW sM5C1llMV9QVVZKuqWuqy3RdXVclyyxUxYKBwUCVEgwKBqniQW6Qq2wwJBiiSgSjglGqZDAmGKNK BeOCcaq0rW6rq8ttTVvTrfE0m6bK2Dq2jipr69q6qpxNt+mqvK1v66sKtqFtqCraxrYx/w2Upqqy bWabqSq2hW2hqtpWtpWqZq+yV6nq9mp7taphr7HXuGwl+bcW+TfNdradVW17u71d1bE5NkddYQfb waquvcPeoerZPJun0u3d9u7/Zu8rwKs42rafmdk9c87unklIQghBihfPSYDgLsWKe5EiAYIUGkKo YMWhRVqkQHAIVqxYKMVpcYq7u7tL4H/2yUKhL+/39nvt/6//6jVX5lk7e3bumbnve2Y3eyCX6qw6 Q24Vq2Ihj4pTcZBXfaY+gzDVU/UEn+qtekO46qf6QYQaqAZCPjVYDYb86hv1DRRQw9QwiFTfqm+h oBqpRkIhNVqNhsLqe/U9FFHj1DgoquJVPPL1RDURiqvJajKUUFPVVCippqvpUEolqAQorWapWVBG zVFzoKz6Qf0A5dR8NR/Kq0VqEVRQi9Vi+EAtVUuholqulkMltUKtgMpqpVoJVdRqtRqqEv99SPxX DbnzF6iO3LkJaqgtyJ411TZk21pqB7JtbfUbsm0dtRtZtq7aiyxbT+1Hlq2vDqJmNFCHUTMaqqOo GY3USXUSPqLfH2msbqlb0ETdUXegqbqn7kEz9UA9oHmv5PEVg/zEtTmwbemsCWuCm6NYFDAtUUsE 7kpyJYFwl3CXQB7+q/X91fr+3a0vlFpfTtttsWjXsb/a2F9t7N/UxpjeDv28P8vE84sKWgNIC0Wg DFSGWtAIxwvt0L9/gc5yCHwH42EazIXFsBI2wDbYC0fhLFyFu+jsgbmY5fkMhKeLJ9bzOcWuni8o xnm+pNjN0wNjLC71pBjr6UWxq6c3xTjPVxS7efpi7IrH9aMY6+lPsatnAMU4z0CK3TyDMcbhcUMo xnq+ptjV8w3FOM9Qit08wzF2w+NGUIz1fEuxq+c7inGekRS7eboDx719MO/qGYR5nGcY5t3+BURG U8m7eMY4yHzvIDPWQWacg8x4B5l4B5EJDiITHUQmO4hMcRCZ6iAyzUFkuoNIgoPITAeRWQ4isx1E 5jiI/OAgMs9BZL6DyAIHkYUOIqOw/F08kwiRGYTI3H8RkR8dRBY7iCxxEFnqILLMQSTRQWSF01Z+ cpBZ6SDzs4PMKgeZ1Q4yaxxE1jqIrHcQ2eAgstFB5BcHkV8dRDY7iGxxENnqILLNQWS7g8giQmQ5 tZR1hMimfxGRnQ4ivzmI7HIQ2e0gssdBZJ+DyH4HkQMOIgcdRA45iBxxEDnqIHLMaSvHHWROOMic dJA55SBz2kHmjIPIOQeR8w4iFxxELjqIXHIQ2UGI7CVEDlNLOfsvInLFQeSqg8g1B5HrDiI3HERu OYjcdhC54yBy10HknoPIAweRhw4ijxxEHjuIPHEQeeYg8txBJMlB5IXTVl4mI2NAMjIGS0bG4MnI GMJB5jIhcpMQuU+IPLVbiv0bwPZ102xaA8jB9vLJoqqoLlqLNqKdaC+6iK6im/hc9BCDxGAxRHwt vhFDcRR8VpwT58UFcVFcEpfFFXFVXBPXxQ1xU9wSt8UdcVfcE/fFA2+k/Rt9bDfbjV8wyf7ffFFF VAEuqolqIEQrEQWaaCuiwSViRAy4RayIBY+IE3HoBD4Tn4EpuovuYImeoi94RbyIh0CxUuyEIG8B bwGaZQgFQ0uvvadl0DJqmbTMWhYtq5ZNe98uGV7RA5pdT/YraZ25iVz2PvxM8tw1Ex1eH5HdOSK3 PTclOuAe0II0+z2+2bXsYL7xueTvDdJSasFaKi1ES62Famm0tHjs79/LIQv4aQFaoKZrLk1qbs2j GZqpWZpXU5qf5q/Z810alq0XXqT9Ga4V10qApZXWSoPCfZEQImaK2WKeWCh+Eb+KTWKz2CK2im1i u9ghdr4LcXu2TCSIBDzjLGE/b/WD+AHxXiCQRxG5jfh9Z8W112dPwKN+wL0rxc9ilVgt1oi1Yp1Y LzaIje+qYzr7TDETzz5b2G8LmSfm4dkXCmRnvMKdeHa7HPbZ80LQO8/6jnIQZmcdzOzP/cnWRZ+z WwN+Tv+EL4W+0A/6wwAYCINgMPbrr+Eb+uXq4TACvsVePhJGwWgYA9/DWBiHfT4eJsBEmASTYQpM RQaYDjMgAWbCLJgNc5APfoB5MB8WwEJYBD8iOyyBpbAMlkMirICfkCt+hlWwGtbAWlgH65E5NsIv 8Ctsgs2wBbYij2yHHbATfoNdsBv2IKvsg/1wAA7CITgMR5BjjsFxOAEn4RSchjPIOOfgPFyAi3AJ LsMV5J9rcB1uwE24BbfhDrLRPbgPD+AhPILH8ASewjN4DknwAl5iM2a8Jq/Fa/M6vC6vx+vzBrwh b8Q/4o15E96UN+Mf8+a8BW/JW/Eo3pq34W15NG/H2/MOvCP/hHfinfmnfAo/zI/wo/wYP85P8JP8 FD/Nz/Cz/Bw/zy/wi/wSv8yv8Kv8Gr8uDH6D3xQmv8Vv8zv8Lr/H7/MH/CF/xB/zJ/wpf8af8yT+ gr9ECrL/F0MITejCJaRwC4+oKWqJ2qKOaCyaiI9Fc9FRfCr6if5igBgoRopxYoJYJH4US8RSsUL8 JH4Tu8RusUfsFfvEfnFAHBSHxGFxRBwVx8RxcUKcFKfEaXFGK6oVs38TXNuvHdAOaoe0w9oR7ah2 TDuundBOaqe009oZ7ax2TjuvXdAuape0y9oV7ap2Tbuu3dBuare029od7a52T7uvPdAeao+0x9oT 7an2THuuJWkvtJe6Vw+QpWUZWVaWk+VlBfmBrCgrycqyiqwqP5TVZHVZQ9aUtWRtWUfWlfVkfdlA NpSN5EeysWwim8pm8mPZXLaQLTFFYWqDKVq2k+1lB9lRfiI7yc7yUxkju8hY2VXGyW7yM/m5/AJT d9lD9pS9ZG/5lewj+8p+sr8cIAfKQXKwHCK/lt/IoXKYHC5HyG/ld3KkHCVHyzHyezlWjpPjZbyc ICfKSXKynCKnymlyupwhf5Dz5Hy5QC6Ui+SPcrFcIpfKZXK5/bvi8ie5Uv4sV8nVco1cK9fJ9XKD 3Ch/kb/KTXKz3CK3ym1yu9whd8rf5C65W+6Re+U+uV8ekAflIXlYHpFH5TF5XJ6QJ+UpeVqekWfl OXleXpAX5SV5WV6RV+U1eV3ekDflLXlb3pF35WP5RD6Vz+RzmSRfyJducDOZIGfKWXK2nCPnynvy vnwgH8pHxmfG58YXxpdGd6OH0dPoZfQ2vjL6GH2NfkZ/Y4D5pdnd7GH2NHuZvc2vzD5mX7OfOcAc aA4yB5tDzK/Nb8yh5jBzuDnCHG/GmxPMieYkc7I5xZxqTjOnmzPMBHOmOcucbc4x55o/mPPNBeZC c5H5o7nYXGIuNZeZa8115npzg7nR/MX81dxkbjO3mzvN38xd5m5zj7nX3GfuNw+YB83D5hnznHnB vGReMa+Zt8w75j3zvvnAfGg+Mh+bT8yn5jPzufnCfGmBxSxuCUuzdMtlnbPOWxesi9Yl67J1xbpq XbOuWzesm9Yt67Z1x7pr3bPuWw+sh9Yj67H1xHpqPbOeW0nWC+ulF7zMy73Cq3l1r8srvW6vx2t4 Ta/l9XqV18/r703hDfAGeoO8Kb3B3lTeEG9qb6g3jTetN503vfc9bwZvRm8mb2ZvFm9WbzZvvHeC d6J3kneyd4p3qnead7p3hjfBO9M7yzub7j7T3D7NsffikzkyKM2cTxWVUd8PiA9R3w+JRuIjOCKa imZwjNT0hOgsOsNJVLyv4JT4TnwH58RYMRbOk7JfIN26SLp1iXTrMunWFbFcJMJVUojrWmGtCAOa gee6oRvMp/vr/iyc5tgjXGdcF9ll6ZP52U2ab79nDDTiOTcSjLU8lbHVeMwjaNa9Bc23z0S1vwse CIFMqPnV0AGNRwVYg+yMX2H2B6620tI8WrLv0fhDMKQ1N+P6IXML5kfMrZgfM3e8PvYQLq0HN/qJ EEiPDiBn8t0j84i93TyG+XbzBOY7zVOY7zJv2J9UKe0zqmD7jCqVfUY6VxKd9dU9Gg+u/aoMzDcr 8609frTHn/akeGtPCO1JTXtCaQ8HD9aaD+uuELefMy/KiwLnFXgFELwSrwQar86rg26MNEaCy0g0 EkEat43beD6uz+Z7/kMa+7bC/v+tr/8dhbU19M/q5n9SMwNkK9latpVfogLZylkeNbMqqVlNVKZh pJMNUCNtdUzWxqg/qYrd/4Ee/q0ajkMd/F0B31SX/9fU8LXaoS6ORf1+UxVLo/uwvUey87B9Rw10 Hk8c3/EMXUdDdByTyHNMRsfxFFttPWypzex2+Uo7ece3ddPyt1JYAVagFWSltIKtVFaIldoKtdJY aa10VnrrPSuDldHKZGW2slhZrWzW+1Z2K4eV851q2//deqs8ylDmn1LdeX+ru8pP+asUf6O+m80t 5lbS4B3vVOFDqMNHzGPmCfPUKz1WwSoVafKNv6vKSX+ryypEpVah/5Q6v6XNVtJ/QZ2rMc5S4lA2 lGWHIFaD1YHMdM89O2vKoiAXa8PaQD4WzaIhP2vPOkIB1ol9AYVYdzYayrHxbCI0ZcvYLmjBY3gs 9OBxvAf05r34VzCI9+UD4Ws+mA+FEXw4/w5G093zcXwMR7anMf4kYYkAmCyCRBDMFMEiJ8wSuUUY rBLhohysI8XfT4p/gEZvB7Vp2i64qqfQU7AQ/aH+kKXWH+uPWaj+VH/K0rgQLpbWNdg1lKVzDXeN ZJlco11j2fuu8a6JLJdrsmsuC3PNcy1lRV3LXZtYOdcW125W13XQdZA1dR1xHWPNXCdcp1gL9AZJ LMr1Er1BHxkpi7IVsrgsyda4c7hzsvXu3O4wttEd7g5nm92R7ki2xV3YXZhtte+fsW3uUu5SbLu7 jLsM2+Gu4K7AdroruSux39xV3VXZLncddx22213fXZ/tcTdyN2J73c3cLdk+d7Q7mh324LCfHTFa GC3ZUSPKaMuOG+2MWHbaiDPi2DXU2Xh2HXV2LXuAOvuYvTC5+RGXZhPzC97cmmyd5b28Q73j+cbk 51twNLqA7rg0Ya2dLcvf2MKgCLgc75ENPU1+3J+Ayc4XoCtIoGivrXbWVuPaCUz2Uza5WC5sNXmZ /SuIhVghPOcH7AMUlyqsCmhsLBtLT9lsgeZ6qJ5GT6un09Pr7+kZ9Ix6Jj2znkXPqmfT39ez6zn0 nHouPbeeR8+rh+k+PVyP0POxfWw/O8AOskPsMDvCjrJj7Dg7wU6yU+w0O8POsnPsPLvALrJL7DK7 wq6ya+y6JjRNPBSPxGPxRDwVz8RzkSReiJf/yjYNi6JxmmnQ6L8VUtDcTwgmAWkxaYjc+1jS3GA/ lxaGyY2oFkGfWAyTASUwmVAOyoMFVTApqI/JDxpCI/SHTTEFQCtMgdAWUxB0gVhICZ/DF5AKemFK jb2TQyjzY/6QBvtoKKRj6Vl6SE9Px7yH/bUGZMD+2ggy0l3dTNRTM7MOrANkoedlsrKuLA6ysR6s B/bpwWww5GBfs28gJxvBRkBu7MHjIQ/24GWQl61j6yGMbWKbIZztYDsgH8035aeeF0meujLNOjWl WaePX8+F/eLMheVBpNLxcB6OjjHSfj8kL8fLoWOszCujY6zFa6FjrM/rg46+Jwpc6Hjao2McZAwB t/GNMQJMY6YxC/yNOcY8CDAOGocg2DhiHIcQ45RxDr10d7MnZET16AdZbGWAHKgMUyGXzeMQhjx+ EMKRvU9AAWTwUxCJHH4OCiKPX4BCOLa6BIWRy69AEeTza1AUOf2G/d+ieH1FeePXZdnmlCUvliX9 W2UpzAvjsXaJBK+BYxmNSqRTiVzo7xqBpHK50b19Ch4ql0Hl8lK5AqhcQcYCYxGWaLGxHNJQGTNQ GTMZl4wrkM24ZtzCctklzUslDaeSRlJJC6H+JeD4YBaOMkpSqctTqT9AXXoIVVCVknBkYpeoEm/n 3H2tiv2zFZUozC4jq0X9Hl5vAZrL5KwtK/V6G2d1WG5cC3p9HPaAd2BRjBdDLGxENKpjnXBxES6S cHETLh70vU3AIHRMqnWLMPIaDY2GoHBk3hP8cPT1Hdb9KCMe0uIYbDlkMVYYayESR2K3oIRxx3gM UeghBkJHdAsj4At0B/OgD2r/MhiNWn8EJlLdr6C6/wkV/AyspBbwM7WAVdQCVlMLWEMtYC21gHWo 7LdgPar7HdiACp8EG1HPXfAbepwQOIi+JiOcRC+TEy6iKzHhJrqLFHAHNT4URwDIhDhC+hTAHkFC GXuWAWraz21BbfNLqzz8hp9Jx8bRU47i9xoB+q9IHO3Zra7GGzXi+71GoI79n8jONg6l6O550Ovj OAhjgjEDv3mdsQVb2xPTbr+4lcbZydeTka7E53w7x28J/WeYFT+ZkngIiIcY8ZAgHtKIh3TiIRfx kCQechMPeYiHDOIhk3jIIh5SxEN+xEP+xEMBxEOBxENBxEMpiYdSEQ/Zb8zYgCWweEWxEpH4R/dh ODNYAF5lJpaTRbAirAyrzGrh1bVg7VhnFofepQ8bxIaxUfitU9hMNo8tZivYGvYL28Z2IzbHEYfL 7Ca7z54i+bu4xQN4CE/Ps/CciG4ky4mlz45Y5KHYCNXPjk1YYYpNWRGKzVhRih+zYhSbs+IUW7AS FFuykhRbYc+zYxQrTbE1K0cxmlWg2AEV1Y6dWHWK4/VUdtSW6yEUE/XUdlTP3KYd9UC3ZUfXDLeX 4mq3orjG7Ucxye1P8YU7BcWX7gA7onsJpFjSj9H3tGM5kAn8UOc5ruXGvBGqve0dkA+wlNgGsYzh mH/MIjBvzvJh3oKhj8CyFcC8FYvEPIoVxLw1K2M/+8HKYt6elce8A/oFjqWqiHlnVgnzT1llzGNY VczHsw8xn8CqYR6vBwHH8qbEPFG3Zz6eubFisKTYqrGcGuar3eg3sIwu+2kmt8T8hduN+Uu3BziW Dd2PuyTkwF7VGPW2A+psd7D//34UTIAZMA+WwirUsR2wH47jyP869m3nfh62pBBs61mwLflYJCuG rakiq4YM2QjL3RpLMRfRGo8I/UCxCZtHsSmbT7EZW0DxY7aQYgu2iGJL9iPF5mwxxVZsCcUotpRi a3c6O2IZ09sRS/kexdXuDBTXuDNSTHJnovjCnZniS3cWO2KJs1IsySZR/U2mmptCNTeVam4a1dx0 qrMZVGcJVIszqeZmUc3NppqbY9eHO4gQT0mIBxPiqQjxEEI8NSEeSoinIcTTEuIMND+gp7oFcQVQ T2d+9r9o2O/xrkbP1GeHCNRiZyaKBVNbS0VtJMT+bvssLPXrpbZ2S7K5F/lkDLUVyu07ZMwfGQpY Smb/Cr3NRJz4xda0EBjM6rL6rCFrwOqxtkYDVJ9GyfPCvCvvyQfx0WK8mCMWq+cqSb1QL5FfJxqT jMnGFGOqMc2YbsxArl1vbDA2Gr8YvxqbjM3GFvVIcSWUpnTlUlK5jSfGU+OZ8dxIMl4YL02kPfNb 8ztzpDnKHG2OMb83x5rjzOVmornC/Mlcaf5srjJXm2vMo+Zx86R52jxrnjcvmpfNq+Z186Z527xr SctteSzDMi3L8lrK8rNyWbmtPFZeK8zyWeFWhJXPym8VsCKtglYhq7BVxCpqFbOKWyWsklYpq7RV xiprlbPKK0t5lVIBKlAFqcfqiXqq0qi0yr4HmY1GfUAjPR2dQxXUtHa8A6p2LI7oLN4DR3ReevpZ 0fjNj0Zl/jT3mkL8KH6EANdC1yIIdCW6EiGl65HrEfo2HKtAKnusgv7mpHEBctgjFnQzg1C7i+CY fRmUxdH2EaiKI+5j8CFpdzXS7uqk3TVIu2uSdtci7a5N2l2HtLsuaXc90u76pN0NzBeo2g0tf1Tq FqTUPUipe6uUqNR9sZwrodGfqdF/rgb/I/X0qoYMQhMITQ/hGEA4piEcs1DJ81DJI6nkNankdcij 1E8e+emG7qVeWBnsed0ykP7N9v/HVvz322Ny28EzpKCWAtRSBNWwi+pTUX36UX36U32moPoMoPoM pPoMovpMSfUZTPWZiuozhOozNdVnKNZbKkjjXL2pqzeuXqHfdHqs3eepnQK1U0btlFM7Fc5nLd3v jc+GoCt5zQKvejoxB/UCask6tWRJLdmdPIpld9hD9sxxAyl4ME/DM/McopLeUo/S2+jRehe9q95N ZVSZVVb1vsqhcqk8KkyFq/wqUhVSRVQxVUKVUmVUOVVRNVWtVGvVVnVUndSnqqvqpj5XvdRXqr8a pIaooWq4+k6NUmPUWDVeTVCT1BQ1Tc1QM9VsNVfNUwvUj2qJWqYS1U/qZ7VGrVcb1a9qs9qqtqud apfao/apA+qQOqKOqVPqhrqt7qr76uFfz1z+9czlv+mZSw7+6Plb64HqGWp+yT/1TDn2RNbOdfyN J4Dd9rMyzlM1/+MzMq+fo8Fz8OK86esxe/KWKshAr8a8nN23fy2CF+CF8IiyuK06r8nr8Ya8MW+F XNUZWa+HfU/rXcm+j/VmwrO8nQr9bbLver2Z7Htk70xl/5Aq2HfQ3krV/zbZd9PeTFiWv5NQD95K WOa3U8N3JdSPtxKi9HZqSun39VZ/SG0wtfs7qfO7kvni7YSq9XZK/YeU6e3klC/5eukMf81N/J25 CQYnUT+LodZXRJddh96D8urtJ/abUIbACBiDo59pMBsW4PhnJayDTTgC2guHET8f3ev93+aF/qm8 +j+Tv3P+I3l2xMIwxh73QGl7LIBaF0yjB/seB2M5cBzNUe3t9xOOYd/j8lhmv99yEo68OFvGbuHy bXYHxyt3kU0YquVDXH7EnpBmPsPl5+wFLr/k9u8Pca7Z70vkLlyW9As+JsfxN/dyP/pPSBxj8wBu vx0uJQ/G5VTcfudYKE+Dy2l5RlzOxHHkxrPw93E5O8+Byznp14Jy8Vy4nJvnxuU8PA8u5+X2u8Li eTwuT+ATcHkin4jLk8QH9C7fSiBEZT3QfmOqjuXVQ+3fz9Ir6B+A0CvqzXG5hR6Ny+3sX6JHre6G y5/p/XC5v94flwfo6+x3X+vrcXmDG5nZzXEUyd3ZPO2BeTp40Ol5OnrnAPPO9eKo1/uDdz0ub/D+ isub0KkylR59hkA3+ZJGeMjKftwva/L/OFPNcGjh/Gfu7x6EkQdh5EHYG/9BysiDMPIgjDwIIw/C yIMw8iCMPAgjD8LIgzDyIIw8CCMPknyFnJwIIyfCyIkwciKMnAgjJ8LIiTByIoycCCMnwsiJMHIi jJwIIyfCyIkwciKMnAgjJ8LIiTByIoycCCMnwsiJMHIijJwIIyfCyIkwciKMnAgjJ8LIiTByIoyc CCMnwsiJMHIijJwIIyfCyIkwciKMnAgjJ8LIiTByIoycCCMnwsiJMHIijJwIIyfCyIkwciKMnAgj J8LIiTByIoycCCMnwsiJMHIijJwIIyfCyIkwciKMnAgjJ8LIiTByIoycCCMnwsiJMHIijJwIIyfC yIkwciKMnAgjJ/Lq/SCv3xYS2hRjEG2F0Hq+PqG1XJ6cAyoOeORlkk/pE1oWN5XkjIWbPo9Lz6UE D9XB19xl5HIxjfUpyJk2pbavpi/3G1vSTkvfOy3dzikG1aEFdIFOSKJREIt/9u2dEr6Mb5xMC1o7 I/JJhY95xKRRex41f/Fcrz0ycM+UPinz+PpoU3x9xKApgjPOjeapd4yky27t876+SKbj5XxOVyfq aq5AXrd2eKAvhb3iDjTqN+/SNvqTNrGdPgn39yl7owyUtaJadez0Savw9L609hYjMOWH0S1jOnXp 1Do2Q9lOMZ07xTSPjcZPZPZltPeLwNA397eKylA7us0neNYMNcqW9qVP5Q0PD/eF+yJ8+SIiCjTC 1Xy+8Nervq/6/keuzesz7f1moPZh9Rq1Xh0u/s7hvj4s05uYMR1EH6Qb3G7wPozBzY/W9EiR5dwA 1+nWLysuS7Wan19qRdyOKdEj78BD1ab+OKts2KOoSeFnIsLLLzi0Pku/jIfyLuvX82mBfbXTHlpe M33131r/dC3R4kk5Gs+fPfDhtkxLD6x1d30wpPPwloduDUl/ZXjZLK0a7RvYY0THovPidtaP7HF5 lX+9eWNvD26St9Wmhdk8TdO3THmn+Nrg4eMG8Y2+xPXmx+/5xew4mDi7QMCA+KmmcXHkR8Oe1pmw /l7qZmWGBkxOV3JE4vuBfVNH9El378jA/RkXF5u2XFY/lGXuzaEPlhx5+qRw9VlX7i5sWOv+8dLx YSk6tzxx9eTcOx0zav618/28uPqvZ2ovLh31wScFH666Eh9c+tv2eT/ybeQCO8T0PiwdIpLaF4hY psuqWT7D5cZGretSCF86e6NCsx2Uppa6lyJn4rrBG1N8VXz/mAY/Ta/9CVVgOj8kZk1DVevte89e z6yF+IJ7B21PcXnb3qXBDdjWgnnzBQf/VHW88Z6vnn3Ae1p134e+KlMqTflgQPm2sbGdi4SFtYzp kLfjq1rM27JTx7DO7aPtrWGdYzq16toytksYVjI2RGyG2AKb+QrlyReeJwKbYF48yNfo1TUzplXz VfVVfrXu4wNKOF/RrVu3d31FVMz/eO7YP3Q7YbechI8iO8yvFh8dcK7TEB4f3W1jh1Yx2QcdKV6+ Y+6QL/dnDws827Bdmg1m/sQhSVd/GnVdhl9sd7+rtm/W0aZFXJP8k+Z4V0+oWbbTyzajJpzZ1f12 lkUFdvRtcvPouk6RldY1Muo/7HJm0r1z7qpFS4Tt2LvzZvVMnR9p7/GZVeJXDG88SEWO6pBPrpgz v+aU3RuOD8sUsHrjqT6H6k19dOJ2Qob6/v4Tb84bENvh0/j1t+9u6Nx01rGOHxZsMO7Dz0vtzt+k UdYFba6lqVbBteibHO9N9x+ekG9y5gOPl1Xocfpmy7EjqpTQZ4ctClnScMbC0rWHuXX/PDm3FnFV TZt3TnjNeq3mjd8x7/uxOYZ8P2Lg1YnLkaNWIkdNe8VRemBkMpf+kaO6/Ud4ICM1NOz4Ib/vrxPd MSpP7djmHTv/zlC+ghEFInz5I8IL2gwVgfz0atX31ZL/BkO978uavJr+k7LRndtGxWQoV7t8hvK1 qxUJL1C4bJ7S+SoUzBNRoKAvPKsvc3KJ0r6zRLWjYuKiW0b9Q0abkH9s6q2eHC3H8eCuswfV7zH1 5zmlA563+jbhoP7Z2m7Hr19csKJGtXXnQlffSEx6nGHIp4XnxnwXM3mI50LgrW9L32ietX3N+Tdn l13WvEzuiXfT/bj3eeKDL6d3iQtckmv6sVHNe9ed6tfxxOHrwS/79xozaVAvyDvsiywr204cvmnb /RGff3Em/parSc/HeTe2SzmhWFDYpQOjtmRKU3P7nLoDMiY2ulc6oPDk23XnVJubNVfLZ9/GFPPr vm5MzPH109e7t538deuydUazhAnm3BijiVGqR96xu39YPGj4gN6Xe+xZU7f96Qa5t0SWfHIxxcbb ZfX+n4lUF3LPytF939nRqaDDsePzi6Uuwk/3aLH/t4fpir9iNA8ior9BXg/7fp1hYIqbfbcfO9l/ 2t62Awo2jx3xFlllzv/4SK0KnY0bpZ7FPVuSa9HGAkv8fHWSyQqpyodUNaX8gLL/K7JK3m3XIlUi tkqiqgZvUBUSla/iG1RV7M9R1TvPHPsuBne/i71a3Ne91S+lad/nUi3r1OffzK77Vb7v983YtvXF worHvjza6Yvs1TfvThx8eM/McTu+rQdFC11OjAi7+WRX+yNjTx7kD8o0qNV+2NFSx4OnLNm/NlvK 7RXL7NiXtPTp+XKDW/uVUU0faZMzV/xo6eDSvxzt8DjyfskN6VOeGlsVfll8/WQzxspOWFHmYKYt I8dP2poQ0ub5B/3Sf9sk/m7cox+HxaTrHVcsMkWFbT2LVLy38Fylh6nyDf0ZWvaZUH96vVkbPxkx vcToxOet9jQJ2WCyGi1nPb+3p/ekfuci8p+oP7rU9I49j17L28i91N/VNGKr50pEn0+DZz3dtLD1 2MFPjkxa1sw/8/Ruve9+eDA7xNTov+qCr4++Ctlrxiv2ypctlNgr/I/s1YxowfB8l23wyLu5W7HU wQLrIjy1L9VbGz2vqyo8jy9Xcj/O8ns/rtWpE5IE1l106+iWzWOjMpTuGtu2U0x07OfEUj5foXzh ERHhhfNFIEtFOKsR9ur/TYv3j6hmcUzDxql9rdamG/9xhgxlxsXV7lAizcFOO7bfudr+xffB/qdP FYntG5oYNiXi+suTG8pUy3wgBo4VqG8M3rYgQ6X7t9vO+7DK0ITVn1f5NP4DeTQp66mJXQftmtul XK9DXx27t/pu5IytjcsfXzi/+Onsbb8PnZUQ06XenVSjzicVGBUz5WBcs/TdyvftXyh4d5eP9JVt ag1NWBwddjS1+eK72Bxn48LqnAjyNXy8d2iLpO1bm1UIr/HT+4HnS/l2xeTwz55pc8FqxadEFB+x c2ohV//G1er1yZ5Tj0iscqh6y0t787S4U774pXlueFhh6qQ9H32TrfblL+ZWvlthV8FihSYt7dY4 IdWkodtTDK9XbP08TzOx7xXVNEVEGvn87K4XaBsh3ScwvME97/RBJhkn2zWxAb4Al8cZRaRkmk4n Rjl4vY3bZ0naE15tX7Yho8+M/bjo7PBOM4utOpzHl/r1QUFcs9IbUBu64sijLJT+P9WdZ1RTWxqG Q+gtAoHA0ANIk8AJReRCFEFpUg0GFCyA9I6IFAtEmqFK7yahKl1A4wVkITLSpImISrkEkF6lgzBB r1d07szc+THLNf/Ot7+1z15rn3c/+93f/nG+gxukCHtJHSORPHYQui09zIROPDuaAxh/gZsuoA2c xGvij4ce++tw+yPtRZH2HpU+g810H9h0AC3gxD6wHflvwLa3YDS/vPWf3ReYCnRW5egtca3SaXf1 cvkqp2mInFuB7tr0xauz+qqIN5rFzDutkwhktmjbdeOUQPj5IpSc/q/EAkzGiEc1qXLdr0rXa+3o 1PFbLcMs3I6tuRnCiE1m4+eYl4gRve4aj/ECViJ1LuY3Eu6U2VKiRsbix/m5kVAhRTUSJm0BLRoi nYPljycn0AsskQ3XIwktE9Dcu4ZNfN0xXonSnq7pvOv8C+he+zaRXUuBl8TIWomHfjaYE0STlxuT 2eaYgXTwyRNyF5fflfRg5d22cxKho9OO4/eJMk+bDrFBbKNT368QNznEGW2PJCz6C+lVdw1jJjp9 k3gsm5VgFwfiBXSjEU+LFU/wz7Fx8YLODyhZwNtTXjDOhUAijVwhUEPUdSmdDK+ujy4t9TMe2WZx ZjcSovB8OtTn1jqy7Zm8cw/PIuS4mz54KXMsu5er2WM3Tj+MUoDZCkJwA2yDl5fd27V6XnFP+j2n qXy1JTMkhMsqYtqCSqgXj24M37+lVU1/Sdv2krphmcaM4WyFj18fkyKjK38gUogMMR0YI2yNabMV X07ZNYbJXq+jhfuTE49LODbExyQ2R/Wlw0tYLTMWiCWhDrdZnBDVPs4ggaTiJVjAKuy22JPwDqcC baRcWv+IJ+oN6Ka1dld7eDOJZxPiFVWfjSoFqzvtOqYnkdkK2CqVjRl6G1AAlo6ewu/5r/yGOSh+ 5jf/z+A3oAwoAhRiKykAKnv8Rn4OFYC98OfZ3/9E73sEl/Kh9zpx0tedZf82XEseaUw1ETUubh/g MRQ7MNeV36Vf7A0Is0/TvzZN5NJN4NOIK0mxBMTfgZwnAmpn7tAfWIPQUI6ybUKtCmJhmUvL9vwy 2wHj4QJT44bZhHpRdEvU5skOxs4LpZ1lGjTEjTyXePs3kv1a6LLQzjFJLVmJolCjM6dZRqlltpxi YwG3sI9ngczNm73JFRPw5Jvr3dCPDI/RrqcrT8be0wHpaduxS0jZFSSPvqIL0iNuBOeza3MyYu8F z57x3aFKEzBmCAGxAVqzjwdFtaqfI0zvlQr6Hkdea0sfUr0dT7ACVwmwlm+vpT+kahc5Zbq7Qdvw TJj5K70LKTOS/+/o/afG8Dt6s+2n995f6IGglC/wDYoFgqL+HL8Emxyr/7k8sWx+xTCCHj63WP+K +TI9VNb2/4b6f8nKUuaaLRnXYEl94vDAZGXxtfftfiYGVOWy3p4WrizQwvanATEk2R4OYqSrNckM 3GooDDVOHfBXJ5tVl5qn8Q8LUIUWVfsuRXTOqFLNkZ/GMNE2RemQF9BcA0aFcaPjUU6vA+s/JCzR yYVQT96VFhPx2FrdHvVNlWVdoyd71PAYZkY7M3klkggqGfaIRhPIlLXlMVhKhPAxMj2v/EYbUs8H iTrkxdw05YHaDWGCDj1jsopeeEPinjaMuNWodOhCdt10zQ1mjYAetBd8Dmip9rW1tKDiZuKEdL/j TFlRe2JnXoGQG98ICW0zwUxkeiS4FKno96z61T3g8beWmiemSynSXeO1bkYJugphF5hfyFR3aFaM bczcqBrJKfBWIhk2eopyiPswq52O9DynpclZU1FRZmDfdE9jN9APHpjFBdhNaHBc4G3KEoF3ak4e mqxe1mmT6emTD9QXl9YRu3huCjOfN5ia2fKLe22QhDcd+5wPvC4dWy9h+qjcCXWH4GNV6UaA5tU9 0F7gcP+Ek3d5uDNk0hQp2mxXmykQxnEZjEKUno0hjcLHqspabCp9TWl7jssaFyWU5foWVuCTrvK+ jQuDXhWRky9gcMNbRB6sw88Ht8B7pwWNmtPmdH9bo7J1v8N8o8mx6YPbVH5yO1JqF9JoYdlnwEfo 25TLOiZ7BubcDM3+hMTSJANYmngwFRUQFPYT/fJ3hdpvZV580PM9l/a7bBmpkSz7a8iUcb9FzEgI sD/LtecBv3akQVJY9EDn4BJtxZ2dJEZUeAEw4bUOGh8HLu/rwoLEAKZ46UBJkAHIEWQD8gK5fy5D 24G8QcIgU5AfyIMS2VParShPDiA/gnig2L9co95+Hu72XlYeDn7CP+wlNFgqUAC5UKRsxRTw7FDt byJNP64aujJldUmH1DdTRVsYHno+nduxCDHUKXvzrj/7/FpsnfRQZ/7T8MPEHQsW6GJuWLz+IvQy jKt7PSaPgP4gqWqszaTXNhvglNJ7BcCROqW07FMqxmIjRkwY1ERn8cdWwqAXuK0fJrfRKsNepDxK ZmdbG6xnDU/nKiO01ryMMbJjgEtxbJJQDZ+ck8x9Op8JCh8peRRns8iZEqLJn0zKUnhupBSxyJXT 4RDhil7tV7WsaVBQRPesdceWrh4BV7gfNvq75AsDuOPbTNxmsq6uog4z7m2pfK2HpUH8RPbindqu 3N7Xgw5sWyJn+Yyn3PsRAisELFgAwIL3fVw6JBbMRGmi+yzGkJ+2+X9Xj6P/XYr48wDPfh0yf7vw oKKM+EeGFnlgr1QGKCGVKWfSwwoUE/OjDDUOCg1kOY8H9p1cwt3eeJbXPn9V+Ac27wnknBgvULJx JdjA26em+CZP2nYz7UzepMUvs6euP7EacZsfvNGSScDzvoRzPw66xf8GjbQxPFq+xbl6JAhX2Rn7 sVmyLIyBdidYbX17SMqp+ZL/29JN1muhfdJt2dvdH6rkFXp6xXjn3cCtWnYMDb64YBUdp/nZjgMK 4KT6oVKPd6eUUTAG9FGSWTDuwQjgr6HHp9Hn26C2lZV6Jo5YdB8TnyozZKrVmxlnCb4PFFTarAY5 tRKi1dS9uefIbRNd+bcrF+UeqST8at4e3XY3gabRc+X+K1zshTSkQz/UsUIsQtD1vP4VW70AHt+S g42YxgptzfhXM7KhblcNWMp4U0t9JV1AoH8AbTLCOQ0KZW5kc3RyZWFtDQplbmRvYmoNCjEyOSAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjU+Pg0Kc3RyZWFtDQp4nF2QwWrD MAyG734KHbtDcbpLewiBrWOQQ7uybA/g2EpmWGSjOIe8/WQvdDCBDfL/f+K39Ll9ackn0DcOtsME gyfHOIeFLUKPoyd1qMB5m7au3HYyUWmBu3VOOLU0BFXXoN9FnBOvsHtyoccHpd/YIXsaYfd57qTv lhi/cUJKUKmmAYeDDLqYeDUTgi7YvnWi+7TuhflzfKwR4bH0h98wNjico7HIhkZUdSXVQP0q1Sgk 90/fqH6wX4az+3jK7ur5WNzbe+by9+6h7MIsecoOSpAcwRPe1xRDzFQ+PxQhb1ANCmVuZHN0cmVh bQ0KZW5kb2JqDQoxMzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA5NzUv TGVuZ3RoMSAyMzE0OD4+DQpzdHJlYW0NCnic7HsJXBTH82/NzC67XLIcIqcMLqDcu4hyyo0Xigio oEZZlgVWgd2wC4gagyReeJFDjeaQeMQr0cUTY1RMTKJGExMNv8TbSNQYrxiPGIX51/QuiCb5hc/v w3t5v/dej/Od6uruqq7q6p7udQAKAOwQBMAmZQwZ9H1AgCtArAOAa9awzIzBQFGNWKjHWgdHZASH ZL9/SwxArcf86NFJw7Mqcl9oBhCG431dWazQ3v7g3hsA7guwToKyXM/6HXw0C6A3X0eQry0ofi7y KgPQ8zjmVxYodFpwBnPUJ0B5koKiyvwzfasPAgRcxfaRhXnFUwYOk58BsPTCThYWqhR5JzfGzcOy AKzfn2fY1DEDMJ+Hea/CYv0UKw9qBwCNWVpfpFEq5KHyUIAgbE9VFyumaGlH4U9Iz8UKbImiWHVR kjYZIBjtsYnWanR6zgtQVkwzX64tVWlHb1gbi6K1AIwOeF8JAfTZXiMm2kTfE7ujKzCtHvxRFP88 MChCyHGtMeIrYkvMWpL6fMKn2LI1BnF066bHQeIr7SVtaSrhNKI3aJKnQQLBMAqpm8KVRhmCY1Qt ahcLVwj7Ytbb+GTqIJ+2s2KEQoqmRGa0UPSMZMgcnshC3G329i7hgtaBVF+xJfVxVXup4BgUEOJ3 Y57eCM3PSvj/6b83MZth0j/dhz9JjSKKgiX/gOK8rhNFAUMJGQbnHUWmsxO5fhNzIAYx14rrmjmi BVggWoIlohVYcS1gDdaI3aAbog3YcI9xrksQbcEW0Q7sEO3BHtEBHBC7gyP3CBwJ9oAeiKiH+x3X CmdEF3BBdAVX7iG4gRuiO/RETk/Eh+ABHogssIie4InYC3ohSkHK/QZe4IXoDT6IPgR7Q2/uAfSB Poi+4IvoB36I/uDP3YcACEAMhCDEIAhGDCYoAxl3D+QgRwyBEMS+0Je7C6EQinQ/6I90fwhDDCMY DuGIERDB/QqREIkYBVGI0RDN3YEBEIMYA7GIsRDH/QJxiHcgHuIREyABMRESkZ8ESYjJMBBxIAzi bsMgGIw4mOAQGII4FIYipkAK4jAYhjgcUrlbkAojEEdAGmIajORuwkiC6ZCOmAEZiJmQiTgKRnM3 YDSMQRwDWYhZkI2YTXAsjOWuwzgYhzgexiM+BxMQJ8BE7meYCDmIOaBAVCBeg1zIRVoJSsQ8yEOO CvIR86EAsQAKuZ+gENSIapiEOAnxKkyGyYhFUIRYDCXcFSgBDdIa0CJq4XnkPA+liKUEdaBD1IMe sQzKuctQDhWIFTAFcQpUIlbCVMSpMI37EaYRnA7TEV+AGYgz4EXEF6GKa4YqmIk4E6oRq+El7hK8 RPBleBlxFsxGnA1zEOfAXMS5MI/7AeZBDWINzEecj3gRFsACxIWwEHERLOYuwGKoRayFV5DzCryK 9KvwGuJr8Dri64jncZlYgrgUliEugze4c/AGLEdcDisQV8CbiG/CW9xZeAvxHLwNbyP9DqxEeiXU IV0H7yK+C6sQV8Fq7gyshjWIa2At4lqC78E6xHWwHnE9bEDcABu507ARNiFugve5U/A+fID0B4in YDNsQdwCBkQD1HPfQz1sRdwK2xC3wXbE7bCD+w52wE7EnbALcRc0IDbAbsTd8CH3L/gQ9iDugY8Q P4K9XBPshX2I+2A/cvZDI9KNcADxAHyM+DF8wn0Ln8BBxIPwKeKn8Bl3Ej6DzxE/h0PIOQSHkT4M RxCPwBeIX8BRxKNwDPEYfIn4JRznTsBXBI/D14hfwzfcN/ANnEA8AScRT8K33NfwLTQh3QTfIf4L 8Wv4Dr5H/B5OIZ6C09xxOA1nEM/AWcSzcI77Cs7BBcTzcBHxAuKXcBF+QPoHuIR4CZqR0ww/Iv4I lxEvw1XuGFyBnxCvEvwJrnFH4Rr8jPgzXEe8DjcQb8BNxJtwG/EW/MJ9AbfhDtK/ELwDvyLnV7iL eBfucUfgHtxH+j78hvQDeIj4G/yO+BDxMO57HiH9CB4jPoYW5LRAK3cIWilA5CgKkV/bcf9rKRLx i37XvUE6nYRdJsnq/wIbrMVi3CD/EzaYdZkkG3NztEHQZfI6n7rOBomFxT9kg7jLJNkSG7ouNjuf us4Ge0tLtKHrxrXzybzLJHW3tsYZ/U/YYNFlkpy6dUMbum5cO58su0ySq0SCNnTduHY+WXeZJHdb W1yV/rttYO3t0Yaui83Op25dJsnTwQFt6LrY7Hyy6TJJ3o6O+Hb4J2yw7TJJfs7OaEPXjWvnk32X SQpyc8O3wz9hg0OXSQrp2RNtkHSZvM6nHl0mqT/LgqgLY7PzyanLJEVKpWiDXZfJ63xy7TJJiX36 4E6je5fJ63zy6DJJKYGB+JbuunHtfOrVZZIyQkLwLe3SZfI6n3y6TNL4sDB8w7l3mbzOJ78uk5QX HQ1WXRibnU9BXSmMNv3PoIPx5w0KA4syg47/kQh/+L9DPv9PHML/Pk3pMkkC6AP8TxcCtJa+7Xl7 F8cBGJ82l2wOPPFJXFxmbMyA6KjIiPCwfqF9Q+Sy4KDAAH8/3z69fby9pL08WY+e7m6uLs5OPRy7 O9jb2UpsullbWVqYi0VmQgFDUxCQLB2Ywxp8cgwCH+ngwYF8XqpAhqIDI8fAImvg03UMbA6pxj5d Mw5r5j9TM85YM669JiVhoyE6MIBNlrKGY0lStoEaOzIL6YVJ0mzWcIPQwwkt8CEZa8x4emILNtmp MIk1UDlssmFgeWFNck4Syqu3tEiUJqosAgOg3sISSUukDD2k2nqqRwxFCLpHcmQ9DWJr7JXBRZqU bHCWJvFdMDDeyYo8Q9rIrOQkV0/P7MAAA5WolOYaQJpgsPEnVSCRqDGYJRpERA2r5s2B+Wx9QGPN ggYJ5Ob4W+VJ8xTjswyMIpvXYeuPepMMPaY2Oz3JonC7xKw5HUtdmZpkJzXLZ2tq5rCGupFZHUs9 eczORhnYlvYemFMzEFUvQC+mZLCojZ6VnWWgZqFKlreEt8pon0qazHNyJrEGc2mCtLBmUg6OjUuN AdIrPbe6uMTt5i6ASzJbk5kl9TTEukqzFUlu9Q5Qk165zTmOdX66JDCgXmJrdGx9NxsTYWXdkVC1 lxGKVOeplPR2z1J8j6RDMCIMrJLFnmRJ0aZwHlThUKMMx2qYsilsZcjDEVEbzBNzaiSRPJ9vbxB6 S6RszT3ACJDeuP40R2HimHlL7gFP8nHSHmtY3kYb/P0Nfn58iIgScUyxjzEk3y8woLyBjpdqJSw+ 0H2Qhr5VZEcGo/s9PfkBnt8QB7mYMVSNzDLmWch13Qpxwf7ZBjqHL2lsK+k+ii+paitpb54jxUje TqZxd4PYp/2fjcTRPrkw0kA5/ptilbE8JUOaMnJsFptck2PybUrmUzljeXh7mYky2CdmMa60iaJd GVKKQTm+vTKfybIyCLzxnxkJ6rwGkRijknAodqBBkjPYiNkWnp6dbNTA3eZbkceTZqZuGiL9n85H PZV/qntWNQx2WOBDp2SOramxeKoMJ3hCvZSaO7I+jpqbMTZrtwSAnZuZtZWm6MSchOx6LyzL2s3i 0km4dDuXz7F8DlIoDNittJgUue6OA6gipQLCIHllAwWEJ27jUaBsoI08CeFhCoT6TLt4B7o3Xj60 D2goR6w3keAIgrEEg3mkg7cGe3g00EFb6/hHwFZ3X3x4xVledPGQ97bziO7N53vERRX5elzY6Oxx Ee9NvUM85kaHeLyEdzDe5Zjn6/Xe6Ouh6a0p1szWzBGEAR7qAexsxXEN1KWdoxzMHczDahuo/XER otq9otptotoCUW2eqHaMqHagqLa/qDZIVOsvqvUW1XqJHMR2Yom4m9hKbCEWi83EAjEtBrFDA3ch zp9/FzuYSfiHmYBHAaElNI/8hz0YwDQlpmEoGOyZFDolI4FKMTQqISWXNdzPkDZQFjiyQmkCZbBL gZTMBCdDuH9Kg4hLN4T5pxhEaeOy6ilqUTZyDfRc9HhmVgPF8axZrvwiuhsoipu10NX0zM4Gx/JY p1i7GNuIgUl/Ajkm9H+SnPw7ppS0yo/AgyrD45IHpd8m8nhNxHMzkFtLuLU8t5ZwndwNS1Mysgwb 3bMNITzBuWdT2+J3xE3j190cabIK7xzD/PJCJ0NVLsvWx+0wLcg+ObnKQv6pUBl2SFVJhjhpElsf P+1PiqfxxfHSpHqYlpyZVT8tTpW0NT4uPlmqSMreDalUbr3foqfUzWtTtxv8qNw/SmygcnmRfrzG 1EV/onERX5zKa1zEa1zEa0yNSyUak9X8AKZl1YshIRsnO3luoy0tcCxyXD2zExwl2hgyMFGeTjNc PxTwH85Z4tpnhe9Ra7z5osD4wHi+CAOGL+rGv2JNRU4zojxdP6TWm4okyLaVJoB/mf8zSccncEpW J/E39mQ310hXbbXzCPHP9gfhcyAXDgMPvN2Y1/lDKHfRdDe3ZnM3hJNB2jqJO9Ob/9lsu+k2JgV4 wwTwxYD9GG7DPsoP0qCROw5KyKIrIBD5i2EXNMI5SII8DHEXajqw3FuwAI8nL0EdRAhcuB0wDK6K bcARvCCS0uAurjsUwDvUGRgCKSgjCgbBPChFHIn8B1Q4llB4qHoOtb8Ob8I++BLOgzNKDIImSkQ9 4PZAImRgH6bBbjgnTBDOB3t4BdbBBjgAP1JB1BrqGnOT28Ed5X7GVr4gh/4wjv/yAl6Fd7HeOviC ljKrORduGreeOwRu2PtNaPUB+BR13adYajSlpN9jKlt/50q4TegHK+yzF/+tCsSjNamgh7VYswke UeZ4VeM6GUsrW225HvxMARb8sX+joBhmwFxYiFasgJWwBa5SsVQhdYy6SVvTVfR+YZooVZRqvr/l W24Qd5//Ogg8sbdjYDLunGfwX0LAUmz5Luo6iNdtaKH6U1FUDDWESqcWU7OptdRvtD99mn7EdGNs mAAmm8lhpjM/MA/FwpYRrctaj3Np3BT0JS5H6E9v9FoSZMJ40IIOKmA6VGHvFuFVi97bhJcB/bkf r0/gLFzC6zJchesUTQnRRgvKDy8ZXlFUHDWUGkVNpAooHbWM2kk1UPuoT6lr1F06lO5PR9Aj6HS6 gNbSerqWNtD19H66mf4VexnJJDM65kVmE/Mxc4j5hjmFUT9UoBCoBWWC1wUGwbeC24K7glYhCKV4 BQkVwrqWVa0preM4Hy6Ky+UWcrV4XUUf9+S/WoLeaE8ajqqS/3oGrdLC83hVou9moUVL4R30He+9 ndAAH2GUfsx/KwHH4RTadxZ+4L8GQOfw9nWnPKlASo7+HUANwmssjlM5NZ2qohZRK9DP9dQOvBqp M2hlK1o4ms6mJ9Dl9HR6Ib2MfpPeTTfSTTgSHGOGI+HEDGJSmDHMOGYCo2eWMm8wy5l3mJVMA9PI fCagBZGCNEGp4CVBrWCVYIvgc8EJwRmhTBglrMHLINwh3Cu8bGZn5moWapZh1iAyE1eKr4hbYRt8 DvWw49mjETWXklD18AF1hREwVfRROou2pJuoasFXVG8cgWgKhIugBO5gD92pb+gwagyjpMai/6qp fGocvM24MauYoXBUWEJlMGlUHmQIlsFj4SegENbQWxlaWMO0UA/pTVAIi+jJLRu4bKobZFBr6Pcw Yl6AaPAVuEATHSHYTXnTvvR+0WaqAWJEZkwEEym2wdwa5hJ2M0NsQ10DBfMDzp+LOLfS6fdwTbhM nRGNwN61MFuwzgsQQ61ptYUNwmw6h3Kj11DDWl5q+Y55k1tJOdM/ALTYtsTTiRhxo7iN9D64Bcta HwouwD76NIzCVUNJZs4dnHsVuNKMhse0Nc6nDFxHtLg2FeAxskAIeLIWQVRcTzOREk97QoGSAQsz oZJhaBdzkUBJgbPYN9zJP1VyN3p4S3Sq5H70cElLNMRGt0Tzt1zW19bT1tvT1rNAAI9ZpvFxnBAe AStoJJ8dc83wA66nVuAEYbuAsrYX4Qg1UDO2O8olli4NlHuclUWotVwQaj/RWbXAyV9yv7mluRli W+5Hx1K2dhERcpm9lPHpF9q/bwgeUEX2DmbSXqbsyz5ZZgnBsnghHR8UGB8fGBRPFTD+/bonDhs2 zNnv0SdB8fFBQXFxxl8ETtCnmc1gCZ67gaG2x3UzF4GLtZmzlfUtT948/9RmyWWIHX5DLqM6qKBP Ny17o6npjWVNdLzx2USCLMR0lf8/cr39f9jFp1C6vP13jvHQ9jsQv7arTDSNkT3LRDMY+eNNtKBD HSHG5gITbQZieMNEi/EdWmeizfE9tM1EW1AsnDTRlhBC3TXRVtAXN/BG2ppaRmeb6G4QxNzmf70S MNgfK0FPQgv5L9oFQYQ2I/wYQosIfyihxYQeS2j+P28bBJNMNAVWwlATTUM3od5EM5Au7GWiBR3q CMFJWG2izUAiXGGixeAj3GiizSFBeNxEW9BxZnYm2hLyxOkm2gryxTtNtDXdbO5morvBeCsgtEUH G/mPMCRW4wlt1YHfjaetiggt4ftvNZ3Q9kjbWdUQ2qFD/e7ED0basQPfmbR9i9CuRJdRpnuHOh4d aC9S32hvIKEbeFrcoc/iDvKtOvCtTP3PrNSq8hVKFbuBzSxUscM1JRo9sthETalWU6rQqzUlrLZI GcQmKfSKf1cpvqiITVcXFOp1bLpKpyotV+W11YvMqCzO1RSxkeWqUh1fVx4UJmP7DFcrSzU6Tb7e N11VUFakKB1tKu4XJJMZmwzPbNeFHdUUlCq0hZUdWSo2qVRRoS4pYEfk56vRDHlEeERmoVrH5mtK 9KwSQaEu0bGZ6mKVjk1VVbDpmmJFCTuoVKWazCoVWrVeUaRjFSV5bJGmQlWqVOhUAWy+uqCsVGVk 5yp0aiWrLStR6suMluo1BSp9oaqUrVDrC1kFKikqUilJkSafLVZgGYJaqShideqCEqOYAlWJqhQ5 2jJ0mU7FpqlZZaGiVKHUo9FBLDsKefmaUlan0ut5c54SwwvQKdWqEr0ajWQrNKWTCU+hI+qLtUVo Hpqr17DYitUR3/EuKMNK6hJWp8faitI84hRdUKFer40MDq6oqAgqNvkyCKUEF+qLi4KL9fwfzQQX 6yYaxQTx3E62qFAVIVdFmqSOyBwycEhifOaQEansiIHssCGJyakZyWz8oPTk5OHJqZnWFtYWnaqU rSlDd1SyZegiffvQou1aVWmxWq9X4SBVEsOTRw2LJ17kM9pSTV6ZUs/bX1GoxtPek7b4VJcoi8ry sCn6LE+t0xahAt6l2lK1KW7QoTgubco1JUWVbB+1L6sqzuVbPZFV0lb7T7tEqufxI4oBpS9Vkzjp oB6bt8uKIj3oo0YtelUxP7NK1ag1T1NRUqRRdFSKnVYYu4phiPZqSDxqyvTaMj2bpyrnZwLWKVQV aZ+x6N+OJJ8LLsLGJTrjIOI5SIPntmLcXxXhHq4Sc7lQSVnju2YS5n/iv1FvL8/AM5MCOXmIpZDH rGDqmb3Mfrx3Mx8y7+O5pBJ3aSrcyStwH6fCM9QGvDNx18nTw1ESL01vqsXiWYaXrSWoQL6a1GCR U4Ttg5BKInzFfywpnv/eHp/pyCnA1no8NfE5FT5VWLccMe8P8iLR0kq0ORd5fOtIUq8U27TJlWPv wkCGVB9srcbelmKJDu98lOJLNBRAGbbmPTX6mdb9sLUMr45ahqN1f7TL6FENyiolO+BCzP9VLRXx F1+vAjWVYBsWRmB/8kn/VKTXERCON+9HNfFEPpGlR0ppohSkrY5IVWPvVIROxWcF8ZyGxAJvxSDU pcJrMmnN905N2heRFsY4YTGnwZa8/Xwd3usBRK+a+KfUJL+tdi6pw/eXj4Iy5CpRZtlTY6on/lDh s5DIZYm9fI4lkaIk/izCMmWHVvzIsKTvxnbFJplK0mOWaC0wWd7WG15LCdFhrKMlPdaSkeb9mYZt eH2FZJQVRJ9xpPnYZWGUqV4+iUuW5PREq3F0/ro3bT3QIUdNesGX5ps8U0HkTe5QT2Hqt9H6YjKD jKNnHF3eZ6xJFy/1Sdy1RUGZSZKaeEv39EzvECm8bYXECi3Oi2C8KsgVhBKfjssgU1+CSf1i1BWM qMc6CtIzPqeDiU/1Jqi9btfq4COwyFRX1UFLKs6QTBgCA/FOxNWCp0cgl585AxGHEX4ycjIQ+fVk EM6BZLyGE24mWIMFubOJD41jWonPMtPY6/9krhlHS0tipZjErp6sQ3z8V3YYp2SMoGGo80kEtZVo yXqTh1qURKJx1CqILiWZCX+m15hXk1lVhG3zTFqN0ZFHyrVkzarsEFu8LvUzq4QxroxR/qzlfI0i QvXBdr74VJHxbdP1Z/0q+YPsznvpifS89pllXFf0pOdPVoE/t15tWlWe7VdUBx/wlhht0RN9bW8a Xr7R1jyyzpWQ9U7xl5YaPa14yqvGNUxjwierGu9VPVlz9ES+Ct9CbSu5UU4hiWrt34zRfz6T2sqC yWqiJBJ1z8yftt2BgtRpy18kuwnVU7sL1VP7B7KuCHoK5IIUwSDBAMQIrK1AG3nv8T2L5/8OjqxL fCvTn4pwnn/555/8Z9t4GgOK40htilzkjO2aBO0fAbpGy6pdw83M/WYPnv3AmhLRddWuvsjypilK bikzNxP6d2NoFyHIFGYW/maUgKoOoylBXYZspCygA8dtVc8qN/7PHfEagQGoIwuYijg+hr9knh2E CRwOD0oIyB3Wv+k6921TaNW9re/0+WJSXXX387Jq5iDegXUMTdG0ZNB+5yXnF6YPTHxwuniwtXyN zLq9q5QQOzVzPukkM0pgZk+PjZd3l9nzGbG91RjcfqpKS9hEhVYld5DZ8WyRvWVSWWmuoqRcjUcY uQ1KQ66FvVlmoaJCr5K7y1x5hqW9g5HBJqpKyRGEHITkHjJ3vpixdzQVk1OWXlGs5fe7ifGynj2s ZX3lIbJQGUlje1jL+WzfkL79IvpFjJVldOjsqAx5D1l3o/5ueBJUZ+DZKYAdUqIMkvvLfI2KerUV EFVsRpuuDDxv4rZVxyutpnp19AolBKaasgHkW9DVFAUbjmxdc/QYu8XihXnvzym7vT31l/MHbPYX KPauznM7tefhkb6bXpbNy5qx4PTks/3fsdn/9fUpdyrem6GJ3v/aFusPC+8WvX5kb3rgpsED7u38 9rmJrvTK34Mn91zzYPWK91wO0RdfHJZ+qVvO9Ti3Gbutz8V+vv38nL0Tp06SBzHLZ9qvH8R+KddZ jwk8NiW07xK75Xa7zxUGb7x86eOaBX6fzPeck7/3pawxmrL90Rt95jx3RNI9euXL1zIPWJQcbP10 6NndIttlvaafjun9dc8p11fKD/9yuZfz6YPbBiWucJlY17O2ecK9m9N/eWFTLrX43nDLc8d7jV6/ 5NjmueWbb35o/Wvz8O/rHhXWbXaI2jbnwB6awcBfPfO0bOZ3slAzMUasUCiiKEEfmY/Mqy0vo2Y7 mY4KGqVOG4QndzV/mOXPCiR23O0pihOIZWb4oCmQxfM8D0GkLFzWvy60LmS2zNRcWVr0VOtgY6x0 DJXE+CCsRSLV3VtgJbNo6wUjlnXjmTa8Lv7THTPsIeZtBRiZa5xlPdrim7G3ysyIx0ALD5QH9uv7 zKxgZs6EoZMfXsv6OMlNPq9yuf/S/dXvU01uw44ZarJKzot9V084dOQ1+yuCdOtbg3oHQ7ih+fBr qStO9srt/iA2zHOEVl71y/zwOduuXl0GrV+NWprq9c2G3qlTN+9SxP/q9+WVw99POLvHf1bMjrd3 fH9xDLdv+6cz7n1l9c7tZa3+J6LSXV3Dez+IHYpzmJNV01dM89j6J//bJ7/znesUIjSfsKJ87rPz +H/JzPjjdJSFd5yOYzqpNFgWaFTq83dK+TJV6d9Oya1pfQafPVE49WWnpPyy52YcbFip9OEGJL41 3TZc4j1K931Zb3VL6m52/AmLh3WufjdGjfZUfNfzdPNHfSd/fuvs6jDVItfXrHZm9Bw/Pb/fRGFN cmt56vmMqlUz2bc3zx2/SvzgR9nDm73ChiVYfHn+M4+DTaN+mhm7I311wEZq6p1VGxf2a115+blJ wpUDJl/av7Sx9WjOw7grorqkn2eOLFnrd2dnjaTPjcVnzOpmp62YNlRsLXM/Inln8oOfsjYLNsQt 39rn6mLH96MvZWhSTvR7e4cmz33b0oA9A65U/lw89aHjZZ8PttxanrErLmBJQ+XG1pPpm3z1MxKu R/RcNcnxcvYer8LvoCpRMqdqsmlKHpHN/Pw/nJJW7VOSxqNjX+NkDJD5yfrU+dR5ze71V5NRr9MF KhVk+jmS6ceL+Dcz0KyxUzMw9NkZyI/ynCnaU6npFDvuQuXhatnBlt3OS/e+Ap/sPXbss7vdvuMe Dm/smyuz/fSe3vXkq+cmvsXa109P3pd27KUrVT1eWtf7tQL7gY+ONLwRzxx9c+Q44fwX12t+dU1z 9Qq6o15Y1OvBniOOS25Y6RsLK77/eXnunAO62t/m6adKN61+Y9qy+geLfZ8fHlTmOjj+1O0d1mxm U0XdsmqlusX8q5rbZXvM3/z+oe0onxWKkH1TacO02ftWfTK/V8CUr/uVf/SqbvzD3ZeHdbeQHm3+ 5mRo0JC47tE2OVO9Plubf2vpV9qfY67ctZ5x5uvpq8ufVx94a8QgWT/P+lVbXHKj/b9ftNFPNO07 p23jp/3w9lpNa/S8D2TVAjtcAn43LgE2cADmR0fPtf065r7y+vm4jh4T4AqgbZvblva9EjXaylL+ t1W2j9KXlUdEhLHtP56SH2GD5D1lbsbK3Z8uMf08K/eUeRiHyelJebpGo2fjy/SFmlK1vpJfHiLC ZHK5TBZmWh5CZPKQvnJT9h/o0d++yum9B7SXo+6kuvZZuWzKBNm1VRsWek/8rXXJsNW7Wt9excZM H7nqzVWLc0Imf52QV3nz/fLDmafu/PzWbLfFK1/O3/bp5Km50ib36HM21KtXlx7cH5i/YkWhz/Lj kQH7rXZk+RwYeMUiJnxpwIY+EeuvD3kp4dLLNntWFI1SvF89/d2cwIphPy3fnhe1Is1NLvZyWLnh yiv+TpcHvKF0yMkSqla6h6XPebDu1uv0Z64n9o9K3javan/k9czXUze3rJtarE/d4nR0qXkfTxhT m6MO25NiJ4oezY17tCbfQvzeNzNHj7m1M2qC48wKwan7+zZXLWk1HHuxaZ1L6fjoIx/dFq/uJdtm NuvwNrbCftZ507qxXjZzrWzmKn5eUoKZK2Qzl1VJxh3X3lKXviMdOcNh6/BF3Bfvlv7vH7/qv4lx siosuWrZuPDXZU79bjRQXt9V2P46Pidk5TuWX8QIX5m7+HDkZc87t8e8FrCjbtCh3FuP/3U0Kmrs hv6Z6lav4tjDRzeeE04/K184YKVEO2lPq90IJ3Xj4+OJl2zHsiOu5U7bstH5kH+Yd+A+1bt2Nd42 ytUPMt0eeh5u6v5r+vsliSGiluoev/1YUGQ98v7eX9I/33vloOwxKzef677E12X4t+702l+qLjDb x92tP3tozE3VkM/TM3duZ/rYcbVNt8WLZzQs+3RTWEDz1Ob1FZfK6+D4pNgD3/SvuRBvt77fJNdJ p/tdPOkmaF6fLDg0tm94yXA369xdFqsWnPg2M3bgMbdR72lP20XOea1s5bpv6nBV+AQ3B1tMG4NJ lstHNIL7JttTB+l383t/2HZIcP+nlgRZf9wvhMrDQkPlofwGHpf4kP5tS8LM957eMtjLbI3HDYsx Cl0hbgX0qEdCXiF42BClq/KKNSV5bT2z+Kue/ZWZIaj0D2ZKZZ5GM1w6luSpyOaD342kkUMB+8eV xJpfScRkJfnkKLvwo/NcTNrNqR+f9PK+X/6lJ3fMb3Tqkbd2VW/tVxkIB9eLv1Ue3rX2/k8HDjTV L1i6SvS7zc7q9BU/V3+2V/Lp+sabk19elOG6J+33PGreAceT1YUQNyXpnl146iPlyAu/D9j9Y1j9 eaVIGvV8XOigu5M3D7zXW9ez1xcJzj1H7kxfcWL1cfvPnGOfNyu+s8QzaWLCjcbDy/PYhgOhj1cl XZ621T244b1zd989/6anTWuWPH5U+IwtWVear2dXem964BdsGxs+JSbhxXWFzTN6Ffa4PPTVg1OS 0ge9O+Llea+92Vgw7Zr5o9nMC/eXPx/tvy7/jaPnA3/wp11sQger7kXbbflljpu7T7rmKMYes7qa 8kN/+PzZPpz571he7MzMTQfw7ri+0AwDAnJEde8mcBQ4eP/mn/LcodLMD368X+fXw/HRgYcZM2XO 7U0caIFVTwvIgDI8ridCvMySbHzIuWOgzKZ9gyWUMfjoMC/JMqa8dOFXYYPhmqVl6NfV8ph5ucnf itc9VKgOBTG/hw+O/+p/tvWTevPlx0fDgldslTx35tnHBT/DtnlMcVd5ulL+TtWVb2JVQrc/T5B+ wxG7uXXCzp6I3TJnpl6eOsX4y8R7/ztmx3l7BliqWSlIh5j/qY0RnXz4jkzfh8Qgm6fsb9PeV77p PxeenDpVwnNB1f3U7ffV1v07IbTt2KIzx+K7Cz6fur26KY/9TqrkzhXf2g5xOs34qLYms2rjQe3l G9Lkl65v58ieLrxjg9lMOdbFwhaLD6wxsNuleN1g2akkIZn14b1PP1YJ7oqz4TH/OPngpA4/lijW mOPnr628+bB2YoX67y15S/vZjCM2xmkJ8hs0sRoDizJpSDHGleg27zR4y0oqxgjFUCkyEGWfpYmx iRmot2QObBsBuaYgrkEJTfwBlWfGIU+wSXS2cZrFuphFnw7ev3dh9dTeazZz5bsPx7bpxX7YWPR1 9ZqOrK23NipVc584sdR7YpyS8MufX5Xnbv2SV7bu/bslNsePHIiMsV+9udhYbVlSY2LlwqQveR1T L+TdPT7/0pJAwbLEXQVdqQuniXUuj2284JL29HbYPIdTf+6Uqei5GDA8vVZbPVXwaoTs4hf+3Cc7 7iy6Fjwz51TyqZlZsybF+fgKvtC/HB0dFx+0uFh36e4WV94eSdGy0xy3Zi0rEH3h+ybzb+ym7P63 moHmFt3H3DxFpwTM2PAlY8n1e5yF6SXzyntkW7Onv3oe73rmwbNC3ovJDJOrDWf0cW8R3rv5wruP 9xXfrUxIfGfubHsY0iRqYpwEDJE+jL4LojB4dzN7ZWnwWf930n6SbHKL56w+P+UvjpJvJUhUmaVx oUHjvAaspcjCkiUDUf5hNha8IR0/FwMnA4cFdgts2qyQOn65MHPAPb+C7EyQqD50mrxYH5QBQOkf mPaNwB1Cf6SeqLOBo4E9vCfK1GaMPI+MaW5qEaaBJdj6hBY330+1mB0zQyQ2JC/zPtOJ55t/Xz7k u1Z/dX0I7y2jbT+ynvH+VpQqt1uaUbVlal1XzCfnI82zU2s7AgJrmkS+NhdfX7Qv5hRTwTm1HPE9 QSJLOw9sf7LwzMLSuRMLbaUPhDGEbf3RonYrzvj3NdWquFm3lv3+8slRak2o21qPOxMthCM4PT9+ NmyX38PSFy2UyvySO/DCQp6umXtvHlxxgUNUVXHrtvBOmYvRbaZLT/1d1f5mpbn9dufsxwofXffU rXv5MXTTQo89qfuCTW6efMGWzMJWkRfw32P37FfOUe2313I1fI08qvPkaX2011OjyndKrZN4dDcH RB875BARsfrS2cf6B8++yZ1vXmnYxHIaWGweZ2JkNGjcOmQKR5QCHjGMvaDxhYEIvELVYDRkZ2YF D7aDqllo1HMyG/Igj5wDnY7gcRvyGSDLihooIzSyGALzrdo9ueCzvyIYezSveOibuySf+r/Tx6AI SQuPYYpB0gKLBjMsM+8KDG7wuRYcs+4L1RpUcKbtEvgaJPTWJEsTI8Mpgc9F4utO/6ncOnODkrf2 3BlnOmavZfxSnyG1it94q+LVLPX+Q/Z+05+tEas8a7K1l/sAs+WnqSqfmPUjG1syJgS1W+UHPp6x 7PAuk2jb5GO/9YItKhxs1vn9esC+6vTrg+sXnf/qHjCvQ8hm/nTFlguzg99EWDjIMk5VthYU/vfG cy7PlT37X848Jd28/Vx3Qfynmm/+XNz7xXJuKyqlXNU2D3Rb88b9ziSLAwIbVxecnTirc7v8Ja8O g1PbPu+Pfs3JleLZzPCO6+lh6aO98u9m2Ndba5/T9n1dGnrrnNkTTlmF+XafYmKZOzkkqwsyTwXa rmy8F3lgQ5fkjiz/EyJ/u2dM2557lXWPCcvCJmCzqInxNyLG2AybGN8AhV6Aknc6TQY1sQyl8rBx QBzABCxlFkQaSCCnPW7E1A4jMOnBZVgN+UH1PbCCNzIC7Sk1iQKWv0hJT4hFwG+m0vat97S6ZBIM nvz8N+0aliSQHezi8eCCnvPpv7F5vldnvXU6Msd6e5hahU9Cyipv9datoT5XRZ1b5v4qcKxydz/y uPvy0V3/3x66dPx/OGNzxcaXtxXrM012Oeovt6vaYjqXdc6RHX4i5gztL637VpWmaQuVBYU2zdA/ nsyxaX/QoXv7PnAt/HuI6fMXlVsbnRNvsTHn//OeMe9j8/o95psUnOdve/Z4/5Hn5gZHPP/WaH5S Kr5vMH+t1vOrbRKG2xWOdh4KcLZ9lWpslRXCYOe+qktrZrC0wdJXKYn5y0K3L9NW5F/jfe/6/2a2 pfLlC3znfPWV2sosfvFnufiJCQKt9hvTz3UuD0pW/vfbMmpubIPB+RDbdxu2f26+fWcCAAIr11QN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzEgMCBvYmoNClsgMFsgNjAwXSAgNFsgMzMzXSAgMTIwWyA0 NjBdIF0gDQplbmRvYmoNCjEzMiAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQoxMzMgMCBvYmoNClsg MjIwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA3MDUgNTc4IDAgNjQ2IDAgMzUwIDAgMCAwIDAgMCAwIDAgMCAwIDUx MyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUzNSA1OTEgMCA1OTcgNTMxIDAgMCAwIDMxNCAw IDAgMzA4IDg5MCA2MDQgNTY5IDU5NyAwIDQ2MSA0NTkgMzY1IDU5N10gDQplbmRvYmoNCjEzNCAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5Nzc3OC9MZW5ndGgxIDIwNzUwND4+ DQpzdHJlYW0NCnic7H0LWFzVtfA658x7BubFDAMD5AzDDISBGcIAAUJgAkMCITFAIDLBJEyYCZAQ QCBPm4eGJEpsNdFoqv61vf1qWvvwRKuN96+atlbtrfmurY/b9vqI1j5s9b+pt1qvMcO/9j5nhodU 03v79fa//+zNXmft19prr9feZyATYADAgkAGrcG1zSv8/jN1wJltAOm7G+uDHQ0vvlgGcFQAUN3Z WL+q4euvPvobgEO/BeCeWRFsXG54yz4IXMo5APm6Fa1r1u78JqsBuLUJWO3GFWs76wvfuCsE7N1f BRi1rlnrK21/4mwzAPMzXLWnd3t4JOVBUxGAMw+AvaN35zi/vrbzOYBKbGOv2jLSt/3VnM6dAK7v Aug6+sJjI5AGTlyfzDf0De7Z8oA+dxNA9WcAbC/1R8ORNwaX7Uf612B/RT82qL+j0WP9dqzn9W8f 3923Rvk+0q4E4N/eFh0dynjMGgXY/gL2nxsc7g0fW3zEALC2AyBz//bw7hHjMd1rOP8s9vND4e1R dfZrpQBDSM/iGBkeG5+6C+5Bfmj/yGh05Ic18mUApUhDkQVEtvL3fqD2eP2b9DXvgVYFJD3661NL yfPp5f0Tf1pw+R7NJVUPjlUDC2LCecq7YlUAWg3236a5RCnNSFwlaUmphfWoN5JYMIAPtmDPT3Ud 4hDZs+x3QQ4q+V1yP9bvEZ/Mn2ALE2P1rEzFyWUKjpVdAHYqALJNcdqr1/I88Ih8UVEVq2LCyruY p3lg7qVEL8g7yU6BkwfhccrqD8QyM8m/DD2ye6GH4kXQRxl8VqzHk+KHsAHmSTI7dMzXnkx/v0nW BDWy/w1eij+Nuq+D7pn97AQ0J/BdUK1cAM2yF7B8DrpxfA1p585AM/cNaGPfBhe2Bf6mG0imZEqm ZPoflNhvwUP/3TwkUzIlUzL9v5S4MOz77+YhmZIpmZIpmZIpmZIpmZIpmZIpmZIpmZIpmZIpmf6m iZX+AiMNOIKxAArmbdryh7l/m4F1TvpLDu5TqIozOea3XMVfgUclkD8v0WDRSS2GGb3WT5h5CCYQ HoGjUv0YhZ+DW+BWOA4nEL8dTsIdcOdfgcu/Tfo0yf9lSYZ7J3/1wkt/baOGFMiFRlgBzbAa1sJm iMIAjMAO+OLUVGIED8HEiDBEcMQgjNIRzNSHU+8DTP0gnpGalKd6E/aU+ed3J1pMYH00smnjhmu6 14e6OjvaV69qWdnctGJ5sKF+WaCudmnNkuqqysUV5WX+0kUlPm9xkadwYUG+25XnzHXwC3Kys+yZ GbZ0qyXNbDIa9KkpOq1GrVIq5DKOZaCIsQm2hq7GrUJGQ4+gcwadBl7QXXVxtU8Ak93hNPJ+X6hY GiXIPQKYW4S01q4zEKgMCQrP3CFXCZzL8K4DJ6+2842CzIU/zpXhiFDQ3uVwGl6yJ/pDOEfIbOhy OOwC68KfZuzCn5VhPiIYWrHdYRdbmgVo7SLl7NQbldgIlY4QwvYuISdeDYXmY/JRlP25OWxexUwa zugyGoICpJ0B3RsCWMiwi5UgQI1Q4EFGDIhRauATmLR3BcYsMJbVyPLsJci0C5XzyKAxstXZGBlA iUZ6pmV6UZSog5/kJ9u7jH5EKdMtwjNtXWe0mgZnQ1SDDUAb4IxGiy1a0oAkRs4wulqGIqyusfoM C6oUFJ+JsNtIylYhcKwHEWcQ5YY95umes1Pnbp7ZBTgtjplFTGRCUDQISpEJfkAIhAU4xp8pOjd5 81kDbO7x6CLOSPiaLoEL44AzwLka+zuErJbW9diES2Hp6eeJuoMUEOXxjf38JNbJ2B6EziBR+qz2 SH+0h5gJ0+MMYp+6oeuo45xdMOGzUTB6hBQclrL3TTs32Wgb4El1cvIoL3wR2Z3R6yAQjcCGrE82 OnE1JNa4tZ6oxJdQG7XG5ghVTuBYmBcObt4q2l745rj9OyYNgu59B2oH9YMz6URJlJGerYTlrWGy zcat/OSxKN3qzXRraK9849YgKWQiWj904uz1XY39zsbpBXHjiHCuuXMdDiHDQyZOTjYSFsMR5F5k GTum+Sc+YfcwyE+DEOigD+igOsAVA+FgSGqSBqwn00hPTzAUcoh6x6GC0nVU7nXyk4Si0iWkeQyO J7HvXHFRS3tXY9BOdy+wDV1L37HZ30G8pTXRzNhwzKTvHbsoo5a1zpY20Qr646CnQ3RgNqF5HCqN p1TP2+znRfyaruXO5T2Tk8ud/PLJnsnw2amDm528wTl5RqebHGns4an7M9j+j8fswvKbQ4Khp5+p phoi5Hhie8vbWwRzWzdR1XK+PywGjjqno9LuMCbGtP65bsnn0PrRB4jPTRreRt50GJ3s/HISas5i hLALhkrisshQZxf6RC+1XwrQV9YicTvxGi7kahxYKwkLLVMyHhID26RWJOJwEH86djYAm7EiHGzr Eus8bLY/CAGfB/XYQ3rOxXssnaTnYLwnMb3HiXqztaz9FPueaduTRqeJr/JR+dPQGxHOdeAeP6gU VJWS6s0NXZydlTDWzhFM48FQViOke+hEIhOMmJMGJ/+cUzB4BHlD1zl7TYg3GDHUMTimyUM8CCPq c84fMSSOQppBYGoExkraAeMqDe9ceiV2JgyJb5zskSxt5rakwyDSP//ecIzBiduzi+ONJifZ4bM0 vElR27Wc+JXdIY5YGRJSSWwWUt+mAPm1N3TxGInQc9sowjfy/UTZAt8TpCEhZJ/ZfHbqQk+QhEBk mQyxSyaOUBTtbFsrLrpSQz+Ihn79zaH+aqQSKMQd8OW4LPWWji5JSpV2yaPIWs1kK7P7E1KMj0Hl o+M5hJLMH9nQUDNt74TmE3lLx6zajMVoX2UiMnR0Ccs9ceJifYXHPrPaNKe7Od6N4WOffS85Rlio P+Nkbmw7E2BuXLu+61ED3r9u7Oh6kGXYhp760Jk87Ot6lMdLEG1lSStpJBWeVKCFQWoPsio63v5o AOAg7ZXRBlrvPcsAbVPF2xjoPcuKbYZ4G4ttMrEtQNvEW0WjrR9F0OVEpUeEQGvXZ0L9kz0hImyw igaIlu2sBYF11p5hWIVO0Dij9YLWWU/a60h7ndiuIO1KZz2aPzoHT1x9sseJ7o8BuAvsTIiYMDEX 1sWfnZrCCHoeI69DULiuwYIBVu0J8WjFK3HcClJ6sHmFcLA3TPggZsqRWN7cGxJUCYI4pFlQIwW1 RAFHLKdzyCmAk3rRWMNOimIzOsfBkBDykEW7BggBnsf7UJOzWlC4RZpyN1nIF5o0OUvpcaJwCRrX UfJQI28kENIWO1ZxsZAoJKUOOe91YldvD4/SlkHvWjRGmZv8aOxiSxRPdZk7SovGLnWC6EHaFI2g 9pKzSklxrRcJ4o8yFBKZp7Wj0gBc2yBokSP3DFFKE1A62NVMeMGfo8gqGfo9QqbtLLQ7d6MPEqYp JSV2Cymu5jAGHHG+FluclfHJSEtFmwiNJ8VWJdm5jl5oO85OnXbuccxIxUVOPJ27iGGCHe+QAQhN zm0QujFwqua2ptDmyUlVyvwTRHmpUhJP0sg3DqCtAo9nCopR4W4OH6s0lRU/CjyT8221jVnJn2Wy 40hWHEmPI9Y4YoojxjiijyMpcUQTR9RxRBVHFHFEHkdkgbcodonCDyn8HYVvUvhLCl+n8FUKf0bh 8xSep/BZCn9E4TMUPkXhkxR+n8JzFD5G4RkKH6DwZgqPUThJ4U0UHqHwMIUTFB6i8AYKr6fwIIUH KNxP4T4K2yhspbCZwiYCfct8jBvqsKzBsgnLMJYDWG7Bci+WB7A8geWfsWhhAZMHPix1WNZg2YRl GMsBLLdguRfLA1iewKJFRToDu5nXLljTs154EcF1n7Har/tMxk9+ivjOXQi2jyAYHEawbchq3zZ0 YDRzfEeaJatvK4ItAwii/Wn2aP/hazMzxqx7GzIce7Aon05/mv3NbxnP+ENM+uNM/ks9j488fvBx 2efvYj2Bu5hNtzHHT7AevAMEDL+3Z1epe229T/dyfG+Kvoo0Fq1Y4Koy3B/dX/WFU84FtjvdhVV3 nmI8TaeYO06yHsPJukDVz08yWsEuTAjcshRGycjRnD2MQnrKpKc80DwJnmNYbsIyeVjhuf4A49m3 X+7ZP5G74MbDjOcolonDcs8hLPbFFluFxVJuMZVZ9H6LrtSiXmRRlFg4nwW8lrMMHzjYUOtw56cW 5Ov1hUzBB1OeD/5D//6fUv/4XmrJ+yUfsBc/YAo9qUUefa4zNc+pz1mQyi/Q6w1GnVqj1SmUKh0n k+uAYXUKLrJAq2/Rs1pYAkFui3qcO6r+Otyn/le9WgtaTqtfAkvUIa5bvZMb198Nd6s/r39U/QtI fZRxMLkBk97OZKfYlJkpFkN6ikmWlrJgWSrjIB8KIDRg8WGpw3IvlicYR8CtKKoprCmocdfk1eTW 8DU5NfYaW42lxlSjr1HXKGq4Gqhp9XcwgqkFWjrqBTODz7X1gt/Tcpbj24VST4ugbu3uOsMwnwth q8DeiMdihyC7EU/CDnzhWt/ddZbJIN2HMaowDAgtPYc/G/J4soUIuYYdzA4JpQS5NTuEF+bSNsHu rPfMTWPj0mPHrFbhj43CB40DYeEDfGN7H1+HPmjsEd53BsfE3sJGoagxLBRgo9sZnEWQmUMfcAFx DfIYG8Olxggm2IQ63O9cfs6oycZb2+vJm0aLEMH3BHtrd4+Q6azHSz/WKlq78f5YPzY2dgbwlnKG JUCBoLu7a1k2kwMRJhtLFpZ0LFYsJixGLHosKVg0WNRYVFgUWORYZIHVkUuRDyO/i7wZ+WXk9cir kZ9Fno+cjzwb+VHkmchTkScj34+cizwWORN5IHJz5FhkMnJT5EjkcGQicihyQ+T6yMHIgcj+yL5I W6Q10hxpinxM0FeSQv+pWfJJSAWQd4IBPBSCrHT6M0bugohPXZz6XwSKOECsXcRnJ8U+MHBLpy6y OGvqizjCeCUfxKmkQj+G2wevwjO0+XY4CP34PAXHYCn0wLWfSOS9K1lpdmJqmQqmGKPql+EmpgQd 1QY3S+2lTAF8KzFwP+yA5+ALcA8chzHoR699Fy7ADdizGYYSowh/9ZgB1oMqsUYq44U/ArDt8zDw AjyLI0zY/xxshN1wFdyBa70Mb2BfD/wO15jmtSgBJ5GPL+Lzs1geoZ2bsX6EtgkQwdUB7odRWDl7 McXjoGLHUT/Xo14uwEvYtAM6oTaxQjVTiPb/VZT7m8jZHawMXmY+hHO4xkUmFVsewR1fYF6F9ZwC ubwDLsJO5Pvl2M9ir0xdlDVjKD+tbAGixscRHJF3QAEUQQmUQUHAAhP6jCM2+0mL4c5c3Sm5xSrP ytVDXV2d4deGNw1vMr53fG8uKmHKy2rZxbVceZnbmZvKKp3lFRX+0hzWkoaVVM5iSbc4yxmjw0gK u1hhLcxLd9v1y2r5krwMdU/NTQ3Le2uz9Hk1RbzbojTdynx0WcGFP6pkfmO1ugrL8zN8/ipnS3ta XmnODTnebP/yhe7apcuLHUX5BVmKoS99Kfam7K5LW2R/+vAbyD1L/m2jvAZ9IguKYQ/e6hs6uwKO rGKu+ERWIMt+XzCL02dz2Sf0Ab3hvqBesS8/35e938LYfK+bqnyvg88DmTbDOx6w1UnYohJ7IOPP EgDbfDNCTGkOZ0lTKBX443SUo3SMZV42v5yx+ksXV5CM4kJ5Kdn+0xe+ta2suXnZY9dt/VKs2uWx KOQWj5v5kql5qKUyf5kjb8uj19fa5Z1lI3efv/6eD7rWbLGY6jXpC+tKuI2+QEGGpv5SHsfbChuH dn/z8Uu7yO9HUAaylSgDL6MTJfAopEydC6xS65pSVIYAPgwGi8rCWU4EVF6H6kRJCbCMmmO9XiWn POENeIvvC3q5HIfDyllPOAKO3PuCjhSDXm9lmZzAggUlKuv+fCKxUhRZ5vmXzuPjfOkM0RmerJuB b9q4AZ++TFp7yucxPEVkKrJU819haabsr2DJEGN0elmn0+gvrahY7E9UamWL/dwMHckCNzm8gdW/ mCgqdeivvTY11+eb+LmzxO2055huMn+0MK4ieWfs+5sa8mN8RvXS2NbqpZmXf6e2uoua6mK3zdYP aqQPve1deRR96wnJJjWZ6bb0+4I2mxPIZcyTamnCiNPK9rAcbtvjUXCKEwGPjHc6U7nUE04zG2By DhiNXs0+t2Ssf3gh8zzUSZvPTGy8yoN9HiP4ieHOWcXxyasEnGa04sxPIikJMVeB/m1CY64oL6dC c1hSWYtRma9w8mAsM5EQINtzU/qSDc29p7qW7Al1dWgsuR4WSvNSbg3uuiv2cuz1LQ//8oZ/lZfE 3uzoLt4T+9OPH4hNfW5gzL1qGZ+WUl+vd9dVxY7mNDUzncz6R5i0b64B0bLZ7dS7OyQ5WtLTLGn3 BS2cQq1S3xdUwf7U1Jxso4mpslF3Rq7RMSVx6OcOts0aEHKl5XDplhm2gNviLCwj06UXZF/+97jm 2ZSF+WmqS84ad6ZZWS8pe1NJ7UKbpr5em5FXXUl43YDxO4K8VsLXJV7LKuwBdVqT3V5WAP7FORau rMx/X7CMU+vc3EJtQcHC+4IF9syKitzFFjnqurp8Qe71XupoxNNe9/tNVUa/X9yUMV1kO91v9BtN uFkP3aHzCpaQdj0vhRBD9JhmtSbEULHYiVGMcTLufKd1dpfbjRJiGIciUu7W61xVl6eKcs1qBWfR 2V2xPwqxX2eYTZrUwrLYEZfHKk9xVzJ/YCxMEfOi3Kx3Lmn56N6lK1z6+nqdKXtJkPld28vegtW9 l72cpzH4lddjZSur3WgHGltBbQkXXlWZZ6j/6MdcOZFsx9RF7nn0pkXwc1Gy39a6XMXpxMJr0MLT IaM1oycDLTwjLY3E6kCarMSAHSX6RUwqt6i4mOO4E8XmDJttoeOgwVCy8KBS6YdACYo6kwQzehQY MajF3Yv6wByHMBJ5Ty9cdMULB4pneNmfoxwyW4l30WMi34uHK/Eoa7rkfAoLUQM5YxUKZ6473/hK xo5rl2ys8m7pvmp/aNHe35wK/UP/TeYlXQ1V68uKt0av+2zD6C9u2fJKmGnbtaMg1FDb3e7N74ju brnuGyGzLfbqmg1FBWsqqzvbygLXHe+57uFwupUpI79cr8G4ZeAu4q3ADxclK16tXcgt/EIgoG3V siNaRquV6S0LLAcsnIaz2O0GznAqYDcUuE+joTF+zgc+g49Nk8l8nO8OmRUYbYGMn/D7y1VpAUvR YRUxbwxkRiLydD8VOIqB2KbPM0tMOGDDtZniebz0P89CAHkQyX7aMiFXPpWuu7wszyUe1+gITjR9 1ATxBBorOKoMqir2K/r2u69ed2AZXkvdhfVeb0NFymPX7N210bfneJMiJS27IHaz7e6TwRpve8kh eWtT3UjzbV+zbtoQXciH1jyysChbF7j1QGxvfZPTkqKpZ34mG+yvXbao3Yt68KIeuuWnIBM1cZOk h3yl4nRQqWY02gIuT5/H5Z3EK4k1h7PlnApYrZmmQw5HocY+kRk/qTEa4j6rpO0Sv7fV/ZCKM+eT KWG8mHdiyFzm5fLLXRhJalmUiWiN+cp8hgqEXghROveyGrzIMenXMTXrt1Q/+ODAc6e+cGjlQcbR GbomvK67aF2lrK5pVSWfpq5PvfwDZnGN89KH33xrR1WViVl+3Y7vPfTD73s7/eRmhzKYRBnw4IOH JBmU52SfDuYAz6Qh16cCaQaFilPdr1DITwcVCrXGx3lSPJznZCDFqlKnczDh8y0qOGSI3/aIvcV3 5CN2YPhVwhjq6qhoFl7xAjOkMy+tEJOWw6Zb5M7FolnFXVo8P11+RhKXZEyyLLmpwBe7uEetb7q3 +ZGHh37++aLOaoXZXcpY9sVea++sDRWv6/Z0VjN5q5YX2jUN6luZ5jUfXrr/rd1aQ/e2kC9T05B6 GfbuDH117Iff94SqUYLdGDf/A705A2UYv4dU82aOPxUYMTN68wLzGvMms8zKmc0aToMB7FRAY4AM RstlcBxevE4GOGsGmCYyM3N584Qiblh/eKoUZngQFYMJ8EDBygbJY31/4TKzfHIeiiHXTCFa00l2 0JC5mKOequRe2/LMDW/9fs+rt3XftJl3m9OYy0eYAzes2rviMVlT6+pu9SOD66cu/cPv9xS2lNe1 rd358NermpiWz99xz20oqWYMfkvlw8CBHb4tSaqKYzmuN6Bn17DsFMvo2SfY1xCRqYE1sKyBY433 6/Wpp4N6fYbMLjsdtDMm1jShUmVnSbeRJw1PJi4kxD7IbjZuuHZUElHJX0p/+vbyMWohBs9orpaV rjHoomk5MoxWzE9i/2frIleKOsOTy5j3cQqtKTcrZpMPv/feh8+nFDZtYn6yqCbPrAyqLldVLnVk Wk3KenLiVqM8StD30qE1fu+ypJ0OWiCdkSkVSnQGmEhJybDNuXeJPqSfO9Q2oxvdQrpRyAizNJ4w z+pc/pg1J9ecKuPUFnchmjzj2NTkwfuA0pyR3xjgdOvaFjvSVPWphDvUluIC2nUIfipxF1DlaWkc 0xqACXIBWYALnAzIDKH7r7563eng1fr0zEVlzfJV/oyWllWngy3GiRxV0URlTmVlTncIGida47eu Kp/P8HqpQdqRdGci4p4OhRShly/fX7iqJIhPpBpi0iUTl16rjfE7qqhcfOeWkTZ2uk1G40jipjZt BMw/6bpPrFq5OWiJnmxrHQgu4HQWtz2WU5ybosv1uTOLinmzUm5wumJ5XqdOrrPYXVmutsXavOKY o8SVIjfnlzCm/VwX17nc3bxk46rCrolrYrcVrfZmp+E1WFu4chOjW39tIMvgyC0sWxL7x2BTUTa5 ERc29zC6+u7KwsxUb7svtm9ji0dbX0/N7e6VKzx2Dd7EqRZlJ1GLVXBS0qInna3iMjMyTweZDEv+ /S5X3umgS19gTC3Gt5WTgWKDf0KhWJJTkG+eyCEKo/dYtD5JeAmh+qlMiYb4T6MYj+IfnxxyfKp8 lfQcjOtIdjJm9+alKFLSs/Ky3O2VOpcvlj0tRr2udmNfVftgQzbVQr3W07yJ0a7ors7P0PnW+mIH Nq38mJRu5RbXuXzrb1gXOyFKHcSoLvOj3PSQA1dLkrOBmTOfCoBVbefspwJqg+6QzcYbDskSH3RI J5MUewxzxyeOLjGcyOk1KHHK0wMeNy4eWeyS217cvXLiO9vefX/vG7Fvb+opX+ExbdoQbHcb+n75 wJEnDy6dev9bvx9l9S88X7HlltC/vLjuG/RuGWuX9SHfTrzHPxx/QyIhglOeDijslvvNZhNnOh0w 60vSizOLueKTgUyDI5/LPxVwWLMPFRb6LdY8PNO1ZE/ppXN2JapQPEN+NcNHC650hZkSmJ9YSD7L BDjRBKi3Slch46yLEPOsYWFZLNXnMnDatHw3Y7lOr1t3cg29EfX1ktvQ1dcUd1Y81FKbp6uvT81d uorbtqKm0J6mCqqOc2ub6bUok6kll6Knz3k7y6XYxxGvccM5SYaVRkYLKoOKVXMqWYDVmrS5Ws4o k2k5LQlG7vvz8pyng3l6a4Yt43TQpgoolQVuPNWzE2+amednnVPx23KmzXCeXJr9VJDev2yZ2YfV fCSlSIfvOOQAx/fu+SLYj1Oa71q/tOFh42KvtbzYrEgtLI2ZZ8SmNm7dqpTY29W19kX+srLY9zat 8qjnhhqUWhvehNaj1HzwfPwTMufUb7+jNjRpnE6z8+zUbwOLxAqXbg6Ys7isU2YD+PCK4isKFOFb 3Kkiqy09PX/BYb3em39YoVgEAe/8r4/SFuMoeb3zGAmgH4LNXdXxyasGiuJ2+QlkpXfHOa+OFvHV MfHmmIq1/PJ/sfVf3bLa2bZ5cbipsP97n2m+eXgifXG9t/6qrKa+jTtrawbv7P7KPzGp3d3BZQur yz226ub1i9dPLNelvRVYbq+pcFf4Pfmdwyvbdqxy+f4NJetCybKyX0AW3C7ZY5FZjW8XZr2e0XF6 84qAQZ8V0BmasrJsHGZy2TOZIM2QlqpKE++UT/mNfsOTVb74pfIpH3lDFu2ERivHp1JMXB/nzI1f G43kNW6x3+KwOIiV0U8EObbr1taTt+1bildi+b8x2bFfWkpdWUWL7Ltbln7py6yvUVPQMNj24b7Y 0msH/ZpMG7GjAHkn4S5AMRyLv5UZi00AxaeDoOdUvqz7M7XZOZzSgSHnJAlbWWkTWq2PnXDFA7F/ 5jvIr/D8op9F0Q8XAtmfSGvmC8esiSGzg1wI6GuE9DGWcfa7h5seY/kB5rAud5Hb1V6lMOYtZI7E 3zh0G06s3HqgEm+HZkcWd+Hyiz2DddnetT7mhuYVBXZd/eVg/JWDWxdc8/k9zFBljcOOd0WM6g9h aJfLO/HmrITMgI7jWKWgADknf0CBmjU8Bb7LT9UtKmE4J0d/ISDv/uoapjD27/LOjwa4Oy/9PPZT xktOh32cwL6PN05CxxbQKJTsOQ4vkMD5XnkJHSvzPPlbakJFTigdWXN8IbvnqhMF8lOxDOY3DAHi r0gis/KvmQeYB9i1mL8mZm7ddJZp/8fmf5a3YX5XcVTMSj3NG1XLVK+oq9Qvq1/W7NLmae/W5SVz Mv9d56ZkTua/07wtmZM5mZM5mZM5mZM5mZM5mZM5mZM5mZM5mZM5mf9/yeI/0cHyXYTZ0AMyuAqU XMXUG6ACzdTbCI9MvY/wKIXHKbyDwjun3gUNHWmFQ6BHeITCoxQeR3gIe5+ECQqPUngLhbdSeJzC ExTeDoemXkE4gZRvxxXfQHiUws/RluOI34G9f0B4ZOpNhEcpPI4QwMdWS//YKIU9lfiHSakwSGvi tztFOJmEM5DK9Us4CypNfAwH1ZpRCZeBTXOjhMsR/4aEKxB/UsKV8KHmZQlXQaG2XcLVsFz7koRr lJrEWlpYp8uScB0U6OJrxXnmEjzHv9OpVHeXhDOg1D0r4SzIDJH4t4FBtqFNwmWgM1wj4XLEhyRc gfheCVfCPsMRCVeBxfA9CVeD08hJuIY7nFhLCx6jW8J1kGaMr5XCrDJGJTwVKkxnyDedydSSnEVc lLOIi3IWcVHOIi7KWcRFOYu4KGcRF+Us4qKcRVyUs4iLchZxUc4iLspZxFMkayC4KOcQDMMO4GE7 hGEPPnfAGETxOQ79MIA4D1twxBDWeRxB6iPYP4rjB7BtHPEItm2mc8kcMrcROmEVLJPmjs7oGcHa MM7YAb2U4gBS5mEXXasX4fzrinUythcGcW5EWnUcR/D0e8LGkPKgtIMwjotIaw1IFHolWlEKvdgy d9+kf5BiBThrIT6j2Lc5sdJ8XA19jPKVy2iaeoRS6sO2UayP4YhRKo1xhIT2/HsXV/84X0tmSIDs RNzLOF1vhGojTOmLe41gyy6682H6jWvz71SUc3iWTKNUr8MSFHcl4juwNkIhT7ndSXcTTdAhIwdx xCdrqJ9KbgSqwYd5F81eKtFeakNjWLbQkWTmdhwzjjsiO+yjexxBCnvo//Ao0h1DnHCzBft24Ppk ZpjazW74Gq5fCiWYqxBb/bE1eGigO43LL64ZYkfLkNYgPtuxrY9yPUZrUepHo7h7oi8vUghTjZMd h6kUREshNhCluozQOYTKkKTjLQn5DkEx9vVSCxFHEyw8w3biOhdlTPQ5DNsQ66NYRPIyce5MLUbo XLLHMeoL4m4IH3spP2SPzbQ/zvFOuq891IZ3ShSJHMPI31xuRH8X5TZtz176TX9EDn20JUzXjM8R 6Y9TLYg9ZOUBbBuk9KOUi/hoUcoDKCuxdZRa2ii1MVFTOym+h44dp/wQHosScWeQzuinPJJdi/YS luQwH/WZkorzMZCw3mktiD4nyk2U5zQP26QoMJTQ4RjlOzzDl8bp3CFpVnylYcm3xHHbKY+DdJei ZDsSHhzXcy/9rkVxn2LPdmrdhMoQ9V7RQ8NojfFRQzAdqwYkeZBRYwlLGk2cE1HJ4nbR1l663yj1 6X4qszCNZqRvthR34HrkLJgZ0caoHw/OiBebKR6esecBKp3NUrSMx9wonbVdiiBjVFJbKLdEsxH0 oAGqt76EpK5OeMRc7xSlJJ6FMz2xl0aWmZE57jtxfyGr7pT0R2IKT61ftI6iGfKatphR5Ozjkvq4 T41RGyWxK5KQyhjVihh3RBsfpRzvoPqcyfm0tMRTRoyB0xYTnROBRBkMQT6ds5XKYhxm2/ncFXbQ 2aKHjkmnSy+2TuukesZqhI8+ykeYzt9FNSvuZb74GMVIPXvlXdQy+6WzSaTTJ8klSqmIFrBd8qqZ UYPINUp9Qxy/h+p/GKnMlskKKeZumzG7AUeLZ6joE1cWzXdInIt2NEg9MO4HI9JZMUDnDFMKIu9h SRdxWxmacf6IMWqceu72xAwipxEpho4l4px4gg9QXUxHqLicxBNpgOp4WLp/iNQJ97tmRaAw9aa4 v26XLGkgcUINUA/hpfN4rl155zlfq+fxwHqqiwjtE8/mClgnxZC4hMqRWhW2z55bnJg7v1dHJasR NRFOWKK4+6jkQTyN02HK+3a6520Qv++E/2wvkf+V3x/mxtlOrA0kTuW1VOLjs8473zw3rl4aFYak e6MY21ZT+sMzdNAsxb65J3QHjabDFBPHivFyG403f507GIlp0/ew+alO90vUvsaXlpRU8asHekeH x4a3jPMNw6Mjw6Ph8YHhIS+/bHCQbx/o6x8f49ujY9HRndGItyG8ffPoQJjvD4/xm6PRIT4SHRvo G4pG+C3Do/zwUPFY7yhpHo2GIwNDfXx4KMKPD/ODw8Pb+L7h4Qi/qx97R0YHhsZxTnicH9sexmXG BvZGx7x88zglvDM6uoeP7sSBYyPh3jiZkdFh5I2whiODA+G+4aHwIO3B8eMDvVjpDw+MDg4MRf8v cecCF2WVN/7zwMwzzAzgJUMsMzJTrDTTtmWNtbuVWZFpF0sb5CI8chlguCniKESumhaxRq2ZldmN t+VtN2rJrVmjEjNqTV0ys4lSuhCiuSOW63m/55kBoXXft/3//+/nP6fvPM9zbr/z/M45v9/vgGmB mc2QM9O5zU9jOFm8VFFaVmlcgSc/N2f+hQwkMystLiM3P3Nhbo6Hxn2qBwel+lDjDL5CWrabsTFO s4cFaXHkM7SCONSVkZYf58lIZrwe1Si30MNjWnZBWlaReq2ZGZkF5junZLqRyUN2boEnLieXUacl z1NZOapBXCbjyEwpUEpiFConK7c4LT8luSAtLiUjOT85xZOWHxpi4bzUwjQ1QISW0gVDnJemNEqz zHzukYAu07LSstNymMLc9Lji3PzUcZnZyfPVoO5QE9EznQypsCA0iSnJblPJ5uyoeYnLRcGslDh3 Luq40ByXqZj8cb2D6p2pgozcwqxUNZSCLLV20Hh+WmphSqhzc1j5aQWFWR5TMWmhBcQIcsZ44oxC ioM672lQWKAmtCAuNTel0HyTyWaz/LT5hVnJ+XHFaUrKyfWYVhJqXJzpyYhLjqPOfMaS5lEKyE5W eWpppGSm5aSQX5o9LzcrNJLrWLkLzOKrS/Mzs5iJUyzzQjpHR1m5BWoO3OyKzAK0pXpn/k2t5Jj7 hxXlSUvOVgVpJdTzFKg1lxuXnJmdZi4oNSY2UmaBhzWoVm9OWnFwASXnm/OajZIy1YbKdDOrpe4e XY3v3a+Teyfwqtys1MlqN196OytEDegX4391aah0nCrtM9VpmeaKTVZKRDxrjQHlJ6emZSfnL4jL VSV9HtNPbR961uysnEy1lW/zJHuC++4iZQhMASm5hTme/ExW2025LHb1Bjew+no29MzM/Ny4meSy LhcUZHg87skXXVRcXDw+u0fe+JTc7Itolzs/P9mdUXpRiiedvdq3qvmsqt2VW8j0lqplzLB4SVWi NgCqz870qCHOKzUHfO2s6VeaS0s9YFRYnGrNKYOQktGnLVd2bFZhanC6UjML3FkICJoiJprXUwvV Mz6uR3ZuDqs9PnMstmKeanSyq5yeyqcckVndNJfsDBSWEtx/vdJNTYf6uswcQHwmUjyYJCaDpVrK 7ijOycpN7iuUMSeHLG1+XO+cYJvcmKfUtCJsj6qTkZbl/skL/ZypMBV/UWpaejKrdHxygbuk52eL fOQjYp041Uf9KwR24RBOYZNSDAj9iwQ6BfFc3UL0/kzy1B9b+KWRkRp1tNqfWz8qStUPi/i59QcM MOuX/Nz6Awea9b/6ufUHDVL1w+/8ufVPO436NvPfYogQFrO++glzjLCZOVFo8wwRyRlioLiE3BtE BTFcJZFBFR7+frFYrBTLxWqxVqwRG8WD4hXxkPCJavGeqBEfi98K9dPtg+IRcVz7SkOKNoQhDe8v T4vrIy8aecORdz7yEsi9BXlzkJeBvCLkVSJvDfIe5/tF5G1G3rvI24E8P/K+RV5APKKFIy8aecPp f1R/eWHX9JE3DHnxyLsSeUnkZiKvBCmVyHsYeU8h7yXk/Rl525H3GfIOI++EqNGixG+1YWKtdh7y JiFvKvJmIW9uf3nhT/1MeTXI24i8euS9ibwPkNeGvL+LauaoRhuIvOHIi0fepci7AXnMs5bcX541 vI+8M5F3AfKmIu92cvOQtxRpq5H3IvK2Im8XT/uRFxAPak7xEPNRrY1D3jTk3YG8VOQVIG858tgX 2pP95ekb+8g7G3lTkDcHebnkrkbeBuS9irzdyPu7WKmFi9Xa6WKNNgZ51yFvLvIKkVeDvKeQV488 H/L+hryvkfe92scRNhER0Z2VzierO0Ln+Xiqq8TlSj0eEUHJlHk+3wfvpE+JsIgIS5fL/HRF2EWE 4wuvik7vNtPVot0bYRUReslWX1dJbG2Xrgtdd9fGlrSW2XVht/ldrpIsPiV2XbPbEmIp4FOmW1W1 1m7fVrfdIuwWl0v4TQnmk98Vkqc7hO78UWR7g+k7n24Tuq1bddipJNlKtvOh757cEtVIDaHDY7a3 aIj50O+u96tRIqab7IwJZjcdqsGUiDAtwuJTH+HzhYdrduuGDRvsEcJuP56eoj7px+02YY84Mc+V WpbqmnfCbtPsEYmpNNi3PStRjdfa1TNeu1PYnX5/ni/PN5s0nXSF73O/3cq7oyG/O8FUkabbQipS PfO2WUXMQpnZ8/DIyDLeaW+OblXV/mcVRQo9ssNX7Eo301G3HiH0iA7V4dG+KrL15Jb9tyqy9qpI ddNJ/Zxf2sM0e1BFIR05lI4c6u9cOaHOxN6TKYV97LBpDnuPutJPqHqOy6n3F+yYT7zrfUu8xdPl wmERjl7VubocTs0R1V93Qe05dM0RUba9Ce0NX7W922bTbBElq5SWyh0RwmFHFTkFaqbmOiKQHK3r 5e/waSm26arm9u3HfU0lprAeFSJMPfp7ZdsihS3qpBKVGm12YbN3msf3YDrqVZLtZarvd8qQTLEp tlx1oAubzVQo91bNxmwz3Nouu5XlEVQpOjX7bO/tcb64zOsIQ5u+XuVarJpTb2198MH/B9rVHHof 7UZqjmi/2+13++9y3eW6mXSN6wqXv+sU2rWHtOuMEE6l3R71OiM0pwP19upXzQT6OOHbUvYT/Tot wnlSv+gkWtiiO90FtSmxwXR0s1KG479XsONfKFjdlzX5S4av6lYK1vsp2PE/KtimFOx0aM5IFIxa Xb6ehIq9J4T5njIl2dRxcopUVZ2Xq4pen6nlt3x/Mefjcq/Twnx1nXxPZ6Tm7KPm2X0U7bRpTnv5 O1v87sRoveqd4xE2LcJesj0yMQtVR9pFpMMvXGZSP0Q9OeVzhVloIxJTSc31W6Gk3s/sJjGdSfDN SzTV3jsLrq5Ii4jsMw0Y8GgRMaDvPKiZMK1635lQcxERoUU4EtPf4pOeGNlT4+SwykOD7Qo6ks6i kABdi4goa/J1JUau6nZYhaNncpgdU057Hylq/M6wMKfu6zdBkeYERTm1qCgpCrx5PqXOkynPV+CV IsquRTmlN8/r9rrNH+qXmz9MIpEnvap15Nk+t899hV8E0xf+z32f+5R9GeGLsmpRtm73yU93VLQW NbArsSShhE/WayrNT1BpXoIroassKkKLclxe8Lm/qyRxxADb/S3H7XbN7pgi2omWbHjp+dwdFMXe KIeIcnYFR4KbXOTN8/WkAm+uiHIwbJs33EyXewu8X/SmYu9lPnsEnSamt7dLLOGUKKuI0t1EnV29 o1Q5XX3HbR8k7IOOrhel7SLv3Z/+9+NBr+mSjnpLfXl90o9+NXrnFAbYRz5xBqOn9k9GvST0Nt3C 9ItHlxSEROOv7OUH2rrKRqxuOe60CafN7T4RHFd+oin4+35iC3y/9keFa1G6v+cjwKpr0RHKSW0P RtcOsTZsnwhPKc3PEkPm56ctEJdmJXtyiLgcQrttxlVx6l8h4zQS/LMW0aF7jVhpQPCv9DWfwzi3 DKRm+A1JSdeLkTNuuSlOjJ8548Y49fcBmTXC6W9Q6J59IwaH7q1EW6eF7nXi9SHi9AVp+TnCa35X md+rzO9q87vW/F5vfm9UR3Dxgvm9V31r0eb3FPPbbX4/ZX7vyF6QvSAszPyONL9jzO848/t88/sS 83tK76nj53wP5RpmvhEhlvmvuQXPb5G8STQaGsg7D+b9eCu0M/T/qEXM/7qE//0x/bv1w0UsZ40z /q/uzuQEdo/IEmViFeftOs5a28Ve0cFZLlIbrl2oJWrTtXu0LK1MW6Wt0+q0zdp2ba/WIdSfbwlX f86Gk5zSi9BeC16fSzWvGqdTu7kC1N9FxBniwrn9ny9p6/+c0NT/OdHb//n6l/s8W4U2M6Z/+cyN /Z/nTOtfP7Ozf/mCyv7lnoH9yz1N/cu9+f3Llw7uX748un/58tf6l1fX9i9fO7p/+eOif/njy/uX P/OT8W8q61/+MuMJ63nWeX5M2LU+z69+JezhfZ7fqBXahq3KOukjIqdGeiOrImsj10f+MfKbyO6o uZG1USVQFbU5alvU8eibo9dFbxkwhHr/nNaTqnpTrdnLT9M3oUTPA0ZGzVX9nyKtR16VKbMnbVMJ 6cG0JZgGDFEpsnbQ9piGGF/MtpidMXtiOobu5mlnbGTsYJ4bzBJf7CWxa2ObYlvI98f+MCw21j9s tFn207SHtK0nDbvQ7PEnadjUobtVMuvv/GlCLpKVbLP1yZ59p0h7GNVac2ShdGZl3PpzhqtxnqLn H0LJH0zDRqs05vwxdTG+MQfiI+Kj42PjR8bHx0+MT4ifxn0GlMc3xbfEt8Z/E398rD42acyBf060 GUnbnhRr9vLTNDGUVM/TzN7/OY1EWrkpsSe1qDR2LtLNxAiCKUml+NjzLzS10NGjyZO6i9k5bsa4 e0gzSPMmHU8Yn5CQMGVyjULlJR6YsvnKqVdt6LleO/q6Xm5ovGFvD9PGT9s4rW165LSNSbcnuZJ2 JHVN2zjzsaQds1JnVc2qmb3v7uX3lN87SpUmRyftmL1v9r7kmcnzkrOSy5M3pMxIuTM1P3Vn6uF0 kR6dPiR95PwJGTMyMjIWZm7O3JI8M2VG5s7MnemCPFLmlsw9md3Gvsw9WRlZOVlNWbsz92RnZTXl ROcMyTkjd0Lupe4JZlkT9xPcK9zP5Y3Mq8nbnefP68z/Y8GMAndBeaEojC50FT5VlFW0omgFOe68 mqLnSkeUdi28alF9nn/xtIIZi2sKXeWTy68pzy9fXr6+fDNpC2lr+Z7yI0umLblnyT3m8/Il6UuO eKd53ZTv8VZ5a70vefd6v/F2eQNwfGnY0oFLY5bGLR291L104dKF3uOkvUu9S/ctG7Ls5mVZ3q5l C5fGLdtO2rFs77JvlnVXhFXEV0yuSKqYV5FVUVRRWVFdsaFiU0VTRUuFv6KzortSrxxSeUZl3Ckt Q4916Jv67fjKeadOwX1+yp3as1v7JrVP+u2wSs/JpEr7Pgd30al2RO+u6Jv6rfXKqlOn4PqufDBq WywrP2Yn1rS2cm2PVYv8Y2V91PHIbmVTKxtnVUVtq2yq/EHZsGGj1dpHS7UhXZk2UrVSZdz3aLDW tMVV9Os1rXCvHqO38FSFRd12XwSllNwXHVVl5nrNVNXXvvYm08qrpGxxX3scVUKqOrUdVp7A9AXK G6zrscNme9pEdiubrLR/33ZzPjqqRrCreT/scEuVp6p82OiqB6u2BN/Z3Pm+PnbOF5xZZWGxBPRS 5Y+NHDY6ZG8b+s6zsp3qvioQ02Da89Csx/rV9/2W+8+4fwN1/MtPlm3rI6ln1XRUxvX23mvTlR0K WiIz9V93fVZYyIL3seGxLcHUx3KrlfaD8jtBz6NSTAN1sOUxDXHrYxqWL+d5MBoxR44tj13+VGit RcfH/6YeC55gWvSWFYNXxAXtJ2s0NrRSg5aZ2qZdndi7fmNND1BOfxHB+sE0Vuc+GiveEh+haq54 Ob7czIswU3Q/mx5MQa+S0Gv/T3qADFL5qS2/6XlaTdt/POh/zPG1KE+ANNWLapugfIF67xVNK9Mf iI/xPTCFb6Vz3wN1q2NWJ1X5Y3bOqsJqVwVt9Ox9q4uwyWJ1PXa2KWhRcydg6X9mwrL/JOEd+qVT 1NjRP81KDY7kZPrnNviSfzMFfUrmzp5rz1PPs3rrfmlI+pCg//nXCc/076Q9Pz/hzfqnpv4J3xcd nJtTpVPNS9GKvBp8YSipJ+UTg/7Q9Ikzeu6KVuBDV+A9/cpPmv7TTPhPkmpZtGJ1Iy1pm+dXHtH0 lWbCRy4v3xr0ltxvDl5DnjPoT1XaY6blqjZ1p62JwFOG4UWDPtRMeM69pic1vajpSbt676q8VWqH mPWPBxMeVyXVauGaaFrRLuSzdipbGBu5Jn7NDmUX13QHc2N2PrgsaF8eiqxOr659eOTDNQ/vfnh3 jah5qcZX805N6wPxvz1R48N2NK21PPJUbNOw0Y9sfYQafePMGF/t9bWzg7YrZK1aho1+9PpHZ5jW bGdMx6MlJ+Pl2KZHX8JWjX70y8e2/S5p3bTHxePb1m94YuITHRteJvbYE9Q0ujH1tDQu+G6cTWvl 02KXTBDfyQ7NIgPaHHlIM+Qm7YBs1dplfXgS3CrrHRtEouNJeFkkOu8VEzmH1MoOTiC1sk2bLoaE 2rWTv0se5ExTS3sLeSfLDnEWVrU12UJJvTaAGhdzP13Ea7dyP0e+oaXwbDASLxygTrts5aRKK3pt o6SVc2+tLA2N1k/bRO0OuVe7C2bD3XAPzAFDNtFHHX1Mt5BnIc8yF+4FFyRDKqRButzb9w05Y9XK 55Ve6KWcHjahh1b0wGiQ20L/36rxmW/UQr1G3kqNqI2Sdtq0hUav2rXQrqVf7+GmdpRm2nmzSLOP NlMzTfRRjWZ29dGMkrbO1MwBOV71ybm9lu/vyNFMLT9Bi49osdnUx61c58hXabFZaQxdBmjpoWWj fqNItd0vb3c8DRvhXdjK7J9Gj00hrb5Jb+0h+Ykh+a+GZiYQmpkKemv5l73Z1fjoqdV8gzlcDd7g ALRLg1YTzRWk3qIcma0h3W1C7ibk/i4kd13ovetpXU/rgbR+pJ/MkDznZNnovFcaIb0azEa7DIgX hC79wgGDYQjEyMNiKLqOlfvEMObyDBguPxLnU3YBXAjjYDxMhssgEX4Ns+B2uAPuhLtgNtwN98Ac mAv3QgpyUiEN0mE+ZCA3EwxYgPwsyIYcyAU35EE+FIAHChlfERRDCZQy1oWwCMpAzdmjrKDfce3m egx+gB/hOHn/gBMgWVfMl9aJdg7CYfhetoaFgxVsMJT1/Qu4FC6DJNnGum2zRMp9liiIhgEwEAbB YDgNhsiPLKdDDFwlmyxXwzXgkS3Wy6Xfeg1cB9fLVuvNXG+BmZTNgjvkPuud8iNrGnnp3M+HDMgE A3LIz4U8yIciWArL4D7Kq2A192vgQXgIqumvhuta+n+U8se5f4K8jVzr4R14F7ZCM3woD1v/Cjvg I9gJu2i7G/4GrfAx/eyBT2AvfAr7eJ/PwA+fw5fyI90qm/TJMA2q4WGokW36b4G50tdzfYLr87LJ 0Q5fyTbnbczNZGGRq4QVe2pT/yck2MEJkRANA2AgDILT4HSIgaGykdUcYDU3spp3iTNlJSu6Vpwl N4sR9Hk2xME5MBLOhVFwHoyGMRDPzhkLF9HfBHblxVwnwiS4BH4Bl8IvIQF+BVPgcrgCroSr4Gq4 Bq6FqXAdXA83wI0wHW6CmyEJboUZcBvMBBckwzxIgVRIg3SYDxm8Yyawv9lBAXZQgB0UYAcF2EEB dlCAHRRgBwXYQQF2UIAdtIsdtIsdtIsdtIsdVMsOqmUH1bKDasVi9FQOSwDLJpby/suwRrp8RYuD c2AknAuj4DwYDWMgHsbC+XK6dgF8Ll3al7AfAnBUunp31NdyVfg38C10wHfQCQehCw7BYfgejsDf ZUd4AI5CNxyDH+BHOA7/gBOyg90ZYHcG2J0BdmeA3RlgdwbYnQF2Z4DdWcvurGV31lqula9YpsJ1 cD3cANPgRpgON8HNcAskgUc2WkqRsRAWyQ5rIvwarhBD2M2NVubVOg2YWytza2U+2dmN7OxGdnaA nV1rvUtuts4hfy7cC8yxlTm2MsfWFLnKyhyz8wPs/AA7P8DOD7DzA9YFlGVBtjSsbup4oBCKoQQY k3UR5WWwmPtyWALMobUCKuE++qmC5dz/BlYyllXUf4D7asb2MPdrGStxDJYiYH2M599x/wRlG7h/ kvun4Gl4BjbBs/AcPA8vwItQB/8BL8Hv4T/hZfgD/BFegQZ4FV6DP0EjvA6b4c/wBrwJPvgLbIG3 oAnehm3wHmyH96EFPoAP4a+wAz6CnUA0gvVqxHo1Yr0asV4BrFcA6xXAegWwXgGsVyPWqxHrtQvr tcvaJiutX8CXvPt+9HQA2uFb+usAIgNrp9ysI0tHjr4LdstX9H3wGfjldP0r8qivd/J8EKR8xcY+ skXBUEiRr4gwfNabxEvrzLud3Hm4U7GdBR+pYsptZkz5qfhAOMzS77hOFrtEjvaVeEH7VrwQpomc 8AkwESaJF8KT4FbIhVJYTH45LIEKeAY2wbOUPcf1eXgH3oWt0Ez+Nq7vwXZ4H1rgA5FjfUQss54Q SfpEMZXI4wd9ulilJ4mJtkXiYqKQFsdKMdGxSkx1PAB4HMcj8DRshOfFDscLYq3jRer8AV7l+TWe /0LdLfAudbbKvzkOiCTHtyLV0UFkEIUevrF2i1TrMeKcxbBUlNiWiRLH49RYDxvo4Ul4Wax1zhAl vbH4pyLCjMh3mbHUDhV/UjeJuknUTTLrxVKjk4jhMBFDJxHDYSKGw0QMh4kYDhMtdOLBO/FinXiw TjxYJx6sEw92GA92GA/WiQc7jPfqpOdUek6l51Q8WSee7DCerFM4kb2LGRnBjIywLZUttmW85eOw XsXA8KRscc6Ae0Nr4JCafWFRsTPt4mkX73iKseqht2hDn03oswl9NaGv5cJmRuCUMANN/1QaHtLA B2Z8rvHdYUbzy4mwW4k2VaT+B3Knq0hSrBEVnFYq5RGxAg2sEoPEA1xXw+Pkr4cnYAM8CU/B07AR noFN8Cw8By/IY+JFqIeX4Q/wR3gFGuDP9PkGbIPt8D60APGH2E15K3wMe+AT2CuPqbWgWeUR7XMx QvsS9kMnp4aDcBi+hwB5R8UIy1B50BILw+AMOBOGw1kwAs6GODgHRsIoecxyHoyGMRAPY+F8GA8X wQS4GCbCJLgUfgkJ8pj1sDxi/R6OQIBnVpH1OKtDk0d0J9coeVAfII/pMVwZm87Y9DPJP1sM0s/l fhQgX0e+jlwdufoEyi8hHzk6cnTk6L+Cy8ifQf5t9D0TZsHt5N8Dc2Au3AvE3Doxt07MrRNz6xmQ BdmQA7nghjzIh4W0WQRlsBjWkcdc68yvvon7Z+VhW4484rCzuifJI87r4Ebup8Pt8qA2lZWzX9zH Gq6C+2E5+xBfw2pqFythFfcPcF0Nayh7EB6iXjVr/mGuNTyvBeyGea59VK4Uj8kP2J+lYp38RDxP nTr4D3gJfg//Ca/Ca4APEfgQVlc7q6td+OAdeJc+t3LdBu9xv53r+9ACH8JfydsJu+njb9AKH8Me +AT2wqewDz4DP3xO/S/ga/gGvoUO6GTsB6ELDsFh+B6OwN8hAEehm3c7Bj/Aj3AcC/AP3vMEV8lJ T8hPtDAIl5+y6vdrT3DdAE/CU/A0bIRnYBM8C8/B8/ACvAiMhRNOCyecFk44LZxqWojBWojBWjjV tFjOlYcsF8p2yziu4+EimAAXw0SYBJfAL+BS+CUkwK9gMu1VH4nwa5gCl8MVcJUs5eSzjpPPOkuh /NSyBBle+Sm7ZD+7ZD+7ZL/17/IQO+WQ9Sj8INutnNLYMe1WKT/VhTzEztmv8+7Y31Jdl5/oDvKc sl2PJG8A9wM5cQ+CwXAaDIFh+NszqTOc8rPgbJ7juI6kzViu58M46o2HCdTjPfVJ9M37scsOscsO scsOscsOcXJZx05r1xNp+2u4nLwr4Eq4mjbXcr0ebqBsGmO8jfHOhFlwB/l3wl0wG+4GFyRTN5U+ 0yAd5kMGZIJBWRbXbMiBXHBDHuRDAeUeQJ96ERRDCZTCQvpeBGWwGMo5WS0BdK4vhQr4DayAlbAK HkAHq2ENPAgPQTXv8TDUyJX4uJX6WvmB/giwF/VHeefH4HewjvE8Th/rqfMEemJN6qxJnbWIpWjH UrTrz1HvedrVyU+xGvttbnnIlgf5UAhFUA6MC4vS7mD8DsbuIM+xDCoBW+JQcQXjdGAvHNgLRzV5 2ApHDdTiDzfJTxzPQj3Pr0AD/Aka4XXYTJs/wxvwJvjgPfLZ644v6LddluKvVzq+lp84J+KJJ8n9 Tta8k3l3XgnX8cw8O5ln5zSuN8p2LF678yaeb4ZbOLUmcb1Nljpnyg+cs+iH+Xcy/07m3+lir59t RnL/n6I2rQKvPgq7rGOXdeyyjl2uxy6PwiY3YpMbscUGttjAFuvYYgNbrGOLDfFbOR57XI09NngD A3tsYI8N7LGBPXYRFRhEBaOICgyiAoOowCAqMIgKDKICg6jAICoYRVQwiqhgFPZbJzIwiAwM7LiO Hdex4zp2XCdSMLDlOtGCQbRgEC0YRAsG0YKBfdex77r4EzIb4XX62gxvihHY+EbxF65b4C1ogrfh HfLfpe1Wrs08v8f9X2EHfAQ7YTd9/Y1+W7l+DHvgE9gLn5K/Dz4DP3xO/Tb6+oLrl+hlPzHUAWjn /iv4Gp1+A9+irw74DjqJ2A9Sv4vrITgM38MR+DsEKDsK3XAMfoAfIegLjD6+wEWctgl/4MIfGERC 0/EH9fiDevxBPf6gHn9Qjz+oxx/U4w/q8Qf1+IN6/EE9/qAef1DPmTxBa6M978DZPIGzeYL5k8QA 16PQzf0xZBzn+g/pCguTCWEW0GUCEdUoIiqDiMogojKIqAwiKoOIyiCiMoioDCIqg4jKIKIy8C06 UZVBVGUQVRlEVQZRlUFUZRBVGZYLiNIu5Ew9jnrjpQvf48L3uPA9LnyPC9/jwvfo+B4d3+PC97jw PS58j47vMfA9HnyPge8x8D0efI8H3+PB9xh9fE81vqcR31OPv9HxNy78jY6vMfAzBn5Gx8dU42MM fIwLH6PjXwyiNUOPFiPwMy78jIGf8eBnPPgZD37GQxRnEMUZRHEGPmeUfgb1htP2LDhbNuJzdP0c 8tAD0Z1BdGcQ3RlEd4Y+hn7jYSzl5wN60C+EcfQ7Hi6mLe9O5DcKv6Tjl1z4JRd+yYVfcpl+iffG J1Xjk3R8ko5P0vWr5Hj8kgu/pOOXdPySgV9SP19OJVocRYRo4Jd0/JKOX9LxSzp+SSdqNIgaDaJG g6jRwE/p+Kl6PYW+MnkXg7wFjK+AqwcKoQiKoQRKYSF1F0EZLIZy8paAF5bCMtpXcK1kjPdBlVyu 3w/Luf8N77ECVsIqeIB6qwGbhF/y4Jc8+CUDv2Tglwz8koFfMvBLBn7JwC+58Esu/JILn1SNTzJM n7SBd2Zv4JfqiWBH4Zuq8UkufJKBTzLwRzr+SMcf6fgjHX+k4490/JGBL9LxRTq+SMcX6fgiHV+k 44sMfJGBLzLwRQa+SMcX6fgiHV9kONbJ8fgjF/7IhT/S8Uc6/kjHH+n4Ix1/pOOPqvFH1fijavxR Nf6oHn+k4490/JGBPzLwRwb+yIU/MvBFuvMyOR5/VI0/qsYX6fiienyRjg8y8EEGPsjABxn4IAMf ZOCDXETko/BDOn5Ixw/pzjliBL7IEHFY8mYseTOW3I8lb8b6NGN9mrE+zVifZqxPM9anGevTjPVp Zkc1s6Oa2VHN7JRmVmAzK6uZWWlmVpqZlWZmpZlZ8TMrfmalmVloZhaa0XYzb9TMGzUzumZG5xfR SO7kXNqEPWrFDrVih1qJVTuJVQPEqp3EqgFsUis2qZVeO+m1k5adIkIbwPlvOgR/i+IJ/TanJTxJ bgq/VW7ihGtweg0zf8fGmZg7Q7ZTq52SOZwMekpazZo+Ttpz5MfqbNxz2uY8PYCc6TDH/B3bDNVP z+/9hJXSgHaxPEyNgHYrqN9uDNLuIOcumA13wz0wB4jqVHsLzxaeLXPhXnBBMnBGs3BGs6jfi6ix HlC/UTJH+RntmszxqdN9U89PEcycvcF3DuWo2i+r3yeJwYyjgXE0MI4GxtHAOBoobaB0U88bMpYG xtLAWBoYSwNjaWAsDYylgbE0MJYGEU6rL0K/uWsTkzRdvq6dzfvEcT0HRsK5MArOg9EwBuJhLJyP t7oAltDGi8aXcv2c3r6E/RCAo+jlWvm6ZSpcB9fDDTANboTpcBPcDLdAknxd3845dDfXffAZ+OUm vZPrQThBmZSv2xirLQqGAnq3oXcberel8Gyg52bepk6zyQ7NDg5wQhREw0AYBIPhNDgdhsIw+b52 BvN9pnxbGy53amfJZ7QRshGttKGVOrRSh1bq0EodWqlDK3VopQ6t1KGVOrRSh1aK0Uqxdgn9TYbL 4Eq4GqbBjXAT3Ay3QBLMgNvgdpgHqWCwJhYwnizIYUyFUATFjKsESmEhLKJeGWNczLUcOBMwG23M Rpumfq5fCZ+zD7+E/RCAo7KJWaljVuqYlTpmpY5ZqWNW6piVOmaljlmpY1bqmJU6ZqXOcqvssMyG DBmwGLAAcsGN783jPJgPRfJ9Sxl1FkM557Lfw+vybf0Nrm/KgP6ufF/fCtu4fw+/s53zy4eU7YCd 5s9X6/SPKdsDn8Be+BT2kf8Z+GWx3k69b+A78+eudayKOv0Q993UOwbHuT9Bv1LW2YTssFllI6ul zmaX77Ni6mzMv20weUO5j+We86TtDBgOZ8EI4Expi4NzYRSMhngYCxfAhTAOJsDFMBEmAXNu+wVc Cr+EBPgVsA5srANbIrAWbFcB68F2DVwLU2E647sJboZbIEkGbNge2wy4DWbCLPm27Xa4Q+603Ql3 yWdss+Fu3uce2cYuaGMXtNnupT8XfSRTZx5lKbzrfPIyIBPY87ZsZYPCHhYZYU/LD4QWdrMYq20S FvmhiMEmDSXaHYatPUNuF2fKNWK4nC7O4pQzgvKzIQ7OgZFwLoyC82A0jIF4ouixkEJfqZAG6TAf Mug7EwwopP8iKIYSKEXOQlgEZcCqFqxqsQQeY+XqMAzOxDcMZ4WfReQ8gmdmjB3axA5tYoc2sUOb 2KFN7NAmdmgTO7SJHdrEDm1ihzayQxvNPy2xALKgmL5KoBQWwiLyymAxlMOS0J/QWCo7wobLv4ad DefID8JGcx0vx4VdLNegwRlhM8SksFT5dth8QNNhOVyLoFSuCyvjuob6T1J/I/X/wPOfuW/l2i3f DndAlFwXPprr1/LD8G/gW+iA76ATDkIXHILD8D0ckR9ahsjpltMh5r+Yu//4uOo63+OTiSUzbRHU QRQpigUlQCptLqLSKuVXAwSkFSskiAiEQPgRxPCjFMqPOIpinHVQs+Zmd42bO/du6tbY3dw7m3X1 rhmu665pZas5k6tDmYR2KA0DFCig2HOfMx2wsq57H/u4u3v/ePmdOefM5JzP5/15fz7nJFScpbrP xiq04Byci/PQivNxAT6MC3ETPoWbq7/DXqKKc/Nawsy8i8Il8z6Ki8PWeZeEW+ZdGf5k3nW4HjeE 4/PWW+/EA/Z90Zp23IPWr/nMgPVPvP+G9Se+72H8I7bhp/iZY6YQII9H/LzteDT88bwiZsLUvFk8 5jt2+H69cF4J5XCLaSFnWshxljxHyXGUHDfJcZOKg+S4RY5b5LjFOIfIcYgcR5jjCDlukOMGOW6Q 4wY5TpDjBDnVl1N9OdWXU305lZZXaXmVNqPSZlTaoEobVGk5lTan0uZUWqXKcqpsRpXlVFlOZc01 lMJSw+PhaMOuMNPwhOrbHf6oYS7saHgyXN1Qtj5l/9PhWMMz4cMNe/AsnrPtecfv9TNe8JkXw20N Lzn2l+Gqhl9ZX3bMrx2zz/eGYSYWCcdjdeGPYtGwI1Yfro69zjov7I8dZF8DYmFPLB62x+aHq2IL bF8YXh472Pp6+w6BO56YO57YGx3zJsckwiNih9n/Zse9JeyLvTUcjB2Bt9l/pOMWha2xo8IVsbc7 7mjHvdN3LIa7ntix9r/Lce/2PcfZ32i/2SBmNoidaL+7ntgS+99j/0n2L7Xf3V/sZNfwXsecgveF Q7H3O+YDjjnV9uXOYYXPfdD7D9l+mnXlvtnY6T57RtgcO9sxq3yOTmPnOPZc289zXKvjzrf/Avs/ HPbGVlvXuI6P4CLHfdRxax33MddysePa7G/3HZfi4/ZfZv8n7L/c93zS/p+HD8V+gQIewXY8iiJm MIvHsAM7UcLj2IUnsBtzeBJlPIWn8Qz24Fk8h+exFy+AF8ReCh+KXxk+HO8IM/Gr0Rnm49w7fm3Y He8KV8evC9Px6+2/ISzFbwxH492OuSncEv9UOBO/2TGfDi+P94T3x28N++O3hYPx2+EuLn4HeGv8 znBF/K5wQfzucCh+j8/ei/vscwcX/0zYHk+Gq+Kftf/+cDz+eZ/9Ah7wXV8MN8b77P+Sz6fwZfvT PvsgvmL/V33f1+zv9/ls2BT/Hv42TMV/4lwfxk6vS3gqbJo/L3xo/vE4AWfjnHBw/sXWS3Cj1924 LXzIXUGubqHONKIrZWp/xTSjK3XpSmldaUZXGtGVRnSlEV1pRFca0ZVGdKURXWlEVxrRlUZ0pR5d qaf6Nx/X+K5r0YVbfMet0AV0oRldKK0LpXWhtC6U1oVmdKEZXWim8vcSOsCIDjCiAxR1gBEdIKMD dHH3Ee6e4e5dnD3DxUe4+AgXH+HiI1x8hIuPcPERLj7CxUe4+AgXH+HiI1w8zcXTXDzNiTO1vzvI c+IMJ85w4jQnnuHEI5x4hBOPcOIeTjzCiUc48QwnHuHEaU48wokznHiEE6c58QjXzXDdDNfNcN3M AX/RM8N1Z7huF9ft4rpprjvDdWe47gzXnam5WoGrFWquNs7V0lytl6u111xtiKuNcLURrjZSc7U8 V8tztY1cbZyr9XK1Hq7WztVGaq5W4GqFmquNc7U0V+vlau1cLcfVClytwNX6uFqaq/VytS1crYer 5bhagasVuFo/V+vjammu1svVGrnaFq7Ww9XGuVqeq+W5Wh9X6+VqvVyth6s1crUcVytwtQJX6+dq fVwtzdV6uVojV8txtQJXK3C1fq7Wx9XSXK2XqzVytS1crYer5blagasVuNpGrpbmar1cLc/V+rla H1fr5WpprtYbW8kRT/fZMziirs3VClytwNX6a66W5mq9NVfbwtV6uFqOq+W5Wp6r9XO1Pq7Wy9V6 uFojV8txtQJXK3C1/pqrpblab8XVOMtI/KqwwF3y3CXPXXLcZRt36eUuPdxlHXcZ4S4F7lLgLgXu kuMu27hLmrv0cpdu7jLOXfLcJc9d+rhLL3fp5S493OUI7pLjLgXuUuAu/dyll7ukuUsvd2nkLjnu kucu+Zq79HOXXu7Sw12aucsW7lLgLoUD3CXNXXq5S4a7ZLhLF3cZ4S4j3KWLu3Rxl4zZdm2kMToX OdlsW/nfr0aXmM8eDE+OBuFotISXw8vqF4ajB50X+VpDKXJKw+ORlQ27sDuyvGHO+qRtZep8yuun I8c1POf9817vxYtev2T9pfVX1Ptr6z7vw8jKWF1keSxqrY+cQsGl2LxIU+wg7xsQsy1unW9dgIWR 42IH2/962w7BG2x7o/VN1oTPHmZ9s2Pe4pi32n4EjrRtkfUo69tl+Gj73un9Yhxr27us77Ye5/ON 9h3v/Qlosm2J9T3Wk+xbal3mu092zHttPwXvs+391g9YT8Vy+1dYP4gP2X6adaXPnm49w76zfXaV 7S0417bzrK3W8x1zgfXDjlntmDW2fwQftW2t9WPWi517m33t3l+Ky2z7hPVy6yf1tasix8U7Iivj V+OaSFP8WmtX5BTqLMRvsO9G77vxKdtutn7a2uNztzr2Nu9vxx22rbfeab3L5+627x7v70WvbZ+x Jq2f9bn77fu891/AF23rs37JmvK5L9uX9v5BfNW2r1n7I6dEvlJV1ITpPgjvoqq7qOrk36GoUw5Q VJ6illPU4t+hqOUU1URR+dco6pQDFJX/FxS1+PcoKl9T1OLXKKqJopZTVBNF5X+PovK/R1H5mqIW /wuKWvw7FJWvKWrx71FUvqaoxa9RVBNFLaeoJorK/x5F5Slq8QGKOo6illNUE0XlKWrxAYpqOkBR +dcoqomillNUE0Xlf4+i8q9RVBNFLaeoJorK/7OKuiV6dGSFiWL0gHuHjC6brnbZp3XRF9xnvBT2 66L3U8q6A+4FMrpmutY1K90yrVtmdMu0blnSLdfplpUuOapLpnXJjC6ZpopmXbKkS67TJbfpjhnd 8X7dsV93vL/WHStdcVRXTOuKGV0xTQ3NumKlG47qhmndMKMbpimhWTcs6YbrdMNKF0zrghldMK0L lnTBdbpgWhdM64IZXTBNAc26YEkXXKcLVrrfqO6X1v0yul+61v1Kut863W+brpepdb1+Xe/+Wter dLtR3S6t22V0u3S123Wq7Wt1jy7z8HXm2BvM0b+ZlTO6WVqWe3WzbbpYRhe7Xxfr18Xul+FGXazS vUZ1r7TuldG90rLbrHtt07Uyta7Vr2vdX+talW41qlv161YZ3Sod+WZ1VlwStpoTx6O3hkXz1I/M U73mqXUy3S/TGZluleklMr3CPLVNtvvMUNvMUL1mqG6Z7zdDZWS/VfaXyP4K89OPzE+95qeKEvop IUMJrZSwhBJWUEKX+anD/NRBEaspYgFFLKCILopYQRFd5qcO81MHZTRTxmrKWEAZC2KJfU9SRhdl rKCMdvPTWvPTWgppppBVFLIgdtS+l2Nvd9zRjnun71iMY+w/1ve8y/534zj7G+0/3r4TcKL9TfYv se89OMl+8zPFrKCYXvNTh/mpg3LaKeeI2Af8jFNle7mfucLnPuj9h3zuNOvKfQ9SzurYGb7jbNe/ Kuw2P3VQUAcFdVFQMwUdRkELKGiIglZTUL/5qdv81EFJHZTURUmNlHQYJS2gpH7zU7f5qYOiOiiq i6KaKeowilpgdtpmdkqbndZR10az0ziFtVPYCgrroLAfmZvS5qZeSttIaeOU1k5pKyhtLaV1mZvW mpvWUtzpFLeK4hbE79z3cvyufY9QXI+5qcPc1EF5p1PeKso7gvIWxD9r//2U9Xnz1xfsf8CxX0Qf pX4pPIwCD6PAIXNTt7mpgxJ7KLGHEpsp8bDIWgrcSnF5ipujthK19VafR7xgjnnRpP+S7b/0er+3 5ClqjppK1NRLQSXqqXjJGLXkqaVEKSUe0kslY5RRoIwCZczxjgLvWEcNeWooUUKJZ/TKfl72SzJf 4hW9sj4m0yX+UPGGMRku8YYSXyjxhV6eMCabedksyWRJJntlcUzmCjJXkLk5mSvI3DrZystWSaZK MtUrOwXZycvOnOwUqpPt/vrPy0pBRkrV2l/n9R1Yb9+d1rscd59jeu1P4rOOecD2L6LPMV+yphzz Fcd81f7+sBQZqtX4VhG+W33n1ff31feYaGdEe6P67hHxDhE/XX0XavWdV99j6rvi7BkZ2CgDPTLQ LgOnq++8+v6++h6TjYxsbFTfPTLSISOnq++M+h5T32Oys059d8lQu/rOyFKH+s6o7zH1XclYt4yt U99dstYua4eq74zMdajvfvW9UX1vlMVuWeyWxXZZbJXFQ9V3Rn2Pqe8xGe2W0XXqu0tW22X1UPWd Ud9j6ntMhrtleJ367pLldlk+VH1nZLqj9tRnTH1Xst6nvrtkvr321Kdb9tfJfrv67qKAdvW9R31n DnjqM6a+K4pIU0Sf+u6hinaqaFTf36eM7tpTn43qeyOVpKmkl0q6qKS91ikqT33G1PcYxaQppk99 91BNO9U0qu8t6ntMfY9R0BgFjdXujTooqJ2Ctqjv76vvMUoao6Qx9d1LTd3U1K6+M+p7o/reSFnd lNVNWe2U1UpZh6rvjPoeU99jVLaOyrrVdxeltVPaobWnLhvV90aqS1NdH9V1UV071TXWnrqMqe8x CkxTYJ/67qHCjsgfV39zdE84R42ztWfT+59F30qZ68wVj5srduEJc8Ru3WVOZ3mS2srWig8875i9 qMwZ+59DdlPjamrspsRxShynxBwlbqPEbkpsp8RuShyixHFKHKfEDZTYQYmrKXGIErsocYgSxylx nBJ7KHEDJXZQ4mpKPIYShyixq6bEUUocpcQOStxAiWspcRUlHkaJQ5Q4TonjlNhDiRsosYMSV1Pi MZQ4RInjlDhOiT2UuIESOyhxNSUeQ4lDlNhFiTlKHKfE8dqdegclrqbEXO1OfQMlrqbEDkpcTYlP UuIQJa6o3amPU+J47U59iBI7KHE1Ja6gxBwl9lHi9ylxlBJHa3fqQ5TYQYmrKHFF7U59nBLHa3fq Q5TYQYmrKXEFFY5S4Wj1+d+1lNJFAZVnfzdSQDcqPnaz7Z+mjh7bb+X8tzn+dqyjiDuwXpe5Uwe5 S2e4m6Lu8bl7cV+4gfJ6KK+D8lZT3mG1O/JRyhs94HlfB+WtprxWystR3jjljdfuyDdSXgflrY58 luLmKG686n9PUNJuCpoLB6mrj7rWVqfX53SX53WZvXjBMS9Wp9k0hW2gsLWUNUZZOcoapKw+ylpL WXmK6qeoQYrqo6g8RW2gqDwlDVFSPyUNUlJfbZrNU9IGSspR0gwlzVBSPyX1UVKakjZQUjMl5Slo iIL6KWiQgvpqU22ecoYop59yBimnrzbV5ilnQ22qHaOYQYrpo5gCxQxRTD/F9FHMIMX06V7HUEye YnooJk8pQzWlDFJKX00peUrZQClbKGWGUmYoZaj2pDpNKRtqT6rzFDJUU8gghfRVFXKVbtRhkr0a nXzpGp3pWkrokt3fdLsttWc3g5TSRynrKCVHKTOUMkMp/ZTSRylpStlAKcdQSp5Chiikn0IGKaSv NvVuoZAZCpmhkCEKGaKQNIVsqD0RzlPGxtqzmkHK6Kv8TUdkWV1rZFk0Gzk1ujuyNDoXObX+6MjS hnsjI/O/EbkvkjjgiKXVPU9EljW8EFkWi+BQvA3H4EScg4vw8ciyeCduwjrchwfwlciyyKLokWFj 1L1L9F1IuUv/u3A6+jB+igA7w+mGZ8LGhj14Fi9z1itxPX4Snhx/ODx5fiScnl+Hd+BonIgmLAun Fz6DPXgWz2FvOB05pG5nGFT+K3J10BY9Kfyr6LJwffS0cCB6lto4LxyOrvF6bRhEPwZ9Inp7mI3e Ea6v/PVJ5FznvMM571BJe5z3Dt+yJ/oeU8XScHv0VKtZJ3pVuCvaiRtxq2+5DXfgTu/vs/aGQcO4 O4yC9RFsxzPhDte5w3XucJ07YmeGxdhZ+Hm4K/YLFPAItuNRFDGDWTyGHdiJEh7HLjyB3ZjDkyjj KTyNZ7AHz+I5PI+9eAEv4qVwV/z9YRD/AE7FcqzAB/EhnIaVOB1n4EychSvDHfKzo+6NdcVwft1j 2IHdkca6pyJr6p7FXu9fwIvhprqXbH/Z+utIY/TwyBrRTYhuQnQno4vDTSKciB5vXSJqJ8lLs9cr qMVPj64Mk9HT4SdHV9ne4jPnWs8PL41eYP1w2By90OvV8rvGcR+x7aKwpZrbi62X+J4229u9v9S+ j7urvwyf8JnLvf8krsCVjr1q395oJ6517HU+c6PXN1sr2b097I6u95k7bbvXts+El9afGlnT8Jfh pob/jr8PL234MfJhsmEaP8czYUK2E7KdkO1E7MJwU+wSXGH2ofDYVejA1ejENbgWXbgOKiB2A25E N27Cp3AzPo0e3IJbcRtuxzrcgfVhMnYn7sIG3I17dD/nHrsP1Bn7DJL4LD6H+/F5fAEP4Ivow5eQ wh/gy0jjQXwFX8XX0I8/xNcx4Br/c2RFbDByduyPrH+MP+ET34hcFRvy+pvWP8Ww1//FsRnrf/X+ v1n/zHEj4aWxjfgW/hyb8G2M4jvYzIf/AmIfG4P4x/4HsvgrjOOv8V38Db6H7+N/4m/xA0wgF7bE HsL/wg/xd/gR/h7/gB9jEluwFT/Bw/hHbMNP8TNMIUAe0/jf+Pm+vbFfoIBHsB2PoogZzOIx7MBO lPA4duEJ7MYcnkQZT+FpPIM9eBbP4XnsxQt4ES/t2xs/lve+G8eBT8ffEybjJ2EplqEZ/wkn4704 O7w0vgotOAfn4jy0Qp3FL8CHoc7iq7EGH8FF+CjW4mO4GJegDe24FB/HZVBv8cvxSVyBK8MEB0nE Pxduiv9BuCkSrVb/re7fjqz8Gwo8Yw2/WBOt57Tz0IDFnPf46r3dpDpuVMeNPjGuBotqsEhzjTTX SHONNNdIc40010hzjTTXSHONNNdIb4301khvjfTWGGngRIVok5+/JHyYx383eg5HqLjAujCIPFFX dC4zPGwWj3m9I7LmlX/fo26v1y/gxXBr3S/Dz9X9yvoy9nkdmvSjpv768Jbo66zzrAdZG6yLrcej yTUsCffyvU3RpV4v81M5cLVXrXSdZ2GV9y04x/5zxeF8Z3uh96vtW8P39nve/l52MS6pel0gRs1i 1MzrCq/xuiDaoftfgy5cZ//11hvQjZtws22ftvbglkii1iM36XCfit5l2924B/e6f15iTvjL8CE5 eIgPFvhggQ8W+GCBDxYaHrV/FjsjS3lfwPsC3hfwvoD3Bbwv4H0B7wt4X8D7At4X8L6A9wW8L+B9 Ae8LeF/A+wLeF/C+gPcFvC/gfQHvC3hfxX8CWmimhWZaaKaFZlpopoVmWmimhWZaaKaFZv4T0EMz PTTTQzM9NPOfAv8p8J8C/ynwnwL/KfCfAv8p/D/wnYDvBHwn4DsB3wn4TsB3Ar4T8J2A7wR8J+A7 Ad8J+E7AdwK+E/CdgO8EfCfgOwHfCfhOwHeC2C/F+Fd4Gb/GPoSRpfEI6hBFPV6HeTgIDYghjvlY gIU4GK/HITgUb8Ab8SYkcBjejMPxFrwVR+BtOBKLcBTejnfAPBl/JxbjGByLd+HdOA6NOB4n4EQ0 gbb4V4F/FfhXgX8V+FeBfxX4V4F/FeKnOOZ9kaUm12JYNI0UTSNFE0jRBFI0bUybNqZNGdNq+zlz W8ncVjK3lcxqJV16Wpee1qWndelps1jJLFYyi5XMYiWzWMksVjKLlcxiJbNYySxWMouVzGIls1jJ LFYyi5XMYiWzWMksVjKLlcxiJbNYySxWMouVzGIls1jJLFYyi5XMYiWzWMksVjKLlbjiNFecNqnv NLsuDZ/mAcPcKKneN6n3rDofqLpSPcfIqf5NlUmnbo0rP7Ruhu/M4jGvd2Bn2FT5V3sOmMkOFZFD eVVr3Us+9cuqV7XW/drrfVWvauJV47yqiVeN86omXjVem9kWieIiTlnmXT8UzUX864fOIuU8K57V wrOSzjdlXlsfPcO5nuncV9nW4vW51lbHnR+2mtsGDpjbLq15WLI2t6X42Kba7NZidltvdhvmZ8kD ZrdWfpbkZ0l+ltw/u5nzOlyDOSp6jbUL14WD0eutN8AMFe223gT3X9FPW3twazhVndxvdz7rqtN7 Y/Qu2+/GPfz2XsfWpvnqvLck3MrrfsjrfsjrWnldK68b5HWDvG7wt6b9Rx0rHw078Uy4iMoWUdki KlvEB1v4YAsfbOGDLXywhQ+28MEWPtjCB1v4YAsfbOGDLXywhQ+28MEWPtjCB1v4YAsfbOGDLXyw hQ+28MEWPtjCB1vMgOvNgOvNgOvNgOvNgOvNgDkz4Hoz4Hoz4LAZcNgMOGwGHDYDDpsBh82Aw2bA YTPgsBlw2Aw4bAYcNgMOmwGHzYDDZsBhM+CwGXDYDDhsBhw2Aw6bAYfNgMM8OFmbAZftnwHdV//2 DNjGg9tqM2Dyd8yArTy4lQe38uBWHtzKgwd5cCsPbj1gBkzy4iQvTvLiJC9O8uIkL07y4iQvTvLi JC9O8uIkL07y4iQvTvLi5L/tDGgO/wUKeATb8SiKmMEsHsMO7EQJj2MXnsBuzOFJlPEUnoa7ZU7S yEkaOUkjJ2nkJI2cpJGTNHKSxpjajplFYmaR2K+hvmPmkXgEdYiiHq/DPByEBsQQx3wswEIcjNfj EByKN+CNeBMSOAxvxuF4C96KI/A2HIlFOApvxztwNN6JxTgGlXn1XdZXZtZGr4/HCajMr01WdacP DOoDg/rAoD4wqA8M6gOD+sCgPjAYP8Ux78O/7o52EeddFDm+bo4jvXInurLqZJW7zvUcrKXqYBdY L+QSqznGGq8vcvdqAuZaV3OTb3GS+ao4rXK7VG6Xyu1SnWkV2aUSR1XhqCrcojKuUhFXqYivxYbC GRVxu4q4PZbxen8lLKtWwrfDUZ1zWW2qXy5Cy0XlwsgKnj/A6wd4/QBvH+DtA3x6mE8P8+mARw/X ptpN0ffYtxSn4hx+fBXf7Kzc49bub/d7X7JhPBzgVcO8aphXDfOq4diZ4UDsLLinpeckPSfpOUnP SXpO0nOSnpP0nKTnJD0n6TlJz0l6TtJzkp6T9Jyk5yQ9J+k5Sc9Jek7Sc5Kek/ScpOckPSfpOUnP SXpO0nNSfoblZzjyZ6bx5gOm8WbTePMr/8KbabzZNN5cm8bvPmAav7s2jY/rcHfrcOM63N063LgO d7eOltXNsqbxRPXu4qTwD3SuyqQdyPHVutNEdbq+1LaPO+YyfML7y23/JK5Ah23XoAsmWBN1wkSd MFEnTNQJXScwUSdM1L+Zpu/y+m7cg3t1jCWRhO6S1V2yukuguwS6S6C7BLqLjmL/LHZGEhx2jsMm 6CjBYROm3AQ9JegpwWET9JSgpwSHTXDYOQ6boKsEXSXoKsFhAw4bcNiAwwYcNqC1gMMGHDbgrBOc dYKzTnDWCc46wVknOOsEZ53grBOcdYKzTnDWCc46wVknOOsEZ50wiSZMogmTaMIkmjCJJkyiCZNo wiSaMIkmTKIJk2jCJJowiSZMogmTaMIkmjCJJkyiCZNowiSaMIkmTKIJk2jCJJowiSZMogmTaMIk mjCJJkyiCZNowiSaMIkmTKIJk2jCJJowiSZMogmTaEI9JUyiCZNowiSaUFsJk2hCfSXUV8IkmjCJ JkyiCbWWMIkmTKIJDhRwoIADBRwo4EABBwo4UMCBApNowiSaiNzxW089V5hpVlafWQ1wjgHOMcw1 kmaclBknRUkDZphUdYapzC+VWcUcQgEDFDDw2qejZoeU2SFldkiZHVJmh5TZIcV1UmaHlNkhZXZI caAUB0pxoJTZIWV2SJkdUmaHlNkhZXZImR1S3ClldkiZHVJmhxSnSr3aq78ZOZuKzqac46jmKKoZ oJoBqhmgmgGqGaCaAaoZoJoB/TSln6b005R+mtJPU/ppSj9N6acp/TSln6b005R+mtJPU/ppSj9N 6acp/TSln6b005R+mtJPU/ppSj9N/Uf2UwpZfoD7LnvlCXXkDQ0viFIEh+JtOAYn4hxchI9Hrop3 4iasw314AKnqE/Kr4n8YWWaaXxnupYu56EXV/x5oDT8x10deZ3tgVv6BeecH5p0fuDMom9b3VJ8Q TOpFQe3YyXoarKfByPX0tqk2iw9Hz3O/fj5t7b9/SDl6BTfr9HM2cbT7aXCABjcd4GoprtbJ1Tq5 WiddDtBhqqGStyvcu16Jq9CBq9GJa3AtunAdrscNuBHduAmfws34NHpwC27FbeCEdLeJ7jb9Xzva P3WzFF2m6DJFlym6TNFlii5TdJniZp3crJObdXKzTm7Wyc06uVknN+vkZp3crJObdXKzTm7Wyc06 uVknN+uk6wG6HqDrAboeoOsBuh6g6wG6HqDrAboeoOsBuh6g6wG6HqDrAboeoOsBuh6g6wG6HqDr AboeoOuBSF30HJ5x9itdrfr8Z2X1Xil49TnPRQc826l0nit1g1qH+Hd5pvIvdYt/w2cakbdQ8aba XWLw6m9tLscncUW1VwWyG8huILuB7AayG8huILuB7AayG8huILuB7AayG8huILtBpMFMNFGps1q8 K3UYvFpzZ8jIpIxkaxmp3IVP1rIx+TuyMSkbk7IxKRuTsjEpG5OyMSkbk7IxKRuTsjEpG5OyMSkb k7IxKRuTsjEpG5OyMSkbk7IxKRuTsjEpG5OyMfkfmo163jInG9VM0O5pkcbqtsnatslX4zVRi9dk LV7ZA+KV/f8sXlnxyopXVryy4pUVr6x4ZcUrK15Z8cqKV1a8suKVFa+seGXFKyteWfHKildWvLLi lRWvrHhlIy1VP17JZ8+r1nTld1Zfr84BlXhVnufsj8wmkdlUi8wmkdn07+K3I9iIb+HPsQnfxii+ g83h19XA1/9NIzSvqqhzXu1nk7Xet19PczpbVmfLRi4UyaxI/iB6erjb8QOiWRTJ3Sp2t0j+OLo2 0iyaU6KZjbbZ9gn7rwynRLQookURzYpoVkSzIpoV0ayIZkU0K6JZEc2KaFZEsyKaFdGsiGZFNCui WRHNimhWRLMimhXRrIhmRTQrolkRzcbWh7tjd+IubMDduAf34j6MOI+N+Bb+HJvwbYziO8iFUyI9 JdJTIj0l0lMiPSXSUyI9JdJTIj0l0lMiPSXSUyI9JdJTIj0l0lMiPSXSUyI9JdJTIj0l0lOVThNu EtnfzA7ZWhWfE1kTaXAftbVud/V3H3vdo9ziHiWo/VY8E3m/+bRsPi2bT8v2PhdVZe4bZ2u/9S5H 7/O+N5xsKOARbFd5Pw/LZrayma1sZiub2cpmtrKZrWxmK5vZyma2spmtbGYrm9nKZrayma1sZiub 2cpmtrKZrWxmK5vZyma2spmtbGYrm9nKZrayma1sZiub2cpmtrKZrRx/fzgZ/wBOxXJwpfgH8SGI QHwlTscZOBNn8a4rqr/Rrvw7DLN45Tfb//S32kHtt9rBq7/VfmV63//b44nqFH+zdf9vj7PR9aax ytPFe237TDhcfZqYDyfc2024t5v4D51u3xNOuK+ZcF8z4b5mwn3NhPuaCfc1E+5rJuJnu/tehRac g3NxHlpxPi7Ah3Eh3N3E1+AjuAgfxVp8DBfjErShHZfi47gMn8Dl+CSucKdfV4lc5DCaLL7628Co en4dDsJ1lHczbvX63nBWLGfFclYsZ13PrOuZdT2zrmfW9cy6nlnXM+t6ZlXAtWEpqltUfuNIw9+N HPvqM4XKv59frv4lw9K6p6v/3mWj3C+te87rF8NxOR93HoPOY9B5DMp95X5/2rlMR2+JHCXXqoIm 7qie13T9yZGl9e/FqZFE/YWRRuc57Tynnee085x2ntPOc9p5TjvPaec57Tynned05DhqnKPCOSqc o7456qv85UmR0ooUVqSoyl+PFCmnSDlFyilSTpFyipRTpJwi5RQpp0g5RcopUk6RcoqUU6ScIuUU KadIOUXKKVJOkXKKlFOknCLlFCmnSDlFyilSTpFyipRTlKV1lX/xpeIUkbOcbdNvns14vQM7w4fE 8moxvNoVNLmCJnEs1uqnWK2faLhVPLeK59ZaLbW5wjZx3e4q28R2e7WG7vT63nB7rXa2i+N2cdwu Am0i0CYCbSLQJgJtItAmAm0i0CYCbSLQJgJtItAmAm0i0CYCbSLQJgJtItAmAm0i0CYCbSLQJgJt ItAmAm0i0CYCbSLQJgJtItAmAm1yuF0Ot8vhdjncLofb5XC7HG6Xw+3V2AxEPig2gZgEYhKIQyAO geucdJ2TrnGSGrfU/o6o4qoTrnXyn3HUSdc66VonXetkrLLtURQxg1k8hh3YiRIexy48gd2Yw5Mo 4yk8jWewB8/iOTyPvXgBL+IlDvmvcdQ3H1BZgzI9KtOjMj0qu5tldnPNITfJ7GZZ3Syrm2V1s8hu FtnNIrtZZDeL7GaR3Syym0V2c7Vf7f8rrz8N/zr6F+GuaDZ8Orot3Fv9K66jon/EHb6BjJ+72foz FVpQkQsjJ9QfosK+yw0mwsF4DltQcY5foIAZ78vWl8Pp+VEcBNU5/zy0Yi26wumFM+Hswlk8hh0o cZcjo6lwR3Qo3BMdptsMTf+Z19/B32BKBe/Bi+GueDbcE/8e/pZWfmCdCLc6m63OZmv8J+GO+MOY 8Xqn/SU8Fe6Zvzicm38MjsXF4a75l4S7IodGHwwXisJgdFOYi06El0d/uG9WJHLRIDw3+qgIzYQ3 RUvhzdHdkZOjT+0rR5/mYi+Hh9cvDBfWHx5eE4lGs5Gjo3ORo83yD4rTbjF6R+Xf5BfFraK4tRrj yrVsxhT+d3iZo65xLVvrRac+Xoms14eEM/Vvq0Z3629dz8/xCxRQuaZyuHV+Q3jZ/BjegMXeH4Nj 8S7vz6xGe0a0Z0R7Zv6V3l+FjmrkZ+bfWo3+VtHfKvpbRX+r6G89OBJOH1wHWTu4HvP46LtdRdlV lGWlooecjEzLyLSrKcvKbP386plP178RR6Dy+4is/H/XHPE96w9c0USYczU5V5NzNWVXU3Y1ZVeT czVl2Zmdf5qzO9sVnPtPtTL/Nmdo5nHGZWdcdsZlZ1x29/mn4XfE//Bozhn90BkFznJ35NzKfxdb zceXKbssX1sil9cV95XqHsMOVHrVXusL+E1veqj61yYHVf+dkzN9+oToV33f1zAg839Eg9/AN/2s YfWy2eu/tv173suXn39C9O/4zhbrw9afIvBdvISCdkV5SZSXRJ8KD6fha+R+Tu7n5Hwu/hci9ZfV qFU0/XT8R17/w74yLZ9Jy2fGp7x3bXG9WgT3iOAeEdwTf8T77SL8KIrY6bMlzPls2f5n9pXnR8LJ +XV4fXjC/MOtb8c7cDRORBNOsm+Z9WTrmdX6uEZ9XEM7c7QzRztzdDMnC3tkYY8s7JGFPbKwZyH/ W8j/FvK/hfxvIe+jpTlamqOlOVqaO7jy/5RRL1sPcZvnqvWReOW37OJ8mT0ZFZixd8f+KhTDbeH3 alX4OVV4tBjeIreN4ne0Kvxy/ZHheP0i6ntHpLH+6PBnlVre93/IOxv4KIr7/8/M3u5xeyGAouAT ik9EAaWhUKonKmp8APXE+BQ0PnAqoqL1oY21QI3+Gm1RC9b7WRttrJYifUKNraJSH4LGKsEH1ERB SRSCckIINGLE7O89c3vJ5XLhQaC2///u63M7uzs7852Z7/cz35nd291Iey8khX7Y8UxSKCSFgaqB VmpkuxpNWcvxJo5vapuf84E3Oeczb1ROwivP+dIbZZ6DmEpfM5W+Zip9zVT6mqnogpbxenRhMbqw WN1P+CEY43fmTQkzsYhyLKIc2euMtj3D+efYX8D5VwivRf5N3jzLQuYDvZm09WLaWltJORZSTnvP xErKafPFode862nz2bT5bNp8MW2+mDZfTDsvpp1n086zaefZtPNM2nlmKEH8tVy7zrvePdOb6d4A bvJmGoY3d3ao2ZlIVk9dJKiDhKn7oLqHmngKRkuIo9UmMTi0Qsx1DxFx92oRFw+ou9vqTF0mtb4Q rS+kxHWUWLNZP8MBf6FlkjxQSKnrjCU8x3YBcV4ivNAbrl4Gr7TNU9XU+WuEXweLQE3bfLWY7Rvg Tc69xfZt8ltC+B3yfo/ra0Edx99vm6o+YLsULOPch2w/Ass9perZNpD+x2w/ASu5vpE4q5DpUwAX q885vgasJc+mtnq1nvCmto8tq60OCxyOBQ6Hw0qtMKO1HM+Fx0qtfpzfk+1enDuwTXNaqTXIu5kW 0+xcSKvVGV4zFtpWF3oTfMDxpWAZ+IjWWg7qQdISC2mlOm2NoWZveKgFfAlawSau/ZptG/C84a5o m+lKoNrqXBvrddgG26a6PUBPzue2zXd7se0N+nCsn1fo7kN4ANiX8H5cOxAczLlBHMsDh3jl7qGk NRgM4dxQMIx0vsO5fMLDyWME+8d4pVj/cHi4FB4udc/k+ET2Y+BScLl3szsJXAFu4NwPOfYj4t3U pnuUQpihEGYohBkKYYbCnHVtM3OawXqwAbS0zYQZhsMMw2GG4TDDcJhheM+IN1x8FxvTtpVA00ag aTX0NoVo2mC0bLBvVwk0bAQaVoNHkuxLdR/qeuW0XoJeqJzWm0fLzaPFymmxBC02gtYaQWsNphcq pBcqxMYS9ES6lWpopRpaqYaeqBBbStBKI7ClBJ7LYjyXxZ361uHgGG8etVNO7cyjlyqnlyqnlyqn ZhLUTIKaSdBj6fe+lDO6eQB7qDA2UpfyoTQHoUNaX+rQlzr0pQ79qMv0l6jPOuqzjvqsoz7rqM86 MQGLrpcbhSs3CRdeqqeuGuGgRuqqjrppVC+JXFUN3gRLwLt4iCvZrgKfgtVIpe+BfMm2FXwFvmZ8 JYAECgSADYKgB8gFvUEfsCuAu63dQX+wBxgA9gUwi3UA0PcEn/IaqfdGuK2Req+j3uuo8zq4rR5u q6e+dV/VCIc1UueNrhC5rgT9wL5gPzAQHOC9R/2/R/2/5w5hfyjIByNFX3cUOAIcBUaDY8EYcBw4 FUTBeFAIzgITwMXgEnAluArcKPrmrBO5Oc1gPdgAWkRuT9IUl1HDzbRhgjZM0IYJevcWevYWevaW ZM2yXQU+BVtbq47X3F6zIcKu17jFGt6LeFlqGS1vRJcS1GoztdqMTiXQqQQ6lUCnEvT8LfT8LXBE C9zQQq/fQq/f0rlW2R8K8sGWavV4vOgCWmtLtTuReDFwKUirafiiGctoRLcT6HYC3U6g2wl0O4EX 0YIX0YIX0YIX0YIX0QJXNMMVzXBFM1zRDFc0m5bZhZZ5wXjb9+uex/h+dfhdi+lrF+NbNWHjWtde oFZewK5hXqwqF/sdBkaAc70m/JsmvIl76KXv56qHYJmH2c6mH3oUX+ExkGSdxVjWYHrwxfTgdbRX mfYuYZuZsE0ZbFNGr677iDK0fjBaPxi2GRh6qW1jqAq8pr14tg0gQXgt59cZJimjLstgkjKYZCZM MpMeXPu8M2EQ3ZNrv7eM3rxOKM3g2ksRYUo6T73awSehLzK4IwfsmeQQYTPWoPcAPUAfcLA5+pKp sUnGW27wGqi1EfgE7+MDJ8QI4s8n/nzizyf+fO0XMBZ/jyslV5WLgPFqktcmtHcjHD3XRKpL/FTr 8DQ+4swksZtcg6dNq8hmtuuNl7y4Xf5a6lePK0dQnyO9eZ3KYntrOpXnUPYHA12ugHnK8yUkSOal 7/xqyQ8Rc8UB+HA5+HA5+HA5+HA5+HA5xG0g50IseCZ6MgIrnokVzzTv0mmgP8GfwpLLseTy5EjP /HeKnhjkEu4Hp+8L9mN/IBgChoJhnMtnO8IbgQbT24H1YANowQ/T5a+j/HWUv47yp8qdoLYXUvbP 28u+yfvcL3fClDvoLaQVFtIKC2kF/aaxBOVPmPKHYJ9mUmmCdZq5ogmLbsaim7HoZmI2EbOJdn7X W0aMZZxdxtllnF1m6m4xvnMzPvMGMz9t6/Fb5pgLTdvorUHbN1g9GeUd7G1AWze4JzNSO5dWOA9M IXwN+JG3Ad9+EyMa2ooxcZOQ+JFzhWR/oflNoDnYj7Dw15ut/UzeLeZLP/VC6Xku5EnGGYxtE1O1 GWubR/5rsLI1WNkarEz362vcI431rEGeNVjPGvcM9s+kPy5mewPbH3HsJsZ/OuVyUt6gUxaD8Xg3 eYWkmgMHl8G92o5HIG85/KptOMcaIc63Rorz4bkyUsyBx8rgsTJ4rIyUc+AvbY858FIZvFQGL5XB S2XwUpnoaZihF0ixAoyQYeVl1HAZNVxGDZdp6xa5aTMAdXr0b0bv6SN2RutZR+ZB2mcFea4gnxXk sYJ2WUG7rCDdFbTHRq+eI/Ucqac36mAv/c6o+chZjJzFyFnss1cxshaTTjGyFiNrMbIW+4xUjLzF PiMVG0aS+g1UQlnnohsTvNW07LloygTvbesCrQ3+8c/YazGxVppYIavQq7fO8lZbZ4NzvAbrPG+V VeQt5+zvrPO9L4j/iggQ62OOruXo+xx5Bw09m71z0Bt0j6NVHG028Vo4cidxPzf56pw+1/ma0CeE qAlrMtdcRS97jdfA3lXeK4RqrB94K83efGsKaeuvEUr2PhdBa5K3zrqCep3svW5d6b1jXU34Gu+X XPEe6V7DkR94NeR+BfU2mTJe4/2MI++S2iTkucq7nhTLiXkV8up0tQT6uE6FUbD1IHniFVoPiUHk +YhXan7rRG9nrFjgjBMFzsMi33yr7F7Q9Rtlc925Iub+ne1TbJPfJKsx3yILmO+vrjRfU60ltaj+ Mhv97i/EAP9rW+XmTdzJN2ZLYhTA3WtETK4VcdnMdr2IYwVxrCBOzLWMiNeLfKHCo/wvwPbc6i/f 1qd9/dbSb/gndyd8BBLofPPF4eIOUSFmkM8sERNPE54PngHPigolRMzeKIvtL8FXIuYERdzZQ1Q4 e4IBYq6zL/sDCR9OeDTbAlHqnAgmEp5G/OngaTnJeV6eEuwlSoNTZXHwFnldsBTcTs3dKkrd+5Dp AVnsPggq5CT3ITBHVLiPy0mUtyQ8WsTCp4Px8rrwBBEPF4uZ1MFb4YuRuq/4B2V4AbwIXgJVYCF4 VeQHBot8JxcMAnlA7w8BY5HwSralIp921G0Y020YvoDrdpOrTTuUUuOlqp8otY4k9vZqhOJslDNo AqEi4um9IuJFRY69UcywvxQznKfFjOBUcIuoCJZSAw+IGe6DoMKrdR8Cj3u14fG0TJArIsSKEiva 6fvS40nP1v+E5kgpR0o5EqO28oSV/uU5E6d9jzhFxCkRA8VvuH4T+Bq0AU9EA2PAceB4EdX5ImnE sUXUOQKcAmaBe8B94LeAklKKDvnu9SZTV5Opq8mUKEKJIuReRO5F5F7kNoqokeBM8629KUhxR7s2 xtHGONoYRxvjaGMJEsSRoMJo4x5o355ggNeCFsbRunhK65CgAgkqkaAyeDs+tdEyESf3OLlXknsl uVcmNUvMRbNK0Cz9VcBqNKtU9Cf3GeQ+A50vIZcZ5DCDHGakp0yKFaRY0Z7iHDwDneooUh1NeY4R M8JRUz6dQ2mnHLTFl6BpJVh8CdpWYr55+BRlPU4ORwdHgJHge4D05PfBGNEqjwcngAJwIjgJnAzG gQkwxURwGXEvB5MJXw2uAdeCH4DrwPXgBnAzmAqmgZ+KiFwF/3wGVouVSNeKdK2yScyV60Q1UrYi ZavcwP6/RDW20QpHVcNR1dhIq7VQrAygbYEzQSE4C5wNzgHngvNEa+AKrPIqgEyBKQB5AsjjvCda nSZajjwc8ggOpAX3BwehBf0pdZxSxyl1nFLHKXWcUscpdZxSa2lLkTZu2JNUkDaGtHHNokgbQ9oY 0saRMo6UpUgSJ8c4ucXJLW6+YPARTNlivqNwoHS8yXI/MBDsDw4AB4KDwMFgEMgDh4BDvVFysDcq cII3OVAATgQngZPBKWAsGAdOBaeB00HUm+y8Cz4EH4Hl3ihnDdu1wPMmB8k/2BP0AxO9yfQncCcl LXWeR/96YSN5xkY0a2exEZUj5qreoK+Ym7KXNFtJ+Kwddw4nPJptARp+IsB+9JsU0Oy52EwCdi7p YjNzsKXOGl6SZj9T0O5KtLtEXCtuo+1+Dof8AladAe4kfBeYKwaIP4KnwXzwHMcWgH9w1fOGzUtg 8xLYvAQ2L4HNS8TLHK82rF4i/knc18EiUAPeAO+QVwO96ArirESXbVp9Fdt0zfA1gtqppHYqqZ3K VB9rtGKwKAnQOwSmi3ybPtheD9AeuxXegxPN10wlOhpmm2s4YYCzF+F90d+BhAdxLA+QDr1MiTPM fP003zmSbfILqHHnDK7HPhzsw8E+qPEBTozzl4LLwOVgEsBO6KFKnKsIXw2mgGvAteAH4DpQyvmf Ea8MlLM/G/wBzp0C04Xg3RmAOqe/Wdr+NdW/E05+STXqvmi+njolDNeETwT4KeFx4AJRkvNT6tFG 6urMXk3sJRab+o5T31HqOAZfxPR3yqjDCvtrU+aYM1b2p7yVzmmEYVjKHcf76YtMMWSKkWorqVYj k+6BCki9ldSrkSuGXDG3SsSQISb2JOU4LVhNC2oGqqYFq9Nb0Nh1qhWx72TuHbWdpRYKstWCyCWn qO+Dlfo+mO7/C0g9RuoxUi8g1aIuNRISvzZfka8SX4JW8JX5enmVc6/5crn+WnmVyO30f5nfidIe D4NHREkP2kz/TyZ0oCgIHSRKQoPElFAeGCKiocNERCjzH7Q/ENr1G90l3eiNSr9TymhkFKORUYwO D8GmHM6Xp48aOV/O+XJx6DZyTNz0lN3zzAx4Zgo8M8XwzNQuXDMljWvmwjVz/d50LlxTZLzAY8RN 2v/J6KtLRAgJCpCggBSLSLEowwPS3s0Asb8pT9eylGaUpcLwZeeytPsXXfyKTA/gcfEE8k705Z2R 4VssMPJmlUQm6KUypEGKDi8nVZNZ2HozLF20WUnOhqUjsHQEdo7AzhHYOAIbR2DjPJg4DybOg4nz YOI8mDgPBs6DgSMwcAQGjsDAERg4AuNGsKApWdi2gtJUUJqKTFuFMabAunmwbQS2jcC2Edg2AttG YNoITBuBafNg2Qjsmge75sGuebBrHuwa8dk1gr2vxDJLfHaNwK4R2DUCs0Zg1gjMGoFZIzBrBFbN g1UjsGoEVo3AqhFYNQKrRmDVCKyaB5tGYNMIbBqBTSOwaQQeyYdH9Hih2ucRzQDV+vvTMGgEBo3A oBEYNAKD5omcdj6BS6iFUmqhlFrQnKK5JNaFR/b37a0iUzO60UltXxVGKzpGXZn6mdiChzoFraj0 PdPS9lHV3n6/udWsq/tP+scC0yKd2TdVa0n27WDefJg3X9ee6Wt6k2NBF/bNgWd6g75A11oHE+va q/Brr8LUnsuIuGqrmHgwo5wiRjlFjHKKGOUUMcopUjkyV/UGfWUuI54iRjxFjHiKGP0GGP0GGPEU MeItYKSrRz5FjHyKGPkUMfIpYuRTxMiniJFPESPcAKPb/sFbCd9OXzPDjDtaGdn2Z2S7KyPbqPsn 3evJfRj5FNEO1bRDdRj/lhFQEW2xlLZYGr5Q7k9brGS8mGJDzYQXYm3SfH87kDGCKxAn+x5XDFuO YcsxbDmGLcew1xj2GsNeY9hrzPTgb7BN9eJJb6lzT97ZA4phkzHTuyc9oBg2GcMGY6a/PTJ7j9/J 04mBSwEjE2wxhi3GsMMYdhjDDmPYYQw7jGGHMewwhg3GsMEYNhjzPZrYtnoQaZ5NDLtMehTSzMdc Tl1FDe91eKeZ/Bf1vdEoHBiFA6NwYBQOjKZ5o9FsXEi9lnbyRqXoSx1Hu/FG29k+06rgxmiaRxql PaK0RzTFkcbiJG2S5Mmo4cl9zXxHFK6MwpVRuDKawZXpnmiU9onSPtGsXJn0QqNb4MtomheazptR nzcjPgO85TPAW+kMQBtFaaNoGndGRSjd8rUXisTRLhZvYfHLUlYg9s7Wp7YzZ3ofms6W3Y/jk/1n R99Z2WX8HjBzR3M75o/Ekd/Wd3vt/zX8q33vAr+FZzhRWkTPV90svmPmrNB0WqOA1ijIMndV2T5G eMKMEyr9ViqglQr8uaz33JXGW475c1oVxHwIHQ/R68Soy1LqMUY9xjhTwZkK6rCCuitNzlmm5rmy z3GlzcmMSs5zcVV0i1ct4KoFXLUAJo22X/V9tKFVzBKVcL2eR2pFK1rRila0ohXuj8H9Mbg/BvfH 4PsYfB+D7/VsZ679FTxmm9nOt9CcVjSnFe4vQntaff6Pwf969NbqTCPudDCL/XvAfQAvn74gRl+Q G5xOP3AL/UGyT5hCn1BEK+hZT7RO5roPggo5hL5hCH1Dkd83DKFviFGi18OnUx/j6Qvg0rS+YSQa 2GTm60wvpnusjJ6qyEia2UuleqikVLlIlZsmVYnpqR40vdX+SLS/kehxtrqnGi9zM3qoIaaHGk39 llK/pXBmDL6MwZcx+DIGX8bgyxg8qUfn+Sk+1LPK6byXMQqP+S0eN/wWROpc6nNPLHYgGEQ4DxAP botRylIsOoZF63HfRsNtE838bgxuiqW4yYwvkn1xKSUsbdfQJC9Vm3Eh2urzU2U7P40ys6pxSj0F bor5cxzae54ihqJhpbRBBI2K0A4RNCqCRkUoofaXVlLClZRwJe0TQcMiaFiE0i2ldEvRslLaKuL0 YHsE21PANMLTwSzC94D7wG/BozDqVLEU/W9C/5vQHm1rSynJUkrSSklakb6VdorAVwvQGj3uaaK9 IkheidTad2hF6kraYBbsmN0HCuADBfCBAp19INGKxK1IHDfape0i3Q+axvHpIJs/dKPXkK5pRsvu g1mSmvaV7xftn+YX9ff9opfxiUopSTxN896nJNW+b/S2GOGXJOqXJNpREtFK3bdS963+/HUnb84v STTDo4umlSR9TrvIzGnf6NXSBq3YTjTDdrSXNyWtVClvrz+lKkgrVdR4e8fTnyRL1cPMeWfa04GU qsKUKFUaIZZ2KlHX0lT4bVJgSjKN/engt75V32cYM1Oy9vpGqhf9uq4wdT2BcUAxSNbzUnHY5u6y +N5OXpq3M4D+r2QbR4Il+m6Nsfhsd2x0v+bfsWm36BlmLuYtv9+KpHkWBWZUpu/mfMfXkJivIbFu /P1YN7oe85m0yNeQWJqGpPN9kc/3mlljPteX+KyaqRkdzPon2ibJ8+la0d/n+pW0wUrN9cI2z+Et 8GrSn5UTijIFGPcIkSt6iaDYRfQTIbGHOIq9seJ08V1xlphMT3ijmM7eLXinReJNkRBzxBqZI6pk b9lHfCz7yj3ECrmXPFqslqfK0zgalWfIXeQ58mrO/UjeIgfLW+VtcqT8rfyjHCXrZaM8QX7KOk4m WE+Va+RarmuW67myRXpyvFIqKM9XYRWWl6ieqqecqHqpXjKm+qg+8lK1q9pVXqZ2U7vJy1U/1U9O UnurgfIKdYA6QF6jDlIHy2tVnsqT16lD1aHyejVE5csb1HfVCHmzGqWOlFPVUWq0vEUdo46Vt6rj 1HHyf9SJ6mT5MzVWnS7vUGeoQnmXOludJ2ep89UVMq6uVFfKR9TVaor8vbpWXSv/oK5T18k56gZ1 k3xU/URNlX9Vt6hb5WPqbhWXlerX6tfyWfWAekA+p36rfi8XqDlqjlyo/qT+LF9Wf1VPymr1lHpK Llbz1Xz5hnpOLZBvqhfVi/JtVaVekUvUq+pVWasWqUWyTr2p3pTvq7fV2/ID9Y6qk0sVq6xXy1W9 bFAfqxXyE9WoGmWjSqiEXKXWqDXyU9WsmuVnaqPaJFerNuXJJktZSjZbjuXI9VYPK1dusPpYfeRX 1m7W7nKT1d/aW7ZZA62ByrIOsA5QAetga5CyrRHWSBW0Cq0LVMiaZP1A7Wo9Yj2i9rEWWYvUAGux 9Yba1/rU2qQGWl4grEYEcgPnqjGBCYHL1Z2ByYEfqvsD0wPT1R/sI+0j1Rx7tH2setQ+3j5J/dke a49Vj9un2aepJ+yofYaqtM+0z1J/s8+1z1NP2xfYxeoZ+yL7IvWcfYk9US2wL7UvVc/bV9rXqRfs G+wfqlftm+1p6nX7Fvs29YZdZpepJfbP7fvUO/b99m/UJ/YD9jy10n7KXqBa7ZftWkvaH9qrrb72 5/Zaa3+72W62DrI32F9aB9ub7E3WENtzpDWU6ulhDXNcZ5g10hnufNe6wBnpHGFd6BztHGPFnDHO cdZlzknOWGuSM9650LrKudh5yPqx84gz13rG+bPzF+tF5zGn0qpy/u48Y1U7C5wF1iLnBecFq8Z5 yXnJWuy84lRbbzivOa9bbzlvOG9aS5x3nXetd51ap9Z6z/nQWWHVOo3Op9ZyZ42zzvrY2eB8YTU6 rU6rtdr52vGsRFAGQ9baYDgYtjYGewZzrS+DvYO7WF8F+wUPtNqCBwcHBXKChwdpieBRwdMDuwXP ChYH8oIXBS8P5AevCF4ZOCI4JXh94KjgjcEfBo4L/iQ4LXBC8JZgaeCkYFnwjsApwcrg/MCpweeD zwcKg68FXwucFVwUXBQ4O7gkuCRwTrA2WBs4N/h+8P3AecGlwY8CRcHGHjmB4h779cgL3NZjRI8T Anf2OK/HjwMP9ri/R1Pg+R6tIWn3Cx0eOsHeNzQxdKU9MvTH0B/to0N/Cf3FPib0WOgx+9jQE6En 7DGhJ0Pz7eNCz4UW2CeHXghV2WND1aFX7dNDr4Xetc8IfRBaZV8Qago12VeGNoT+ZV8V+iL0hT0l 9GWozb7GVa6yb3Rtt4f9QzfHzbF/7Oa6feyb3f7unvZ0d1/3ILvUHeQOtu9wD3cPt+9yR7oj7bvd Ue737V+6R7pj7FnuCW6Bfb97sjvOLnej7hl2hXume7b9O/dc9zx7tnu+e6E9x53oXmv/yb3Z/Yk9 353mTrOfdW9zb7Ofc8vcO+wF7gz3l/YL7j3ur+2X3XL3IXuR+7D7iP22O9udbb/jznHn2O+6c925 9nvuE+4Tdq37pPu0Xec+6y6wP3RfcF+0692F7iv2x+7r7iJ7pfuu+569yv3A/cD+LJwfHm2vDh8T PtbeGD4xfLrdGj4jPN6xwoXhIscOnx++wMkJXxi+yMnN+SDnA6d3Tn3OCqdPzrqcDc7uPUVPC99X jf4uXC+OaRlXJcaLi8X/Y4tX2/GbCnnrWG/wXiOkcbuG1+Kfv2gH5z8LPJjleA2oS4/nzUamed44 s/e5kfPzzaa8oT3UkMTOWbzPwBrw8bZd5c1n/Wyr4y8xv+u2VbqsaSX0akIrk2l6nwBa2PvoG6a4 rrN0XeX0mneU9N3lny31Dr3u9spERwrtafQ1NmA0xmvczLXN2Y5lP9pZWtZVXkNKJ731W5KyWwnW afmTtum3aKL9XKJL7ES2oztqMal/o5KkWilLGyTL1JjSnq4lSPFS52PZj3aKQTt5y71an//WtZdg m+vHm6Y5yZvWpQR+iHx2mt5v7dKZAb0xGWcne47X15tswox1qBX9WyMGmP1aHYYxmthrar8m4X0K I8824fIsOZbD1QnNccK0pW5l1nK/vp/0qrRErOvMr2b78ZuRv4qUakix1qQnvAPTztWmrLX7ejat /bwJabb+J3i1+9y2bzGpvwFWbdNVLdTCsjQd7ZslTlovTX3UJkuz/YvJO8l2unaeod2qAD2Ot3qL 1ya2uW+V31DMnb5QC+/sTE9h5y/eWu9l2m/ttyzF8zsonSRXtHuBaaHsep/FZnbGovkuyUP+kkfO +Wzzu8Rc1vEr8mGpZZr3ODKbUIM+rhlUsx+La2aUUrEz0kk7OqBz6u0x3mad5d3UwcbY9R/5/UeW 9KrwpWuMZ1+zhbI2dPymh7zx3mJ+NcYl4R+ftfn0tnXxzgZXdydX2v4of71oC+npfmK5CU2D4/5p +GuWN9D7RXuMadsp8Sveo96jfrjZy/F+4Y3xKrwsI0etQ2k1e5iPMUk5Db//F3FRpueE11blvbg5 //nfsaSPIc3+ZjzULjpV4z2+JQvpKJ+2M+8fO6u8KW3wnttsrETK0/O5sxGm+c025PKy+c3CQNuz eJW+R6TZ4pPNl6Gjtn3mOczbJWkX2bnIjGR7tV/eV6T3Ank7qgT+soefupshc0qipJ87yo/rywEn 9W7bpHks5SmnMfQ0dKyz1vWF35PplMMPkW68a+NXmxipXBuMt50cL80zvx0jwQZTjwmTtu6r8kRG X5n0Js2iff7eqVCyr6GvyNe/ftzm5G/2ke6/a9m8d+05GfuT2prbPG+SCa/u+E2Gui+HGQXp7aIs 5xbpo4whl3c+6m8/9T7tcsVxGftNnfaq0r2Kts2Uz2+Bden73npvAz6AP4L1qpPYOYsZrS3Jcryb sXPXWZgkS6a4kjps9N4yIa3FLyXHFN4DRm+TZdWhD7Kk/EH2oyl5WM0Y31uZHMP6R/9Efg/jKz/d 5cp5qTFmx7yogRkteiu8D/Vv9lL6KaxsD60y/LuT5ltMHW3zvII3QXsX3gQT/qjjNxVKzQt+m4vR rk5eUaezzxiP+ZltSvFb5KksXsViWP8O3RduYzo7tG28ezP2l28mbkZ/7V3mHa9/Tfhv5vf59nN/ M3bSvY0M6PbMDl2Mlsxr3zuwvTczPgF9suP19ufsZuGnlidXPYLzJnu/9+4ys01PsvdkkpXZn2/O JXlhXJYcq1hrvXGmv46YI7ebY2ZE5F1E+9WaI9NYG3RvSp+83E+9Kl1a/9oxXHMgW5NnpxmvjBFK 8s5Dx/0HHTLc15CaF9czAjtvVqDb2fftGL149eZ3vrkr0SJ24D0cv2Zq063JjMSzeu47jb+3eGdi C9e/yFgjy8h+i9fV+Kjavvz91LKMpvBEsh7dEfntuAUGSPrivbOc0xY6mxi300p5Wi/Yn4kd3uZf ORu91HFuZy3f4ozDrNQMiT/DnsYd2z3XsJ0WgSUsY91GZkgbWVRtrx6Lud/gimzXbGs6c9PwjRd8 SM2sG7YcU/TZwV7IgIyx7re44OUu29FzBtssw+fdzJu+Lcz91k5H307fN/Omia3zrv5z5+Qowz/1 naf/D5eYj+1ftpOL2tvgW+EiI8H29gfveEuyjey3cFWifZxcpUfI27tks8SkfWbe2W9/eqPjeF+z bv2yrQwa2cb4mcsAMwrJ32w6+V3vJO3AZWem/Z+yxLciTrTTnpl/EgU7IN8UvvFCr/WhGKDvymc5 19AxK2b2k8/+7KA+yRv1H+RVtGT229ucQtN2ijAACT7Jku4n5i5GpleRJeY3y9XcX9juNkgyudeU vKeTce5lfRQ9S83AJudj/ZiZc9pbkVcnv8gbY6Tf7pke733vfeNjZ7kD59WY2ff2NvDndlOz7yu2 U3PO3TEl2GweWbU725NrW5neVs9UdH5Kjfpdp5970XNmhCrNbM4s76qOO/neRRxfmSWdld0cbS8D OvgOXtGj3sPew/6RT70J3kPe9d4/vF91uVI/1fRx2h3Ai8BY0f68mteYeTfXLN1YSvszYb38+4O9 skTqlXHvUGSP6a1qf1KwPmkt7bXXddbI7XIklcohbZs8x599Lzd3JMyvnpMk9LL/TFdj51QZ2Vzk P2eXbdZxFmuDd4OZzUjObernimcl54Y4npy7rMEzM7/s7Z2t1fzUarzDuHqcfgbQ7PdOOzffaMIw 4T8D7t8Z62gtPav04Wb8v3/XzG9V+uwWPdoA/45nsnaOamtua/bb4DFTL3/3nvWeNW1wt6m72mRb d8Do0Y/9Jw8vzZLjbHPX6DauXZf0Krw/Ep7n34e92TxRqWd+Z7PWmCfejzH3wjvdq29PbRb1P9vE f9Cc3SXtXLlp05OFfzfWW9rxmwp59cm506zLv6sNatJLhf12nn2/xDvQ28P7iQn/XT/9ya+2A323 e55XDWM00Pun7mUm2r3/+/ynp6ZnyVG33CfevaaVkrPv1cmnRk34Lv/+eI0/S6915DRjaS0iy3O/ 7TP1Vf4M9CFp5zJmTvUzIqnfVMjbsFVzQjt16Xw/YbMx0/8D0teU3twZRQvfxhd4O9Om0mJnpNPN 0dR91+S8e633Nz2D6p/VfDq7a62ac/PN8xHTxBafUvtvW/war0LbtUYu9N7rNmYHv86HfedTh1n9 TG+xN/SbywLr62ezGwxrGXnYLvQWbvY6v8V8Jpq9VXkl77h195zA/OzHt5jqbNFxFy2RzMUcy8IT 27voZyYzlsEdv1tvc1lS5lp9pzWbv77Fa5P6tFUe4Df3MDebaiJjW+O3xVbc58ZrmGd6umXZnubw 46SeOz2/3f/oNOb1iv1tfTYvaWsW03eOwwa0Hdxr7M3Iw/aVzV6XGjUl7ydt1mbar0nG7WbUvu3P BvjXVYn2e3tmhDotKc/OsIOs+ffjZ6oJ5ezgpIvTcpnXru+TWS8CSQZy2pa0rcI7crLd09vaxctp q0u2IYya5cm7LV7fJe/u5Um/p2/2z27bpL2l5LOC/zlL9/Jk3vukDVa1LcGKnLam7cgvJ6U/8ELx 5uNmW7rm3b08Wdpg1X93G3Qsbd/is9fZnl/MLo9m9B2z4P/rJ1+a9b+Wu5x7zfyXubHzeD0V0x9f NGz9PKrxN7rrqZW4UQSE7odOE6eLk8UZ4hYxVtwqZomfiF+Jp8zbzWvEY+JNsUq8LD5j/VAkWD8S a6QSy6Utc8S/ZC/ZR3wtd5VHSyHHytPkUPN+kO/IM+VVcricIm+Vp5o3g0yU9XKFvFaukZ680bwB pMy8AeRO8waQu8wbQO42bwD5pXkDyEzzBpBZ+v0U8h7r08C58t7AhMB1yg7cEPih2icwPfBTtZ95 68T+9mh7tDrAPsYuUAfaJ9knqcH2KXZUDbEL7bPUcPs8+zw1wr7Avk6NNO+VGGf/2I6r0+377N+o q+wH7bXqWv22CPWivcHeoF6yW+yNqkq/M0K9ot8Zoaody7HUaw6Let1xnX3UImdf5zBV7wxzhql1 +i0Sqlm/RUJt0G+RUF86JzunqK/0+yPU187FzsVW2Jno/M7KcR5xHrHGObOdudap5l0S453HnMes QucJp9I6y/m787R1jvOM84xVZN4rMcF53nnBOt+8V6LYvFfiQud153XrYucN513rEqfWWWFdYd4l 8SPnc2ed9WNng9NqTTdvkfiZeYvEHcFwMNeaFewT3MWKm/dH3KffH2HN1u+PsOYEvx8stv6q3xxh vaPfHGEtC04JXmMtD14fvN5qCN4YvNH6WL8/wvokeEfwDqvRPd+9wFql349gfabfj2Al9PsRrM/1 +xGsNe5d7t3WOvceN26td+9zf2194Za75daX7pPuk1ar+7T7tPWV+6z7rLVJvw3B+tpd6C60PP02 hIDQb0MIKP02hEAgnB8eHrDDI8JHBYLhY8PHBnqHTwyfHOgTHhs+PdA3fEb4jMAe4cLwWYE9hZJf oMEBcaSwWS3hsNoiyLq76MEaFCGz6v8shVlzWHuy5pq1t5lX24Vtb473Ye3L3i5cuyvrnuYO3e5i N9a92e7OeL0f61GiP+t+Yg/Wo4m1pzhW7MV6HLH2FvuLfVj1c3yDkCpPHIIMh4rDkOpwMYw0viO+ z5EjSCUsRouTyPdkcQqyjGXtjS2OI39tjbtgjYXkfxY+xe7iQtaguEhcQg4TxeVIMklMJo0rxQ1I cqMoQYabsNr98Wumk/tPWftizbdw7a2sB4nbWIeJ/2E9WPyMdagoY80Tt7MeIu5gPVT8nPUg8QvW odj+DMYKd7IOEXexDhV3i19ydibsMAx2+JUYIe5l1d8fiYvvif9lHSruYx0lfs36fXE/6xniN6yj RDnrEeIBMZsU/iDmkO+j4s9I8hfWQeKvrEPFPBgnD8Z5FkmeEwuI+Q/xCserxatI8k/xGpK8zjpU LGIdBDPVEH5TvEPMd+GkYWI5a56oFx8j2ydw1kjDWYcbzvqeWCO+IP5G8RWybRKeGAVfKXEELGaL YdKRjpASo0GnesgeIiBDMiR2k650hSPDMix6yBz4zoXveomesrdEe2QfuK8P3Ie+yL6yL/FZxR5y d4neyH6yn9hL9pf9xT5yD7mHGCD3lHuKfeVeci8xWu4t9xbHyH3kPmKMHCD/j7kvga+iyNY/VbeX 23WzASEEkpCEJQQIEEjYEwghbGEVEBAQEFEREXmKiIjIIC7DcxBRb/ddRQYZdRSXcRDRUUTHPwMM MjzE3VF2lUFBZRAxeV+dAKK4AOqb/+1finOra+vqqnO+73KqqiHlimyRTY1FjmiOlrQQLVFvgShE S9oKfepIkeiKmBLRHW3oLwagDQPFQLRhkBiENkDnIhwmRqAlI8UEpL9IXIT0E8UktOEScTnaMEVM RRumiZlow3ViNmq/QcxFvTeJ36De+WI+8t4sbkbe+8RS9Mn94n5qLpaJ31NTsVw8QK3ECvEHaike FA9RgXhY/BExH4gPqL/YIXZShdgldkM+IA7QAPGJ+IQGiU/FpzRQHBQHabA4JA4h/jPxGeI/F58j /gvxBeIPYw73F0fEEeojvhRfUj9xVBylvuIr8RVVimPiGOK/Fl8jvkpUIb5aVFMl7IekXtInfdRb GtKAbEoTsiUtyLa0IcO6UDttXahIWxfIsC6QYV0gw7pQkbYuNMT3oe9z6ur7wneMbN/XvipK8FUb JqUZlhGgdCPBSKQcI8moAznVSKNGRj2jETU1GhstKN9oaRRQK6OVUUSFRrHRmdoaXYyuiCkxekAu Nyqok9HLGELCOM8YRRZs2EVU15hoXEb1jMnG5ZRtTDGugjzduJpyYdtmUKlxrXEtdTRmGjOpod5d CaXNM+ZRa23tyKetHaXB2vVAWG72pASzwqyA3MvsRbbZ2+xNjraC1B1WsBJ3+5vQLeYAcwDkgeZA StV7MiH9YHMwYoaYQ6iBtpRUqi0lNYGlvBDhOHMcdTHHm+MpSe/SRC3Ni8yLIE80J0K+2LyYupqT zEko4RLzEpR2qTmFcswrzKmIv9K8Ei2ZZl5FAXO6OR21/5d5NdLMMGeg5GvNa1HyTHMm7s42Z6M9 N5hzkOtGcy5y3WTOQ5m/Mecj/c3mAso0bzFvRcm3mbfh2W83b8fd35q/RUsWmgsR89/mf6PMO8w7 UMLvzN+hhEXmXci7xFxCjcy7zbsRf495D5nmvea9VNsMmkE8qWd6yBsyQyg5bIaRJmJGkDduxlHj feZ9yLvUXIr4+83fI+VyczlKeMB8CCU/bK5EysfMx9DPj5uP4ymeMJ9Gq1aba/Ckz5rPo5YXzBcR s878K57uFfNvyLXB3Ih+3mS+ivK3mNuoxHzNfAMtedN8F214z/wn3tf75gfUw9xh7qSe5i5zF9qw 29yLp9tnfogyPzI/Qgkfmx+jhP3mfpT/L/NfqPGAeQBpPjE/QS3AMVSocQzCw+ZhamX+2/w35CPm EWquMQ3pfbCIWkLhCSrUyIY6amRDXYBsFMKAlYC7iVYiNbWSrCRqZSVbyUiZYqVCrmvVhZxm1cPd dCud8q36VgNqYWVYGVRgZVpZuJttZaOEHCsHpeVaubjbyGqC9E2tPKRvZuWjnOZWC6RsaRVQe6uV 1RoxwFJIU2QVIVexVQy5g9UZabpYXaiTxlWQ+1n9kL7SqkTMUGso0gyzzkf8CGsE5VkjrTEoZ6w1 HrUAdVFzoK6LUbveS7qpdbl1Be5OtaahnVdZV0O+xroe8bOtm1DCPOtmlLzAup06WL+17kCf/M66 C2mWWHejrnuse6mzFbRcOs/yLNg4K2RF0M6oFUUJMSuG9HErjjT3Wffh7lJrKeLvt+6nNtYyaxm1 1sgPMSssWEDrD9Yf0IYHrQdRwkPWQ0j/sPUw2vCo9SjCldZKkhoXUl2NCxE+bT2NcLW1mgzrGesZ 8muMSN00RqRkYMS1VEfvQIY0QIpUXyNFaqiRIjXWO5Ah3Gq9Rol6HzISeh8ypHzTepeyrfesfyLm fet9sqwPrB2krJ3WTpS5y9qNNHutfcj7ofUh4v9l/Qu1HLA+QfpPrYNI/7n1BdIctv5NGdYR60uU dtQ6ipZ/bX2NsMqqQt5qq5q0UTWorm3aJuXalg07a+NDhu23/VTLdmyHGurdzkjaCXYCZduJdiLS JNlJZAG51qIMu7ZdG3nr2fUQn24D99kZdgZKyLRzUHKu3QQp8+w88tvN7GakgG7bUrLdzm6P8jvb JVTHLrXLkLKHXU717Z52b5TZx+5PWfYAezBqH2IPR73n2yOomz3SHkVl9gX2aCq3x9hjUO9Yexw1 BkqegJQX2Rfh7kR7IuIvti9GeybZl6CWS+1LUfJl9mUo+XL7ctQ+xZ6CXFfYV6BeoGoq1KgaIVA1 FQNVz6FW9o32jdTUnmvPRTwQNrXSCJvqAmHfAHmOmkOFGmcjBM5GzG3qNmqpble3U1P1W/VbyMDc CO9W9yDNvSqINEDe1F4jb+qgkTcVa+RNXTTyRsyL6kWE69Q6xAB/Iy/wN/ICfyME/qZC4O92lB8o CsCiAYW3p+aBDoGO1DTQKdAJMZ0DXah9oGugK3UIlARKqGOgNFBKXTRSR5o+gT5I0zfQl1oF+gX6 IW//QH8qCAwIDEDMwMAgpBkcGIw0wPEoYXhgOJ0XOD9wPvChlOMYzVcwjk9h1J5yHK/XZpyuEXkK Y/FejMV7Mxavy1i8L2PxSsbiAxiL12csnslYvIKxuI+xeArj7xSk1cj7fGDrFEbVvRhV92ZUXZdR dSWj6vqMqjMZSWcxks4Bjr6Nchk9t2L03JrRcxGj50JGz3rH+EWI0bi5GLj5LqRfgqsj3Y0rlzF0 MWPoLoyhSxhDlzJ67s7oeQKj5zJGz+VAzzE8SRxXFt1HD0BeASSdBST9EEp7mP4IlPwIkHQukPTj wMpP4MqlJ2kV5KeBrXPpGaDrNvQsEHZrRthFQNgvgJGsxVVIL9JfIb+CqxC4+/+hbetxFQJ9/w3x G3AVAYNvRPwmIO8i2oKrCPj7H4jZynvtbsNVDCy+Hcj7dVy59Aa9A/ld4PJc4PIPcHcnrmKg8114 6t20BxxpL5B6F/oQSL0VfQykXgKkfgDc6BNcpfQpfQH5MLB7KWP37sDux8B2vsZVRlXA8T2E3qql XEig+XLhEz4qZkyfcwqmDzCmTwamBwtkHJ8sEkUS5BRg9wBj92TG7gHG7smM3QOM3Wsxdq/D2D2V sXsfxu79GLv3Z+yeztg9A9g9B3g9V+Si3kYiH3Lzk2heAs0XoORWojXZog2QfbJoB2TvANkXgV0U i2LU2F50htwFWD8ArF8KrN8NiD9ZlIkyShA9RA/El4tyoP+eoifkCtEPcqXoD3mgGIJwqBiGcLg4 H+lHgA8EwAdGopxRYhTKuUCMhTwO3CAZ3GAi7k4CQwiAIUCLiUvFZVRbTAZbqCWuAFuoI64UV1Ia OMM0PPtVYgbka8EfUpk/9AN/uIEaiDliDnrgRnCJBuASN6EffgNGkcGMIsCMwhELxALIt4g49dS/ Bh1nDqOZOQxl5jCamcMYZg4XMnMYy8xhHDOHMcwcLmTmMJaZwzhmDqOZOZzPzGEkM4cRzBxGMXM4 n5nDSGYOI5g5jGLmMIyZw3BmDsOYOQxn5jCMmcNwmSATqJNMkknUWabIFMi1ZW3IqTIVcppMg1xP 1qNsmSkzyZLZMhthnsxD2Ea2oXqyq+yKcJQcRRfIi+XFCCfJSWTKy+RlCKfJaQjnyDkI75R30iAZ lmFqKu+X91O+XC6X0xD5kHyIGssn5BMIn5XP4u5f5F9wd71cTy30nrEIt8ltCN+Qb9B5co/cA3mf /JCayyPyCA304UNN9H6wlOdzfA5C5VPUzJfoS6TBvtq+2tTI18DXAGGGLwN3m/iaIH2eLw9pNC8a 7+vq60rZvjm+OdTTN883H+EC30KEz/ieQahZUwXYUR3wGc2L6oMX1aMsIx3sqCHYUWPwmSbgSAXg SC3BhQrAlArBlFohvjX4UgfwpfaQOxidIHcGd8oFd4JuNrqCQXUDgyqF3M0og1xulFOZ0RNsqgfY VC+wqd7gVAY41XkUMIaCWfmNC4wLKNEYbYxGzBhjDCUbY8G1FLjWxZAnGZdCvgy8Kxm8azKlGpeD faWBfV0BeaoxDfJVYGKpYGLTwfT+C3ysAfOx3szHSpiP1THmGHNRvmZlhczKWpndze5A4ZqDpTD7 SjL7mH0gaw7WlxlXEhjXYMRoltXbHGmOpLrmKHMU1WfGlclsqoJ5VArzqLrMoyqYR/mYR9UwqBRm TSnm9eb1KFOzpgpmSinMkeoyF8pkLlTBLCiFWVB9ZkEVzIJSmP/0ZuZTl5lPhRk1oygtZsZwVzOf +sx8KpjzpDDDSWEOk8K8pRfzlt7MW+oyb+nLvKWSecsA5i31mbdkMjPJBCf5HAznC/MLymVO0oE5 Sa551DxKReZX5lfUkZlJkVltVlOxNv6Uy/wkh/lJiWVaJpUxSylnlpILlhKgIisBXKWYuUpD5ipt mat0AFdJoVKrFhhLN3CVdNytb9UHCm8ArtKGuUoRc5Vc5irtmKvkMldpA67SCGU2BmNpyIylgBlL W2YsHZixtGXG0o0ZS5HV1mqLvJq3lDNvybLaWxjVzF46MHvpYXW1uiJliVWCkkutUjxRd6sH0pRb 5eAAPa2eyNvL6oWYvlZfhJrnFDPPKWOek8U8J4d5TgHznFzmOQXWBGsCZM12WjHbacNspwhs53Jw iSnWFJRzBZhPWzCfqxGvOU8xOM+NaNtcMJ+OYD6/Qcx8az7S3AwWVAwWdAtadat1G3W1bgcj6sKM qASM6E706mLwom7Mi8qYF3VnXjSBeVEZ86Jy5kVFzItKmBd1Z17Ug3lRFnjRMrRWM6Is6wHrAX0m DBhRETOicmZEZdYj1iNoyWPWYxSwnrSeBCf5k/UncpgLJVtrrDUINQvqwywoYL1gvUCpYEHrEK/5 Tx1rg7UBMRutjZTOXCgDXGgLUm61tiLcZm1DWMOIXrdeBzvSvEgxL0o9hRdJ8KIPUOaOk+woAexo F2J2gyMpcKS9KKeGI31kfQRZM6XASab0KdjaQfClgHXI+gy1aNakmDUlMGtKtb6yvoJ8zDqGNJo1 ZRxnTWQTBZg7KeZO6adwp2RmTXVOYUoBO8VOQbxmSumnMKUAMyXFTCkAptQIHKkx+FLAbmo3haxZ U+A4a8q3m0NuYbegBLul3QpyG7sN5EIwqAAzKAUG1Ruy5k61mDvVYe6UytypD3Onfsyd+jN3Smfu lGGPt8cjl2ZQdZhB9WMGlX6cQV0GvhRgvpRhX2lfCXmaPY1y7On21WBZ19ozEWqOlMscqdheY6+h evZB+zOwvmP2MbL8FX7wAf/L/rfoAv/b/i/JdC52LibLmepMRbjaWU35zvPO8whfdF6kIc46Zx01 djY6G6mps8X5Bw1y9jh7Eb/f2Y+YT5xPkPKgcxAsC2CJWihTmXSecpRDRaqeqkfNVbbKRpijcnG3 hWqJuwWqFeR2qh3CMlVGjVSFqqA81Vv1pmaqn+pHg1WlqkT8MDWMmuh9p2mgulhdgjTT1FW4O0PN QPxMNRMx16nrkOt6dT1iNBvMVTeCB+aq+Wo+wgXqFoSaDZaCAS5CeKcCy1BLwANzwQA96sgMsIta of5A5epx9Tji/6xWIXxGPYvwOfUClai1ai0Y40vqJeqpNqqNiN+utiPcqXaizL1qL5WpfWofdVcf qg+pnJlhKTPDnEBxoJhymQd2YR5YwgywhBlgDjPAXGaArQKVgUrI/cEAi5gBFjMD7BgYEhgCeVhg GJUxD5zAPLA8MCIwgrICIwMXINeFgQupbWBCYAKV6v2uqUXC4YTD1ELvek15iWaiSXkkMwr13tdZ 6xttp05gC/8ffKr31/jKnes+1DW7Vnwnjv1tvrXb9F3VK6qvPbHb9Cnxh6pfq77l3Oqu3l19y2mR zatf5/9J3nnS56eIvd71anG9U4te43B8rc9/ZmcW1J7Kz32utaeeq7/ZuXpBfaeU5WeQZj97oeq/ 436Y1Xv1nmVnXsK5f755yhNe29Xer1nfj3+qr6X/o91yvrtDF2Im611l+G2ccwt4vqw8LbbGn+uE x/HyU/1QauZkdWp1X/6377m87eqx1WNpaHWpzv+dO0Uchk+0qbr5tzzJ1U/5vpxdT/Db+7H9yk/r 81+y9u/k/UGP5jP6pELjfPDdZ9Eamvede/NHVjj8rE917ol6frESz9gTsurNKv18w0/1ddd+jlUH 2Af1Gu2belrpOd+kOxl328kSz1KDno2O/4W1hH7f+79v7Nas7P7uaPq5tX/7Df+S7/sM6t58qmXD WD71W+VJ6VVeIfQLt6z6rlPHB8fc9kNpf+kPnqgS4/jkfKg+UB399uw40RO/jOU/rf436dQdwfae We/yW3juR+6fhh1+IN0Wvdrv5Ld/cPgTe+fUoJDq535oXcTp2OEnyjuL0z2qR39fXd/U85OrTYYf T6d7vaX2pdZe9Cd6vPox/NXj9Z53Qa+9+u03DiuZdVzS61FerW7FGFmnq8H+KWf+HL/455qfSoAZ /WvpkzPeuaHqrM6iOaMSf3Jtzrd3s+aY/6Odcn5i5n2n5dXPn2XpJ/Y5P6OVHT9Yyn9kRWCNPQG7 POvxUHXkZ9XLs0Rbm5p/f866qO8p/azQ3w/tTPX9o+aUvc3O4X2fopFf/XWs2I/Uzb19wsZA3/6s 8Xpa6WfQ5yfXxB/fT+B7Urz7fbqx5jcd/jvHNh9/9nPQvNXDz63G47kP/JzcP/9zfEfrM9iz6bjl /MZ+1+zRkU0nLfVZflp+q/TvWXHxa33OXpedVem/ErPksk8b5yf4/+m/WfxCNZ7ct/wnf2mY8J3v r9f8nnBOtZ7x76nf1K2Z94m5yL+yrvguAqXj+wr/+C80p/2eOvzU31PPoO1P/nSaH8z7+DnmqxkN qWj76u9bR414/TZ+dIU1kPJNbHVuOhv+VH1N9ZtVd9X8TlAd0d++YYRVmiu2r77m+5DAibjvX51X dfrv3GfxOcUCb/xpvXJ8V44fXaF7FnV/Y79/PRT/K3++76yCX73OE3rtZ735n9mGl/4DlZ4446Om zyVNY78lktkyh4Q+V5t87L1k6BO1yZQFsuC4J5Otz9Umv+wsu5KSFbKCEuVAOZCS5GA5mJLlMDmM UtjPqZYcI8dQbTleTqI68jI5merrc7Upg72dMvWJ2pQlZ8gZ1FBeJ6+jbDlbzqYcfbo25erTtakx +0LlySVyCTWT98h7KF+ftE3N9Unb1EIulcuopVwuH6DW8kH5EBXKP8pHqZ18TD5G7eWf5Z+pg1wj n6OO8nn5PHWRL8mXqKt8Rb5CJXK93ECl+rxtKmPfqR7yf+R2KpdvyDept3xHvkt95T/lB1Qpd8qd NFDukx/TIHlAHqKh7E01Un4lv6JR8mtZTRfok7ZpLHtWXejz+wI0zpfoS6KJvlq+2jTJl+pLo0t9 6b50utyX5WtIU3yNfU1pqq+ZrxldZf/Z/jNNt5+219B/6dOX6Vp9+jLN1Ocu03X63GWapc9dpuvt vfZXdKPf9CfQEn3uMoX9N/tD9Ef/w/5PaZ0+d1k4+txlUUufuyzynZXOY6KtPnFZFOkTl0WxPnFZ tNcnLouu+sRlUapPXBY99InLoqc+cVkM1icuiwudz5wvxDjn306VuEgJJcXlylQJ4gp9yrK4RqWq DHGdPmVZ3KSaqQJxq+qgOos79MnKYrE+WVl4+mRlEdYnK4u4PllZLFWj1BixXI1T4wWfrCweVrPU LLE6YUfCbvGM/t9c8ZeEqoQq8aL+31yxDuPydR6Xkv3ppMzB6DR4dNb41kkenRaPTodHp8LoLEZ8 e4xRA2O0M+52OTlSi3mktuSR2oFHakceqe15pBZjpI7H3QlyIuK1j1579tET7KMn5GSMYB+P4Bp/ PcEj2OQR7OcRXMAj2GY/PiFvxDj2YRz/BmnmYzQX8GhuzaM5mUdzLR7NdXg018NoXoq5pD3+6stl GNlt2e+vUD6A8Z2hz5NHqH0A62KU/xHhIxjr9XisJ/NYr6XPlkdpz2LE1+UR35ZHfEMe8TnsJ9hI nzNPRXIDRn8LHv2NefQ31afNI9T+g9nyNfkaZt12zId89iVsJ9/ErGimT6FH+C7mRi7mxj8Rvo8Z 0pRnSA57GjaSH2GeNNcn0qPkT+Sn1EQelAfRhkOYOfk8c1rxzEnCzPkamqJKVkFHVGMWZfEsqs2z KA2zyE8B9lJMYC/FdF8A8yqTfRXb+JIwuxro0+wRar/FVMyxVIR1MdPSeKYl8UxL0Sfbo8wmmG+p PN8yeb5ZmG9PI1yNWad41rXkWdeSZ53Js87ErHsH4buYewU89yTPPQNzr4Qsf6m/lBx/N8xDxfOw GPPwCWrpf9L/J+rgf8r/EnVkD5T2/rcxP4Wen+TD/OxAptPR6UR+p7PTiwr0XCWpT0enDOcx5zGq q2csJesZS3UwY1cjfMZ5BnfXOGsQ/xfnL5TI3iv12Xul0FnnvIy76531CP/m/A3pNzqvQtaeLK2d rc7/UC1nm/Ma1XO2O9tx923nPcj/dD6gts4OZwdS7nR2ouRdzi7Iu53dkLX/S6Gzz9mHGGgElPCZ 8xnlOp87n1NT5wvnC8rR57FTkXPEOUItnC+dY9TY+dr5mpo5VU4V5UBrCMrW57RTHvvLtFOW8lMz 9pppqJQKUCN9cjsVaZ2C+FRVF/Fpqh7i01V9aqoaqAa4m6EyqAV0TSPENFZNKR8apxnKz1f5yNVc NYesPW7aqQJVQM31Se/UQHVUHSlVdVKdKKA6q86UBN3UlWqrElVCWapUlUHuoXogZbkqx91eqhcl sG9OOvvmtFGVagDuDlFDEJ6nzkN6aDHI2k+nlRqtxlAKdNk4xI9X41HmxepSSlOXqcspU01RU5Dy CnUFSp6qpkK+Ul0JWfv1tFHT1XTEQPdRCnTfDspP2Jmwm+pBAx6EfCgBPaz1INl6qQNlJopEH6WR RIdqH+kO7CPdin2kO7CPdEf2ke7MPtKd2Ee6C/tId2Qf6c7sI92JfaS7sI90B/aRbss+0kXsI92O faSL2Ue6LftIF7GPdDv2kS5mH+nW7CPdhn2kW7OPdBv2kW7NPtJt2P/Z/y19fbqmrkEQ2hfalqWy FLqjXJZDd2jtXCj7yD7QKVpHN2YdXcI6uvS4jr5AXoD0o+VopNf6ulCOlWOR/kI5DnpH6+7GrLtL v6W7L5GXQAufqsGnyCkn9fhUeSXkGm1+lZwOuUanXwOd7mOd3kTeIG+ALTlVp98k531LszeRC+QC pNH6vZm8V95Laey/ncSavRZr9lqs2euwZm/Bmr25XCFXwDJpnZ7Aft0J8kn5JFJq7+4k9u6uw3q8 hfwrNHgGa/As1uAFciN0d4bcLDfDWrwqt0DWejxLbpVbIWs9nsV6vCHr8WzW4y1Zj2fIt+RbsBxv Q5tnsDZvIN+DNs+QH0CbZ0CbQwvI3XI3pbMPeRZr9kz5L+j0DNbm6azNs+Vn8jPEaJ2eJ7+ETk9m nZ7MOr2uD11EyexznugzfCZkrdlTfDY0ezJr9hTW7LVZs6eyZs9nzZ7sw0WOLwX6PZn1e8BXB/o9 2ZcG/Z4M/V4fofZUD7CneoqvoS8bMVrXJ7PXeqKvKTR+Mvuu12a9n8oe7F3Zg91vt7Zbk89+yn4K NmCVvQqh9iG07Q32Bmpsb7I3IXzDfhPa/2377eM2oIn9vv0+cu20dyLcY+9BqH0OJfscSvY5tP0T /bOpqf8G/3zKYatQ6A/7w5Trj/iXUyP/A/4HIK/wPwRZW4vGbC1K2FqUnrQWX7K1aP0ta+Fja9HE 6e1MJIO9GSV7M0q2E2ns01jHec55Dppa24Y6bBuas2djgvMSLIRi25DGXo5JzmZnM2K0hWjGViEN VuFd5NVWoQVbBcU2oDn7QCY5B5wDuKs9IeuwJ2SSc8g5BNtw2DmMUFuCAtiAo5CPwRI0gCWopgz2 lsxiG9CQbUBL2AALsg1LUI+1f4FKVIlImaSSqL5KVimQa8Ee1GO/yky2AQUqSzVEvPaxzGQfyyy2 BNkqT+UhZTNYggy2AS3Z6zJLFapClNZWtUW89sDMUkWqCPW2V+0Rry1EMtuGZNVFdUGobUNdWIVu kLWvZgC2oSdk7bGZwlahNluFfPbYDKj+sA2OGqgGIo22EMlsIeqqoWooZO3PmaiGq/Mhj4DNcNhm 5KkxsBnJbDPqqovURMja2zOFbUYq2wwHNmMq4rWdyGf/z0R1rboWMdoLNIW9QGuzF2iiRs1UK2Fv wl6E2hMyiz0hs9gTMoU9IVMSSxJLKCOxNLGUkkkYLxsbSFAC1dYLpO715Ci3hTvanetu9Sq8sW7U W+K+4T3sve8d8qQ3OTQqNMndFZruFrqD3AnuXC8JsRORah5SVIUMfBsbuSMSj6yKbI4ciTaKto72 jk6Kzo8uiqyPPhl9Pro9+nl0e6x2rEmsMLojNjw2OrInNiE2FXk85NmGPEOjU6JzouHoUvy9E91X kzL6fOSt6OexueHh4dGhFeEJ4UvDU91ytCUanhteEF7ojg4vdgtDt+NOUNcfWxZ7MHIkNjXaO/YU 6l8UuUPXHluLujehBSmxwtgbsfdQ967YR26LUDhcEn7PnRv+yF0WPhbxhwdFciJ5bjRSgacf7Zbg iSeFngw9EpmBa7Y7KDIvtM+7I3Jr+I3ICO/9SINIu9CT6INuqPlxrrs8ciSeF1kf7xSviE9Ezb1r 6o2sQr3p8c2oNyG+Lf5+fE98f/xQ9OVo+D7jPhXPiT+MFE10f8VnxOfFH0eqddHt8fUoW6KEEu9I rNBtgvQvRzd4DdypeD+HveXeWO8Od5l3JDQF7+UVd423yl3sbnWjbhDf53pj8Vbaebe6l3rv4/un 7gKvE97S4+4upNzjdvAOhaaHBriz3E3usdDtkYcjj8dmRdZHnou8FXk/sidqoO8V3mNxtEt0ZnR6 9J7oan6LB2IUa4g3pHuyMDYo1jd2KXo7LZoZuzpyKPpIdAve/PbI/ui4mIU3/3J0Bd7xkciSyLpo o1iHaFlkOfrojkhV9PZYQiwdI2BBbGFscSwYHRBrgdpWRI/iLQ2ILkKu9dH86Ci0b7EbdHd5qV6O N4LH5cNhC21vFCoLdQkNdZ8KR8PLwivDT2EELPBWhR/Uf+E1GB+zwmvDV6MtqyLrY4ejYbz3ZbFX Ysdia+Iy7o9tDU+IRWMrY59GZGhoZEh4U/gVPQoiSeFZ3sRIXqRTpDLSDSO9xJusR0FkcmQa7u0K 7wo9glGSF8nDqMjBXFjsPoW6SsJbMSZXhj8NH46kRgoiYyMT3WB4ULxbvCoej6fGk+IF0TDGxJD4 iPjYaO/4rXEvfkdkVXw5emBCZE/8OYyKt+JH4kviS6KT4pXxyeiDAfFt0ScjHt5DGvo9M94gsiey 576U+9Li7aJl8Wnx2dHW8VVRFZ+McVru9kVbF6I1y9wH3ZVeJ/eN0POhOZ4MbUGvVWIsHA1TaL73 Fq5V3jpvc7g25u22UEpoXLgFxsF0PMXVobAbDb0c2uB1C+0LZYbSPL/nDy0K3eMODy0NrQg9gpmw 2g16BaF3QjtCB0Kfh46GjrqjvRneNG+2d2u4A0ZeNBQOzQwnhNNxLz/U2t0VbhIu9N5CXEloUbgc 861veFCo2BviTfbi3nPeem9/SHnPue+5H4W2e3meF24Y6g29Aw3kLWHtMxkzUGudcmimIJ5usTvL k+7aSEVsE/SWML4kSffz2lvi/WsE71wjedWtj+6kKBm0gv4ALfcorlRajasur2BN4/Wq9eg1XOn0 Hq76vEdMA9qLK4M+xpVJ/8KVRf/G1ZBXj2YLS2RTjmguWgA/F4pCKuF1mqWiq+hK3XgNZndecVkm BovBVC7OE0OppxgvxlMv3nWlt5gsJlMfMVVMpb5ipphJ/cR8sYAqxaPiURrISHiQLJNlNJjx8BDG w+cBD/elobJS9qfhQMXDaYTEReMYD48Hvr2BJjDDnwV8uJGuB5/fTvOA9HbQQrkLKO5e4Le9FGQe 7jFaC8sv5GGKyCM+ohjgfD1a4avvy6TnfNlAUGt9ub5cehEIKo/W+fJ9LemvRrFRTH8zSowS2mBM NCbSRmOKMYU2GdcaM+nvxixjFr1qzDFuoi28nmsbr+R6zTxqfkXbeV+JN0ARfPSWZVoOvcO7RXzA a692WJlWJu202lhtaBevltrN66T2WCVWN9prlVm96COrj1VJn1oDrYH0uXWrdSt9YS23HqDD1oPW FjqiV+6IXL1yRzTSq3JEY70SRzTRa3BEU736RuRZ+639opneiUDkW8esKtFcr6MRBbZlp4lWdku7 pehm97P7ie72JPtKUWZfZV8lKu1r7Bmiv32dfZ0YaF9vzxaD7Dn2PDHEvtm+XZxvv2S/LMbYr9h/ Fxfar9pbxCX2VnuruMzeZm8Tk+3X7XfF5cCKe8R0/yL/InGd/6D/oJjlpDlp4npntDNazAZ2Oipu cI4pv1igmbC4Cyiotrgb7DdNhMB+00VYZapMEQHayRFRzXhFDFy3pYir1mqIuB9IY6R4GSx0tNig xqqxYqOaoCaITWqSmiT+rpmn2AzOeZt4VS1UC8VHapG6W3ys7lX3ioPKVVFxSN2n7hNH1DL1e/Gl ekA9KL5Sj6hHRLVaqZ6QpP6knpKG3iNAWuoF9YK01V/VbulXe9VHsrnarw7JVnr1hywOdAh0k+0D ZYEy2S1QHugtu+v1HbIiMDBwnuwVGBYYKSsDFwTGysGBcYFxclhgQuAiORzIpBRjWcihYFoakzQi k+h3xnf/RL3grODCYDD4IEL97+E7R7kyuNBNdQsWxYNRdyL+bnU9N+4+7q5z17ub3W2Lg8izAGmR Y3HJ4hLX76bqHMG1SOu5y5GyE77Pdg/pspcMdY8gHUoOrr1zFPLM1SV7acEoapoY3OTGvXyv2N3s dfHKgrPcKs/wlJfptfZ6c8uQ35sZXOjNCb6CEg57S90C/FuTN4i8W7x30KZUb5/3uXc0RCELVwL+ 0pHveW+A6+nn8ZYi5/NItSG41l2HVj6O56nAVRlcjJbuDy4LRtHGlcGVwTXuEDzHwuCu4Efoh8O4 2w79sNYd4U5zl7jv6/bieg4lbHPfCm4NvuHuCT4VfAr9lep2c7uhV6L6e/BY8Jg7I/gK6hi7WPfU LNTawH04+ClKXBWcizDJnefe4W4LHnZz3Dx3snurrg1plwXfQ3pdYjcuZ20w6A31BnijvHz0QyNv nJfiTfKmoL9n4anKjoeH3f3ek7q/anrKu8db5IV1j7kzvEdQwmp3m7cdvfwyeupAyPJWeCvwNg7r nkG4D726IFQbz7PWm462bfZ2hBqGGnrzvds5RdB7HneW3jkKdsA01hvriYwNGu0am4xNJI3Nxmby GVuMLbANkroj1J56zSgfur81rkwqxJVFnXE1xP3u/8ve14fFdZX7rr1n7xkYKSLlRkTEHMQcSiNi RIopRURKaUQOIlIacyimMEyQDMOekUzmK5OZ/TXfw8zsHUyRIkWMiBQpBzHFNOVBpDRNaUoxRhox RuSmGCOHE3MxJ/e8a9d7Pc/94/53P855ynoWsGavtdfH+75r/36/Z7FBH0VV6HG0G30JUjb6B1SL Pob+EdLHlXev7UE6SH+P2iHlIjOkB5ALuVEeMUqMok+QmeRDKJ/8LLkfHSBLyBJUTYbJU7DTf4sc g118nHwBdZBT5BQyktPkNOoCxv9TxJAvkbPom5SaUqPjVDKVjKzKXxvbqOOUDdnph+nD6ARtoA3o e3QX3YXO0Gb6m+j79DH6OPqB8jakMdpL+9HzyluPJugY/Sx6gZ6kJ9F5eoP+E3pZ/Yb6DfSq+k31 m+iC+i31W+g19YZ6A11Uv6N+B72ueUEzjZY0L2peRisKo307YXfCbnQ14cmEJ9GvFa65luhMdKLf JEYSI+ha4ljiAvpt4mLi6+he4qXESwSVuJy4TNCJlxMvE+rE1cRVQoN1RSIh8XeJfyIS73v4voeJ XRDxlWSNEvG7wBLIm4oz8UGpNHRWagghySX1SyPSlJ+JZUpXpHXpnkzJuXIl5MbYRGxazg7Ny0a5 W7YHB6RSqUJqkA5LrkCvn5GWpfXQbWkTaha+W1OmpMOhejmk3HtdHpBc0GYqhKDuFWgLd/ZfhdpL cqUUhfor8Rq47zV5QyqVh+Vp+Zy8KK/KO1JpIFlpT0muU0lS4FROYOtUgXRPmvpr24bYdCDjlCx3 nxqUrmAsBsjq7KnzgM8vQE014FkmNoHnA4gG2JYEmF3OPZUn58st0Gumv0bOlmqhD6d0SJmNPpAs 8XKuFMArEciQLuLxBruVddgvV8tNsojHG5sOMXK77IY59UIakgySWdryX5a1coo0Du1xeUGa9U1L AeijDOq5YNYNodvQdkI6AL2WSq5YplwXFGW7NAV3GApkyI3SjLQGdQ9JQ34kWaU78i7JGiDhfg3K +A7JK1K/nOvblud8A6dQYFOOy6PyTfm0PCFvS2unzsvd/pzQ5KlUKSAPnyqQM08VSTOAVDtO6fBK yXbZDqjRFyzz1wS25Dl5zs8ACy05VX+qBlavSqqAnnrlXH+OPye4A2t6HvhN+qksaQHGUXqKlQIw 6yXwHxIie+m9WP5/G8vqlgQLjmViAh0BMF75Xv7/O5ON3D6BiYrRiRiKpXKlsTxvXLgQa44x0SVu LXYmusMVR4e5fdFupdaKNx5Lh1oI14hZokuxVO/p+Gx82Xcpfk/Kjl+UyqQ6qd3PS92+vqBaikuj Utw/FciVVqC0Id2UtqUdGUGbmfhyfB3aVEL9FqidKnVD7YF3awbV8XXpnO+WUNSTFp0W2Pgeb5zb Epq50vhersEbj++LF3MjsXmBiZfi/uUC/1T8noyksmCSVOfnvadx73KRFA+mwwh2SStyiXdV2vYN yuXcvkhJPINPiYrxw+Hc0EzcLBT0kLzIlfakxfLgjjzMeCcejWXFAZLE++ND3lB8JD4enxImueJY s1DAi/EoV8oVQ88Xcd+yDvrukFJ8FzD+8/XBGij9xpehX8Bn0rY86E8AVHRenvdvwieAwYLpcrO0 El+G+cJ6yT5osyIPSitSXJ7kSqNLcAd1jJFWuH2SiFN0JeoWiyOXYnmw4vmxjhiD7RIdjQ7Hzkbj 0QmwySSUxVgqWG47ViQwsWYoz0VFftUb72mA2osxHbcPrg7HBsUR8aIwGZuPL8QvyqnxtfgVsMWm f49ESaeBEGRL+VKh1CQ1+q5LbsWKw9K0VCir8UpCugafgRV9WVKmnBS/E9+UQmD5eHxLqvYbpBRJ jC/LKH4P1mdZskP9/f7d0iqU7klGaU5ahLbpcpacI+fBrJcku3dbmvBPSWV+HlqtSbm+PHEE5hSH Ma9Gr8WSsF8KF2DtGVEfvhnVCjCzSFa8ImqMHwgtcA3R0/A75HgtVxq5Gm+I3YCxLMOsIMslcoF3 W67y9fnG5Br/msB6T0tlcnncIDTHzbFL0QnsBXFz3Bq5BXZ19aSJ0Xd9QPGCQCxLqIofgmTGdufF WFYPGe2G0Q2DL2ZA+x2opY/r8dXYjTgfjQsFMhPMklPlet8k9grwCad/XWahV4yU+7BXSDuQtuUz /gRpUb7g3/RvSnXYd2A9yvwJvr74jFwCqxsH3zoIEbMNvnFVroIUget7ob1W9gmMNx41QlSGovFw bjg3OoAtHSmJDkBUXoVVw/E8ErsbOx87CKkkVhWrh3JzrD44HxsT08A7IHEj0OJ07DIvRndit2K+ GBu8Ebwh9MUuRO1CX6QktMDbY5fg7jdj12M3YrfDO9GmSBb4ThaOyFiOuAcioTTijJOwngnciFAV i0C8JMfTYjXhm/EMoa8nDa7uFgpickwduQz+WR6rETNiTvDb6eg5fjW6ESuAXaUPMowYIhB2H6EK 1hV2HZihiGcXjYNHLEWHe9KC6fCEbyTGiXGEiEliEhHENDGNSGKGmEEq4mXiZUQRPyN+hmjiFeIV pCZeI15DGuIN4g2UQLxFvIUSiV8Sv0RaYo1YQ+8jeZJHSaRIiug+Vb4qHyWrVlQr6P2qy6rLKEV1 RXUFfUC1qlpFqaqrqqvoftWaag2lqa6prqH/orquuo52qdZV6+iD1DPUMyid+jb1bfQh6lnqWZRB fYf6Dvow9Rz1HMqkvkt9F32E+j71fZRF/YD6Afoo9SPqR2g39Rb1Fvo76hfUL1A29Uvql+hj1K+o X6Ec6m3qbfRx6tfUr9Ee6jp1Hf09tU6to1xqg9pAD1B/oP6A8qg/Un9ED1J/ov6E9lJ/pv6MPkH9 K/WvKJ/W0lr0STqJTkIFdDKdjD5Fp9ApaB+dSqeiT9NpdBoqpHfRu9Bn6HQ6HRXRGXQGeojOpDNR MZ1FZ6HP0rvp3Wg/nU1no4fpHDoHldB76D3oEfoB+gFUSj9IP4g+R3+C/gQqoz9JfxJ9nv4U/SlU Tn+a/jT6Av0Z+jOogi6mi9GjGp/Ghyo1AU0APaYJaUKoShPRRNDjmqgmhg5oJI2EqjWnNICbNN/S fAvVaJ7RPIP+QfNtzbdRreZZzRD6smZY8yP0RNIrSa+gp5NeTXoVtSS9lvQaak16Pel1pEt6I+kN 1Jb0ZtKbSP+e/vee/vee/vefQ/9Tt6uZv6kBxymcVQ8ESgMH+DR7VcAQsDoyAlF7lafWUxsYD8zw GYHlwDr8vsXOBe6IeYF7QUpknfmBCu58oNeTBleGPLVQa4Gdg0+WBTG4S0wP5nLAOENXg3XuW8Em b2l4d7jY2hs2hAPhXnEwvBBeD2+F70WoyK7QWDAXUl2wLFgWTvOWBtuhdinUPeQeDJZZo0ExWBfu 5WrCvThZo0JhTyr+rScnWGhb7UntKQ/3eg22Oe9mT1VPjbdB2IisiLpgpVBtL4FaWeFe26rjnm0u WNmTGkxxmAOleGa2VU8tzCEaXMIzFZqCK4EZNjt4LbgBpR12zjHFlgWp4M3gdqCU3RVcZHfZFh33 gjuCPSh6KyIt1qh3b6Td2uu4EuiHcY46xtlRa2/EHnE7N+wIaoghdSQUSvJm4NFDGoGxHBQKxdue mXBvsA6PXtiwrdrlcC87apvr0fEZ3oaejh7m3fHhxO8Vkf28pzaUB6OLvjs2Ps0xEtKxG/xh+LwD NmO1HYUYT60oQwto6TTyaYEte1WoKLgTqneuBK/xBkF0brgH3YOczzsTmo9MuwcjTYFoZM7aa2fD BjHduxbRhnzhe6FIZNW75d2KXItseIvFLH4ochNayZFt961IU2QpWCfctPaKavuFv84JW8Hpozyl 8NPXkyOAPYRz4V7HHZjPGH8F5jMZyY/k95ztOQ810nvmuaJwr7DtuOM1eGbs8z19PYOOqG1VrA+W gf/cAZsv2Fa9m1bwEY4NlgVqAwfsBU6KT+POOzcCh/gpqGUG7+SdFLZaAJcvOqKe2qAW24yvcFix Z/Lw3ToUOBzQKz48G5iFNlAK9ENagzWNBEphlYbAnwNw/Q74/qbIBqKBEUhXlDs3BFz2quAuSNng y/vDB7zFYT7YFGwJjob14AG1juSIFnz3soiC+d5SoS50Hnw9P5LiuMNFBG04KqaLWZzP2RTRsqP2 y8Fz/AGxKJgJ9wNPFweD3eBdjcEmWMsCviJ027tbTAr3RuKO5EBtsFJMiuxwl3oKrFHuck9ST7qt BVYvD3y9yHs43OvMFVOFFvtV7yb2dMcesd473oMC+nAvrENhYNYafbcU6O8p6VE7DME6x4LHBRZR Bwy2a9B7kbDRU8/Nh8lQCdjBZavD9werJfPm0O1gpr0Ax2PovKM/WB2sDt2Aq2Q4QcwK7wX7pIWc nI/fCm+GLvCH+DRsGyflmPLUchf4A8HVEPLUeiscCTCTK5HTob6I2z7mvoUzRMNApDuUGjGG0kNZ tlWuxpGMc48O9oMOMa+nuccCYy4FP9+OtIOnFeJIwKX/EQtglU3HCHh9OeQaMU/MCzXb4GqoClss VBKoCFl4K/j7npAzxIZyQgU4WkIHA2b3YDgtbIgMe2dwFIQi3nHHuGMzdCN0A3aKg8H9kdGQHBoD C16w9vK7Q32hwchE5Fxk0UZ51x39EK2VOItOxd+zOIhY4ZwjQ9gQNryBkFMYFW95ZkRdj66Hta3y y+6xngt8f0+kR3Zc6TljjTpzQ2fEKvsFuP/50HxoPmAOVoupkcxgKFjnLQ4ag/bwPv5ipCySHTwt djgrw/3hofAIjHkqfMfb6+gPXQoO2FODw6GzwTn3oMMAbfPDGbDnhCDhK4XBwvBseAZ2zqbgdHAi dFd0sk2hSU8yJ7sHPckw4/lwslhjL4oURvZzVZHccK39drghfNjhsvZae2E3qIxUWwP2s+GL4eWg 22GO1EUaHXsCAY6BXcBpZ92DXmukKXwFRpsLa7EnXBG2Bg4EDOHx8HroeuhWMG4vckfCZm9FeC3Y FHaBNSLhXkUxnKZ+Ak+ZtwAf4vc3JAPKS0S5kD6kKIYZilb4YfQ4pExFK/yIohVmKVrhbkUr/DtF JcxGJ5EffQwFkYTy0SlAnA8B3vweegSNoedRKToHqQzw5gL6vII4v6D8h5IK9DpaQo8q6PMxBX1W KejzceVdxwcIikhG1UQKYM0niDzAmm0KytQr+PII8UXAl+0KvvyGgi87FHxpUPBlp4IsjYQHMGUX MQqY0qSolt9UVMsesgQwZQww5RcB/32JrEWDZB0gyGEFQf6QDJNR9DMyTp5Cryia5muKpvlbRdP8 vaJmbpDnyXn0DrkAKHMLUOY1dBvjSyIJ40viPvIGeYN4P6DMPxEp5Db5F+J+8l9ViPgw4Mv7iI+q 3q/6IPEgRplEIUaZRDHGl8RnVQ+oHiRKVEuqJeJzWCclyrBOSnweI06iHCNO4gsYcRIVGHESj2Ks SVQC1rQTj1FOyklU4betEo/TD9OPEgfox+hq4qt0DV1PfI1uoA8Th7G6SnRiXZUwYl2VYLCuSnwT /5cIopuO0aeJY3Q//SxxAuuqxEl6g75BuOlN+g8ER/+R/jMhAIq9R0TUSE0SEgxQTfSqE9RJxDMY xRIDGMUS38FvCiUGMYolnlPvU+8jhvC7PYnv4vd5EsPqCvWjxPfxf38ifqCuVn+Z+KH6K+qvEC+o n1A/QUyqW9QtxD9hXEtMqZ9TDxE/xu+9JH6i/r56mnhRfVb9EvGq+mX1z4k31K+o3yIuKxj3d/gt /MQ6oNtNYkPBte/gN+wTm4Bo7yP+oPkA4Np/URDtXwDR6oi7Gr3mCPHfNd/QdJKEpktjJ9X43Ylk qsalcZH3a1iNSKZhvZj8kOZFzUvkRzUva35O5mhe0bxJPqhZ0ayQRZrLmrfJhwDRXicfweceyXKs KZNfwJoyWYE1ZfJRjHTJSox0yccw0iWrMNIlH8daM3kAa83kF7HWTFYnPp/4I/JL+NQiWZs4lThD fjnxpcTzZCM+qUgeTJxLnCe/hs+yk02JryW+Rj6V+Hri62QzVqXJr2NVmjyMVWnyaaxKky2Jv0+8 QbYmbibeIo8Aqv4X0oDPIpIMPo9OmvBJdPIYfm08adGqtBR5HJ8/JG3aBK2WtGvv195PnsCYm3Rh zE2exJibdGPMTXq0D2rzSVZboC0kRfzXLWQQnxIke7SPaMvJKD4ZSPZqH9NWkd/CZwLJZ7TV2hqy D58GJJ/FuJwcwLic/A7G5eQgxuXkc9pOLUMOac1aC3lGa9W6yR9qWa1ITgFG95MvaoPaEPlTbY9W Jl/S9mqfIX8G6Py75CvaM4DIXwNE/hPyF9oXAZFfVRD5mvZl7c/I32h/rl0i17WXAJHfAkT+sOoD 73vkfaWqDwMir1R9BL9tX5WD36+o+vh9D9/3CDA7AgVQ/G+Y+2hEyfcp/6sqD/bBItjBKlA1qkMH UTOwbQMiT47z5Uh1coTL5KugNGhtge99fDV8JnMJ/H4ohfhaKInsDvwkj+4/6UKqo4UnrewmXGP4 XLjWwV7loceTLdxdKDWxS3zGv9uVCeUt4AgR1BK1qYwuC7/DsWPr32eykVlwV3LbRqMn9eRu++Lx TL6kc8Zaz98+nsltC7VCA7fduc4s8Gpciz9ob+Rl+yI/b60XEoQ0qH1GbBGNoijGxWlxVdzwqr05 3hJvlbfea/Gy3j7vWe9l73XvbR/pS/Dt9u3x7fXt8xVDm3Zoc1qc9qZC/SKorfMehNpn3q3pZcXT 3ku+A7YRYfz4nDB18oBnzFYszNgXXTeEWWHBahEuHl8RDEJAWFb6h57FaV+xV+0zw/2qxBbcu8/l 7fMFvGfFFbhnr68f+h7yjTALDuexu1wjt+1u54uEO3yJMOKy2Ebsiw7f8Ux3Zdc8zLtB3G+vFivF arHu5KyttKtPbLI12FO6+qz1YoqY6fDZF+3d0LMb9+27An2viUu+O37KdwB6Vv+1X9FH+uP+Ad9e f6Z/2r/oX/Kv+Ff9w+I1/4bY7Vv2d4ui9zZeL/9+f53f7p/wh7x9/tNMsbDXO+hL5mEtuG1YF583 wh/k023JfH13O3+Gv8Tf4u8KhzrXj89Zx4TDbNRohJW52rkOFuoTknmGv8qnWuutluPdfFbnAb7E uANXavjr3I5Adq4LB+yrNtJ6VTCIdpjBTbBECGwxIA6Lc94+cRFWc1vc8RZ488COTsWKY9557y1f qbKSpPegLwNysbgEc64QJ7yMVxZvQstRb5b3grgE452Eq9OwPqK3GeojmG0alM55y71XvTfAA2p9 Db5DvsOwUne9zd4O73nwkSRvDbQSxWvedPsqG+26C2NuPlnL+7Bfds6cXOZvC/vsLdZJbpuJCleE KyeLhTV2WZi1G61ZOB9fBc8scJR7xmAsf/3y9YJ9eN+Uz+qb8c36osKUT+8z+MaFe2Kjw2cZEdaF Tb6os4Gbdqe4ysXsk+Pu0Ls+wG27dGI+PyaWWZOsSSIljBivgZdUuyy8mo0yUfvisbuWEbFQaBC2 ui6LWnGXtU/M7bprL/Pd81/zt/suwoqti0t+rX8X2D/bm+Rv9Lf4K7FXwArs8w/7Rf85/5zX52/y N3lz/Cn+XH8l1Jr2l4ntMIMl8KIF34J/FPxn2H/Tt+nb8hf6q/1Gv1tc9OfzyF5tr+66y+fweXwR V2irxZa2DtpX+JJukY/wTn6MXe4cEvT2FEuCPcU9bLhwctlaz4wYrgu1Nmvnuuc6E2UOOZz2RcFl G+EtnVvCHmE3N8FN2A4JZj6JXROsxnZ3iL8BvXQIPBcydrMZ7LKjxlrAn+Un+fP8BRjFIrQPHF/p jgtR21SXLBRD/PR3nRGslopjd22HHD6I0iFhRCjlWX6QHzN2Wy/zN4SMY3nWQb7KmM/r+MtCr1DB l+Md6Hgm3n1wBOJdx17NbUPfRXyBfRWuBBw+XwB2Ngr/K0KEaJKGXY6GL0TSGlqDVO/pmO/pmO/p mP85dMyEmcTdCmqZRZ9AqKXkP1pW3WXumNzGAX25e44xGAeMhbplj7pzzdhiavdkWQxMhadIf9dQ 0Fmr22c+6GH1qaaUrlvu0+5h96ix0b3Utsu940HGliNmY4vF4Cn36DprPU5PjrFRZzB3MHxb4xEr Yzh2gdtvmzlq99xqyzctMuvMndYc7rSnr23CVMmtMFNHW7ommSGukgmwW04zRx2xHrG6V20zsPfP eG7gNsduQ7t7nMisc4udC3C/FdsQV8fZW7PYjLbGrj7G5ZCPVzOBNveRYmuOkGbaEHYL+/TNeovp pqA3W0y5XbeMKa0FJq05vYu1HYZnwiV2yzDI32obBoyYDLXhqSIcOHZVcHXdEvqFYsOgcFh/2ZyK 16dth+Hdc3CHQssh3XLnGnwGq2MYsxi6apiKY6iz1swaLuhTLVbbHbhmd140DDoOHr3JFrdleq6a lrjq1iymlz3A1bG1pg0+B9akny9oa2QbWnPMqXxRa4TdMme1RvhydjdfxR4y5+A5CXusRcerbYeP FJvc1hzTRlsjnhFj1luYUtPNzuKuW3qdcdicbrtjHMCjxONkXe454zSs56C+vOuMqR1GrIzRONBZ a9nsNOtT2YvGus5AZ9Q46uw3busRu+aItO10WYwDhgJs+64zxkV2il1mZywG80FzR2uE6T+WzusY g7mqM9kwaD6oO+yI6AytOYDXTrc1mju4SnadGTJRxhSz0+y0T5t9zBo/b5Zbc46ls5utWaZKbHnd YZ3BtMSfZaytOUdb2irbGtvceI7C8vFqu9YcgRWEMQv7jhS/Oz8G7NBaYGwyp3cecsjWs9azR5dM 9i4nIJhLbTeFPXaoYcrFttaXQxtG1MJ6WFoLjl2wGHT7WnOYKb3FmOLp4FaFQGt6V72noKvebOHP mi2es8cu2Hjw+lVTHXh8o3tYX67P8pSAjVeNA+4Ny15sY0869n9PlX3A09ylxjb2MMalzgXs/11q +O7UHXBPe5I8Sd1L+uvGAU8RLru3LVOemqMtngKwvM+96B5wTxwxeyzH0plS3T7mjnvFo/bUG/NN Ke6bxmxjtonyHDQWdq61Fugn3dfMMAaG1zebS/TNXMgz5hkzTnOjbfnHbjH9nJ2LsxmmOm4VsCVE ClfI8qYBz6BB7TjIWLn9nNszyO14ZD3Lq7lMNoHr5ja4li7Zk8SlcEssz4xw2Z7bXLunr6uEq/Rc ZnrbRtk97F5m9tgZhj9ihWi7aqqzkOw97pptpg2QG1ipRT/Zdto0yl9qc7O1/HzbDkTMVf56K2Ob ac3ikTGbv2sbYWZNG06DAHYTartyBKt+EvumEG1rN6bgWOsqaWtkhvgb7nPCXk+qUOrJa3MDkoJy V2pnQDjEN4NXuIQhLpNL4S9bGaHXFmWmdPq2RsDSGcCfzHCXNeBYIWFKIAXeyjANQgN/FuJiQxjh 5/XIlG1MaWvx9OF9g4Hk6fP0cZWtt5hZZoEZYbZgn8jhJlqzPGc9Z7lVfU3nsv4s7Df5FtjxsA+Y 6sxs246xkS1l9+lZtsJeaVpqi+tGTBtMg7mAL+GL2nZ0IzhDfNZwbvawe4PV8/WeW6yBzwN/dfHz OOt1wh6mgRmx1uiGhBnTNHPHWGi7w2fBLliMYxSXLBXGbaYCItVqnGZ5fbmlogvZeGNh19WuM+wI O+5hdId0h8wWxw1jnRE807LMDumW2WjrbbbfuMReMbW7h49TXWqLgTVDWmBnzanHtUdb2ABELkR7 Zy3Ds728s62RO803c/vNVbwF4rhZ38z7GN6sMy3pLcDOxsBj9usRP2mimCmG5zvA8VjA44N8H39e P3g822kGr8pvzeEPsg1cNTOEPbMzWTf+bhzD3m7lZeMqxGh6W6GwYNcKV2DHXNOX2+eOFJt9nYec LuGeEO1iu1hzR9dBh9x5SNdrsgt3rDm805wqbAmbYkrXGH/JtNFVAp4zK1wUKXN6W76zAfaCCI5p 2xbcPUtYV54hDZyWgRF1JncmMzz2YmO2PourU7x27thdNtlzsKuIM4KlI6ZrpmF2t6msbYKb46bN ea1njpi5Jc95z3nunGfec4G7yaQxQ/o8lueTwAf26vqZEXbTUsv0My5jts7guctumlawD+Fr+hLP GX2Jtca94d6AXX+SydDfPWI1ZgI3b+ws5lOZwziOW+FpYJruTOaa+HTTkmkVnhEVRgpiB55lrZdN Wn1Saw7s9ajzHly92RqBZ1o3m6afZJJNO20TtmjnsjnC9Bp3zMis1h022XWGI9buHWbTeI4bNuW2 TeiRbtw0wJVx1fYm3SxzkRs4YjW5PREY5Zinzz3KkvBktHOjwIuWwMe3uWqWZ+8cgUhwr3K5XD7E xHVul+cSM8XyXTXGHaYUGEcKsUqsIkT8mvg1IlQbqg1EUj+kxpGKeoH6MdJQZ6l5lES9QS2jD1G/ oX6LPkLdoN5Bu6l/pm6jbOov1F20R+E4uTQk9AD9EP0QyqP30/vRg5oJzQTaC330/h86p9uH8hSW 9BhwpOehNWZJ1YoC/yU0jxZQjcKVvqwo8HWKAv8VhTd9VeFNDQpvekLhTY3ovwJvelLhTYcU3vSP wJs+ipoUxmRTGJNDYUxOhTGdUBiTS2FMJxXG5FEYE6swJl5hTILCmESFMXkVxuRTGJNfUelDikof UVT6UbIE2NCYwoZeVU4Y/1ZR4zexGk+QWI0n1PiEMaHBmjyRQL5Evkq8D6vxRDqwpN8T+YoOv4/c JDeJTytqfCH5zypEPIT5EfGoosB/TVHgn8L8iGhWdPivY35EtCg6vF7R4Y8oOny7osN/Q9HhOxQd /qiiwxsoM9VNdAJjchEMPsdM2BSl/Tl8jpkYUvT27yp6+/cUvX0En2MmfoDPMRNj+Bwz8byit8/Q G+ok4qeKln5N0dJ/i5kUcV1R1H+nKOrr6k+pP038HvMp4ob6YfWXiXewfk6SWD8nVVg/Jyl1m7qN pDGrItXq59RvkRrMocj9mEORD2O1nCzBajlZitkT+XnMnshyzJ7IRzF7IisxeyKfwOyJbAT2JJJP Knq4U/Oi5m2SxQyI/J6ieI8pivfziuI9rijeP1IU7wlF8X5BUbwnFcX7nxTFe0pRvH+MT1eT0/h0 NfmmomP/UtGxryg69q8UHXsVn64m3078nfZ95FXgUPeraMyhVEmYQ6nuwxxKlYw5lOr9mEOpUoBD 1ao+gNmT6rOYPak+h9mTqgyzJ9XnMXtSlWP2pPoCsKctVQVwnFLVIrCbr6t+oejA/w0RRDHR9zfO 8oT4Hy7/bzXr9ru2aqRqv/30NPwk228+PQ7fN2y18Nm1p4dssO+1X7HVQ2nZVtXZB6ULSv15236l /jnbXihNP221ZUBp/BvTUBqxZXXq/i/tl/9TD6dvqlP+9hdyX732v2byd/Ysa/+TCdYRe1VznV22 Xnlq1rppvWK9d2TnqOUps2OPY5+jWLfi0LemOcYds46LjtmWS/Ysex60GbeO26usa0/NPjV71GK/ ZL1nS7HlNp6x33ak6VasM99Yd+gd1tY0uM+sdehEyYn6Ex0nnCf6TvQ595+4dOI6lPpOXHeluXaf 6HDVug67DC6Xi3ftgWuXXP2uIdcItKmBWizUuwz1IblIyMVQ3+UKuPZASxbKs09ZbRO2CafRNu3s 7mh/MsF2zjanq3PabYsd7U63bQlGyD+Z8JT5qVldy5MZTtG24gzZVp1xPCbXumvrRB/0dcl1B3ro O1GFR3SSgn6vu2pPjLn4kyn/xt73ALWRnXl2CwkYmRBCiEMYxkMYLBiChSwYEEKDMX9kBmMZa4gQ khD61y2iEVIPQUJqdbcajuNYzstSPo7z+gghhOI4zkuxLuJyWEJxHMt6CUsIYQlLHJYlhBDi8nKc yyEO572v27vj3dq6uautuqrUlevVk/hev9f9vj/vfT8++n20nWUH25LbUqlzoafMgu3WR+tUBbNB ualFZpdxMU+oxYaWumhaUheN36PnQ8/pFbcrnIgv4Avhc+FEKJnMQjjPdovcoQL4BifhWhhD7rhd FEId0pNUJMwE5+eyHx5oU4fHwmtt5jaCTQBZvJyHG+Yx1HYP5ALyaZuFstC2BCWj7VHbLrvf1sOe sCwn0zYCrvewkrY7IKc1i7ahBUuA0RK6ke2kEkFmEjarYf6jfXKEK5wWqVOL1qJtktFZ5ElIHHI1 BegUcgQvphtDStD4ThCnOujH5GRTwC2maqj+hhZykl4nx0MEWEIF+QL6t7gyQ1WYjVLhG9A2Aa3H 1DJYThE9T66H/NRUqC90JzQUGoVnTgL/W/hGCKRJe8DSthxr9H39FNVLTTPCsCWMszPhAK/17nBv eJgt+nuLWQwfhQ9BU0lsCqtgy1gTS7L3Of2wnRx/YC+T4anwNEisHyQmhxFu+GkbZDIGVytBwwPh knBz+JS9FV4OG9jb4QpoecY2si0w9iG7wq6zW2AFLBvNxrI61gN34uwiEJ4Lr5Ej+ilynLf4Ggon jogjapjcp+Ya5kNnMQVY/yGtYJSWO5Y7dCO0kmANM441sMk7zGhogbnHPIBtHyywbpIZYu6C/c3C yF2mOHQA0nwcesJQnFWHA+wJaDSOfdwmbpOyL9pyWVt4ry6a3QGdplKL4bSmALPEJHO2B5a3S8Uw B9QitVgXzTzlbC8cGY6hV5rGOJsjt5hVKLucpcHIRLDSeCozLAP9HNpuMUv0SjgeOBpnHjGPuD7M 8zBC4bVP4Emrbe1txW3KNnVbFVihuc3R5uLXpKTNz9vhaNtdWA99XBtYINVGhfc4a+Vo6JUQ1rRt hKdAR/ttxdDvQdsBFG2bnrfMrrYesHCCSquL/loVlUdpKAOso2YqQC3jSiaDPuFWKaxTcSg5JCS3 MAW3D9VuwE70IqSmTSEpbaIVdCWtY4phj5knH9I6rx4ssJN+GGpnqsCWwJ5C2rrxkIMqCd1l4iic yaBgB6I2G1rsj+yPQvqQmeObHKdvfS35a8n0TULGWWGoJ9Rl0Bq0jNgoo2TM2YYWkFIyk0oxMJs4 Rtqww+Q6uhtIQzIdTQvoWDqJ0VIq6ohRQinGc2F/vE0PhnKpTWoTL2b0IYo+diUyZtCNknEwLppb b5PkfWqb2qOz6DK6mrbRLL1PDVBjoWLgf5GWMGp6nBwkxy1ag/Qf9mDoC/sv2NUkvcLtvPyKraBw kJqlYR6scgVLoLrrosN7/OnVPxP+GYII/1z45wgq/L7w++Bb/kL4F+BbfiD8AX961Y38K4TLls6h 3iQe9SbzqPdtHvWm8Kj3yzzqTeNR73ke9Up41JvBo953edSbyaPer/CoN4tHvdk86pXxqPcij3o1 POqt5lHvDR71annU+yGPemt41KvjUW8tj3rreNRr4FGvkUe9Jh711vOo18z/ncAqeB+Qro1Huozg vwm+j/Tz75R8k0OxyHc4FIt8l0OxyDSHYpE/4VAsMstH+Zf5KP8uH+Xf56P8v+Cj/Ad8lP9XHIpF /paP9R/xsf7/zsf6j/lY///gY/1P+Vj/MyElZJFfi44jY5BTHoN+kcegiTwG/RKPQZN4DPomj0GT eQz6No9BU/h3OPL5dzgU/DscBRwGRZX8mxyFgEFXURUf03fxMf2P+Ji+m4/pN/ExfQ8f0/fyMX2C j+l/zMf0m/mYvo+P6fv5mP6/4WP6XRwqRX8vaj7qp+gEH5Ff4iPyP+Qj8mt8RP5HfER+/Y1j8Rn0 LzkEif4tH4V/xkfhf81H4U/4KPxv+Cj8cw5Bor/lEKTgHf59hXf59xUy+fcVvsK/r5DFIUjBBQ5B CqQcghRMcQhS8F/5qPfPAJXcRqZfYZNr6n9WPxWh1d4J5iERtX1BVbAEqJvBXPjsDKZCGxvMCEqB Chg6gGoOJgUBE9W6sHmgHMGYYBpQpsAJULrAiyCsilpN4AioisBR4PT/ahV9gq+iE6IzeR6SEDCz qvZ/qBGnH+3W5ToaA4f2uaAkKA8WeRaCnmBLkA3eDo4EV5wrwXV3pGEA0xoSsYXANCm1TBiGA3OB tcB24CgYi097loKNQbY+YEwKrgS3SDGmJVOD43DtWGvCVq1b+kmsi2ynHcYd7Am5QR44k2yjlimT mXSQVder6w40Aa4Hvocf0sXXSToVu2NBSK1+ki427pCr2BP3sPGxwW2puV6EZ9IPcAO9G3xI9tU9 uT5IOuhRYzVZZdKHBXV9daPVwrqej/Uf7VqOwibniqEkzFrG7JvhmfDD6g1sibqJrRrw8LE1K3yi mWaefZwRjsaqaEfDg3B1WAe9W8Ke8Eh4nNZTN8mq8E2syljtUBiTOPkE2VCNfc4wHCwKNYN8WgLL nHSw1eBKqMO5gtdg2lB3qJ+UhgZCwx/thgwhd/XTEBPqDU0Zi0JzdS5G9bG+Th9aZErqXJYJy7a9 hCxmapzVoWWT2cKE9pwmRua0QT9DKI+xhNacjTxPwE21UDMNHDGWI+cKtAFH+hn7ZqgmPGNYo24a 0qwt1ixnZ/DhR7uGSG6elMA+R0UHk7RZNwJUEcyy6OUcHY2Y1lFE3Sel1MNgC7VD7X+cSj02IB/r qZMbAUMNdRvuNuBZoF5Q1SRFDQYrqcngCqbWmmhxfXxtLxPAuqwvsCUnSNFZZIkxFpnM9edIh3Xr hoEupuPwQ6LIuOPcYo6c+1adYe2GzHlsODSO0GdvyOoOOM07R5yTxh1mO1RjMpvEhmGTvs7B8cgq q4VscTjLuu+8aUwKsx/tvuSvro+6ye5qE6xZ7NM2pC2+LdFqwy2GQ+txW5px/ToZOKrrw5Y4XbM9 7Ci7xD5nH9k3q3fJducxmXxjGZ8L3w4/JuPog/AW1mU4F5wPPgx7iCznbXKV7AtsGiLt08YTsPyj wDNDpGkXrBfWH6wARdDG6Tg4yNl/cCe4TwrJYk7HZBw+R2aQuWAHKcEU/XrgNCgIdgZvBieD93UP gi9pXbA6+BjuNI/nkcpgbGAxsFcfIM8aBpwzhkSwmwRYXSfaJMtEsFK/rl93FAVfBMuCJKk0nujX rcfYKrZKqmkl2P8s2U62Ywf0KnkQQshiepReCJ3DO+gn1atMDKwUs/sc/ox0heJDiQ4J7aDvkS4m ntQb9pg0utiN00P0c3IDb6Y36Fx6l5HViWk1+QhKVXUPXUw+wLr0j68f30BCqlAJtqoH3ZALdfAk OoN+Si6RT5hzDGIiDP2GZqfAYKlzaLk11odVhRPqXGQxrCtJWP6xPqyozcOeOlfCneGb0DapJ8Pr BhVnm+GdsCd4HPZopsNZ4SynJJwUjA6TwVvhW8EZrSA8yNOVQVN4PpxFZIXvh1/QDuY0HOvODO/X nTWu286CvaeEbcwYrgqfsOIbvWwcezZchi25Mw15jpbwSrgo3MgK6/qsxzfGTJSJIB2WKWeRQ3Kj 96Pn5CxdjD3Fnlr2QpH4OdJsMns7rI2eKvcafYAvGk8MFViX9ygI64KzAeNJqBt2vxX8WShQuxma tp2tczk9Tg+s1WVnS2A7tGcS1t3jKqxPnL4X2qSrQtuMm9wI7TEa+yYnGa4Y0up6jI/rYxyDtQOs lE3F2kOW0BhTwSaHNGxGSBPCQxNB0oDATvEsdETFUgmUhJLfWKYUwTLKQ7EUSXVSt+CpE9QMNU6t UFvUcShAtcC6zKIqKRtlotYpXWAN7DIF1vVh6JSaJ6UGhBZSSVRKUEc1BpapkWASVcb0Ox+H5vRF TDPTwXQzA1gV7BUjzJjzPjNtS2XmmEVYtcXMGrPM7DnXjTt1QwzDDJNLzBQzwRxSZZZe7I5D4j0C ubndFmYTPwSLTHZ2Mr3OQee4QeacudHrMbN6+5zxxBhNpbBqtoo1sy6WYP3hImcjO8veZRfABk5A dwfsRlukaajtHHuPfWA5Yh0sxd4JF7XFsH0fZ4DVZNk32VwoT6xZhsO2TOwOq2W72KGmEXY1LGHb sT7jjnGHlmIPsFlsyfHQsMdZsSHP5CKr6sxklS5ZqyCfh2LoO3QPfdfReF2Bn4byjCOw+zzyFNuU Gou1kd4l75BDTQpylLwLFrCHdRljmUQm03uk0zqqibKPnoQq6uNNZlxlLCJ36a7rnaE0cpa7RvpJ gqTw6VCmexifInsMifjmV1/YAzRFU4YjZzQ25Ghxxl5/YUvFmRu9dDuTh6VWi+0TjkbTbt0CrsEr 8BrcgvXBrmd2ptS5dBlOibHyRia+7O7HupzyGypnLN5Ru1nbaziqP+dMcSqcRfha/TnLBNmFJ+J5 9N1qscGNM4ZM3SxN0P6Q7Po89pxecmbhm2QVeNF22kUukE/pPhJ8qreD3vX0gWYjmUQ6FdrNoGct raeryNWmRvIe6XC7Qx3150I1gA4ihH8n/DsEYIRIiKCiN0RvQNvrGPbrGPbrGPbvWAwb6YWV8wl6 L174pH7qbx41+z4dElGz8+E2fAtqNt3wm3fNmq8G2pY/XPJVALVgPARq9sMZnxYReAK+aiTC0+yr 5vuP+WRwbfjDIV8iUHfqBoHq+/CWL/V/u3N88ttGRGNEx6u3m4sT/nFFRxqIqvnaZ+5ArcY95Z5z L9u0VzuaBE2xTZImeZPJaGoyNfRpMvU710brtO6KppkalUbWQLgtMIap1RgqbNrKvqbYG5GasSZT U+PLnk1yN9PE+gy+Zt+EP9qf4Jf4Ff4yX8DXzFMp/kq/zd/iW/TN+Wd8htpFbg5NsZ7dWo1G5l72 IjZtk8Bt4GZQZ24yeeONprpd/Y430ZvWNOPN9MLzPQee52Xt3hjvOW+Jz916tjW5NbX1rK/Xv96a 4WNapQ3EtT7unpdnazXefvdY+XR5pHe5SeJefnm/2mf6ndploqxpprW9SUB4WnsckwR5rcexT3SW R7aqCQmRpMnkZOHd9oiJLPdyq7/JpF9v7Wu90zpUR9X1+aM9u62jvgkj2zQOPN/1lTTpfHNu/Fpf bcX1Th/iZtwd1/qqiSaTe8w95TtXu+w+4vhqyuLk6qtoaintbFrh+NLvGDRN95vmgfcJ90SVzRfj 7vWlfX3FJ/PlVaphfLe7173n3vZp3GO+kroFjaxW0/LcF3kjUr+jyTRWXht1G3yJVzt8NeVjNSr3 cpWtyla73NCnc+lXNLLrnVW2r3K6MPhwTh+gEYXf5F/3Wfzjvn7/Tf9tX7+P8W/5q/33/Vm+U/+O /8T/olXYKub0B/qK9pt83f4iX7wv06dy97sPfRa4Twe0CaAm+Rt9y761JpDo9U6uehPdU00mQ4c3 8ip+teKrI5xWQCO57qm6vlZlXZzniTfP88jz1Ktq1V7rAX12tBa3VrnHPAfeuXKDd1Hn8p62uoho TkM1qhpVK9VKtHYRjQTrjfRG2rSgA32r4+tkk6DV7LaAdCZAox3eDo2haeZaD3HLO2aYdu95n7kN hNw99uGd1rv+6NZ7vubWB/5Yn8Hv8ev8JPB7y7fp2/bt+Q6B33n/Q/9Ka5xf7h8EjoDyDfsGfGP+ EX+Kb9rP+jv9x/7HmmX/vs8NvEz5Jz+x7DLfka/Dn+B75o3n37pFRSiswwgRuA9RpCgSEYiiRdH8 W7f9/+9yRiEdUC4gnVCkSBeUbKQb6YF7cyfD3uN9ej749EVEAX79ITyN8+lK3qcX8ufA3keFqAi5 xOeeusz71hLet5r53FMWQZHgEmIVXBZcRuyCUkEp4hCUC9QIJvhA8AHiFFQJqpBGwVcFX0W+JqgV 1CIu3gt/xHvhFv5cVzd/rquHz1X1B/zprl4+V9W/EywIFpD/IPix4MfIbT77+x/ykbg7fCTuP/J5 3wcETwVPkW8Ifi34NTLIx9q+yWe4GuIzXH2Lz3A1zGe4+jZ3NgsZ5fNc/Sc+z9UP+DxXq3yeqx/y ea5+xOe52uDzXP2Yz3O1xee5+gmf5+pAdCB6ivxS9Ez0DHkmOhH9Bvm16FT0AvlNJBqJIqfwWCHy PyPFkTHIC97bouBn5aiAP30ljLwUeQmUro5Uo5GRVyOr0KhIDXjeN/jI3Wf4yF0sH7n7LB+5iwOf +230c/zpq3gusxaawGXWQr/AZdZCz3KZtdAvcpm10MQoT5QH/VIUEdWMJkX5ovzoW1GBqAD6dlQo KoSmRLVFtaNf5jwv+g543nn03ag/jfpT9GLUStQKKo/6YdQP0ZyoH0X9CM2N+suoDfQ9ziOj+ZxH RhWcR0YLOM+LKjnPixZynhdVcZ4XfZ/zvKiez81l5nNzNfC5uSx8bi4rn5vLxufmsr/x2zd+ixLc f9lAP+ZOOKHNXE509OviLvHvoT7xvxX/Ptoq7hP3oaS4X9yPhsTfEA+ilHhI/C2UEY+IR1BW/J/F /wVtE/+R+I/QDvE98T30X4u/I/4TtFP8PfEs+vviOfEC+gfiffE+2if+lfhX6L8/k3PmPbT/zOUz l9E/PHPlzAfonTNXz1Sh3zijPaNFv3lGf0aPDp2pP1OPfutMw5kGdJjPHvZt8IJ9yOQrX1gQ/U/q p/pvTyfRD/6YJQaIYc47E33w2UyMQpub6OIpBzEOlJkg4Vvg0RFjQFUTbvgWeCqIdqBKCDNBAKUk ON+eS1QTLf+HfePVGaXeyEY+75kasDmieF3/BRUdMSReiSuTFq7qtAX41dPSeaXtcoYKL1+rflLq uXqqr756Wpjr1ZRsq2LKx7w1qu6S7XLGkFi8VSYt3ddplSNKW5m/fE19q3zt6qlu9WXPUk/pvmrN a/A2gx8ygO+Z8uJQm6Fw1AT8vAm119tBpHhPVTg3hwJc+UKnLWdK568eKm0q3JvGzaBEdfW07JG+ Wp1Qsl3QUWJQdVdFX++E/mKtqURWfaA6rF30qIkWsDCW6PROEHLiJpFA3OLuyN1TK9Bpy9Sa03LZ FaX6Jtxx/uX9yqQl21eGSgWqbmKGmC9NKk0pU2qzVL1qud5DPKzaKtkuk3o1nCyKB8v0wPMEcR+k YSJWiHVii+OI2CJ2iH1vx9VTVUzJtu4uV7wd1xPguUOqEm8mSCeXk6puSZ1QgHsrqtWXMzi+Lus5 uV6m1CeFuWV9HF/wLHPBHCdXxax6sDzGm+dVOfYd+5VmVfPV06unBZs69fWRqrKCDs2p7q5yvJzR aQHlydS3mmyq7fJlVYw3zVtyOePqoQvuVjpfOlg6qForzC2dBz0yqpLS8StLoAsD6ADncIF30btG yL0WItobgJZn8NlMKICjJO+0d4woInSEibARjbz+uHF73Fid+mqN7oGuqjTJa+E1yZemIu+Yt9/b D1KVqkq4WtDB2ZEq3qUr3FUPFg4RLaCVBOK24i48YdCQWDrP6Y/7JMZVvaq1AhzsDzR0RUlMXlFe TyidL3eX5+kVnIa4ourWHBLzBXNlPRyKU9o4PQKP88R89ZPiLd2SYhYkhBfgqm5Vd5mr6vYVKTGi Zjk9l2yrE9Q3gUODd5nnwwJlG34+JBK8w7wkBrwDRCUg2yzg2+Od4zjiKYYrhIAQeLu9R95DaK1W WYgyrxs49hCxf2/ZnE33e5vBGobLHsHOpEH/GP1j2Ji+g34Hdqnvot9FBOj30O8hEeg8Oo8I0UV0 ERGhS+gSEomuoCtIFLqGriHR6Aa6gbyBbqFbiDgiOyIbORPx44gfIzERfxXxV8hnIn4S8RMkNuKn ET9FPhvx1xF/jcRF/E3E3yCfi/hZxM+Q+IifR/wc+XzELyJ+gSQIB4QDyBeEg8JB5KxwSDiEfFE4 LBxGEoUjwhHkS8JR4SiSJBwTjiFvCseF40iy8K7wLvKW8J7wHnJOuCHcQN4Wbgo3kRThlnAL+bLw kfARkircFm4j7wh3hDtImvDnwp8j54W/EP4CkQh/Kfwlki58InyCZAiPhEfIu8Jj4TGSKTwRniBf Eb4QvkCy+D38Ar+HS/k9PJvfw2WiM6IzyEXRZ0SfQeSiz4o+i+SIPif6HJIr+rzo88h7oi+IvoDk ib4o+iKSL/qS6EuIQvSm6E2kQPSW6C1EKXpb9DZSKPqy6MuISvSO6B3kfdF50XmkSJQuSkcuiTJF mUixKEuUhVwWSUVSpEQkE8mQUpFcJEfKRLmiXKRclCfKQ9SiAlEBciVmKWYJqYhZjllGPohZiVlB KmNWY1aRqzFrMWtIVcx6zDrgztdI9TVSfY1UfweQKjoT0fcK70nNr+u/oH4qoscC+A4SgTXj+/hj oFz4Nnw68ENoM+NrPKXDnwBVjT+CbwFWAf0isBJ8he+vxOeAysXH8CmgsvA7QEnwe/iD177x/1vf +Cqmaoqwvfq/Vplz6Mi12XJV4erVw8LV7Af5pvoKTIqp66QFgcqN8jlZd/59WfcFBPMrihV3y+ew dqxLHfve7rXZXLZwtfBs4Wp5L/QvLggoFQUBzIw5uJ75SeVzpUX59+3x2BC2ZFvAE3GZbQOXYaPY KB6Dp+GZuAyvAZr7y/uYfSw7mZtD/m3pSOHqe7v1FSUTmLROalviZlAolHUr4V7ZXYrigl6FA+ty CpTz12aV1eWarPbrLfip7sCZ4pQ4spxy24HDZN+0d+NjTgV3R+6e5qLCVbMCi7vcpehxVldu1Fe8 vF/hqqLYyRZYsK78yUvNWIaz03nTeUtRLCXxZwZVIVESfyEG83OyKHvgtDnJ+grHoKy7pMM54hy3 7uCJzodWgXPS0YKtyroLZxXF14a4gq0WF5WrimPzox07hWcV5uLYUokmXtYhJbGz5kZMieWWtZc5 OLliLoyQHldlcXxB0ZfPKeUwJ2UB/EbgOHa8qD13ORmrwrRlcbJux2PHCZaKJV+exeKuDcnc7+0W rjq2HPtKBUZd63N48pNsS459TF14r1hRelJfkV8GpfMCUnivDn5jzI/Orywts8fb90DeoA9sFS/B NfZNrAcfwO7hDN7tWAe9zIFOJvA8AECL+Db3Hg2eBvrj9BWD41BLMPHlO5geE2IZWA82atVhd606 PBI/hxuwXewApLB6oYN7mvKhlJR1OxMUo/k6Z1K22JnlMIFGigrWnA+dZfgz84oz2tzZ0OWMdVYq d/I7peR7LrOi6J6i54JM8by2o76itNrZ4vRwGlLHqmPrm9WKS82X7zpvOxudjZiU02PhvfqKS831 27msJl6hlHVLSSlZ34x1KfTOwfwspcmpc5ryTUaFrMPIOu+DpmawUec8Hg/Fglfgbtj7OkASTyzd 2FPYMafwacsefoSrLHPYXY7CZrEH2ALei/djj/BmPIBvWisvLOLL2B2w4Q18mJMMWDZn07uWOTwN e64s4v/f0vPXOPQ1Dn2NQ38XcCisjp5Xnu6djU/HVOYly0MkwvLQPGtZAeq+ZQ8RmHYta9A2ZR63 zAG1bnkE1Kh5AL4FpkULCdS6uccyD/1vWiaA6jazlgFE0FBpMQNFmZsto5/sCq/OqOyKDl9llHqn iKuCn1+Jk4gta4VD0v0CTW6S3CF3vb8FLQPvC+SjadAuEZ/3SGfyd7geOTU5A9J9+caVuOxUy9pF kmvjRshdGaxcmNGSP6huaXietlZ0Vjoj02Q9ytHk7RUOFbrOv5CIrSnWLGuZtdLaaL1pvW0dv1ZV tW7dsT62xVmPbVJblU1qLbL5rz2xUbY+2x3bkE1oG4UxEhhTDWPuX6uyrlsfW1/wvZUve1qPrdU2 s+2BbDg3Ol0meXrxuL7bsljoSpfJxix7sjHZVIbk3VTLctqaZKmkWZkkV17MSpdZoy296dNSMqeG nxM3m0Z41ri1Ep6xY03hZqRxw1MObFXWTnjOU9tz25AdsUdeibs4mLOct8jL4pl8Q1otEUviMgZl w2lrudGFQ5Y1uRquHOUMyJrljq/O52xLX6htV4T13TJDdrtljJufdIaTsDzOCrLOjZbB3HIr05dh JkXcXOyZ1ka7zMraK+w1tgcwk/G/n0fZtSea0+tJMA+3/fC6xH7qENiK7ZvWW45Yq9zmt89Zy0Am IFN7t33Yvmjfs6+BRCcLNLKKjEFbrq09f+faE+k+SC/Zlip3ZT2CmYvlwhymcCh9uUBToLFsZ89C CyGbKnTlJEpNOR0S1405q0C+Ud+dg5xPUd7MiC1oTtvOTUpbU96U7Fp6C5+CBPZzulWavEXgaAmK ErhTnm9MW5T4oYgLDqX7+QnSfcumZbp0K5+1zEnEhUNgMQ7oR6Sr8rckcWWEfCP7Qd7ieXl6tzXa qgA5DILOOa3rrCZrC3BBcjrSnFpXrA+tO7azvAUU2/Q2wnaX08+1J9DSA3XUylpZ2z2rzSa2ZVgH YaTNOn+tC9qSbWq42ghSLrOeQP8RkFkXUB7rls1hc9mEmhLbrG3BtgTy9ltPwPa0MI9J6z6MKrPe ss5ITZzW5aOSuLTt0se5lZI4sHxCTlj20tduRHIr5bznfFG+SbGUvyPJze7KaJTuq2PTZfJd+a5s TD6ao8puL2nOML0sYH8TaWs5YxnH2Uvplve3SpplYzDbspfF9tR607Zrj7c9sifaz9meFLpsq7YN e4y0Ol2VG53TLTl4VwhrMDVHJnmU8TBbnJugZDNiX9qedP88KxenD6QPyB1lrjKX5KwkThInG5Y7 MgYLtrNT07bVsWlreYs53WmLOQOwNnNVzdaEwgcSoeRpth84i7ZrHNHWFHuajbDngR0a7DhYXLN1 0j5mn7L3c3YI0hHaN2137Ef2Z7Zk+4R94lqV3WIPwNVJ+6G91yoBXljQ0axt1r4NFrvpSLCr7CX2 DvuAfdq+bCXtjLyHs4LSx0aP7oF8o+C08ClnL/LkjAT4zJWIFUt5e5ZhFV5SU3+YPpDdXrqTs2bp tYxBeWYZk+vPK84XSWckROWdtNN8EtDcTk6NdP9CPNjSkjr2vMkyYZlS3spNyIH1VeiSDVv6S5ql NrlDEsddKxTXzl3slCyob2Ww7yYX9cg0Za7s2eyli7qLuvTIjJSiuLyJ/MpcSUZsQ0/pY8uhZeBi ZeFs/nF2e/Y99UrpiwxB9qzlSN6Ttpa2lj6dLktbzjm0xsqaTauyYel+ruLKQn5lTkca7BTpkbAz TedMSeIsp7Dax/I6ipJl7vSBwtmMloYeCZVfJk++kvv+bYn/QneO7GIlaAxWSIHGdCB3vNyDC4e4 /ff8TVhpA9zOC3Ible6XPpZvZBzLXbBuKguH1Ou50bYDPk/f94U/eH365PXpk9+h0yf/JI9l0kO+ fioiko1fUiARshFjO3wLZANGEj77L6mgrdfouZQJVNelYqDa303K6QKKNALqkbW8GwPfApn7UjxQ uLHsEgKUOXsEKH3GUY72H62PV+dKYqLjX2G1pMyI0wuNmSnpRZlb2Ylv5741/cHuWwYjYfRn7hsd xnbJovGu8cEHudJk41LyakZP8kF6VrqpUmVMNqYaM4oQY9Vbh0aXdDVzP3M+cx96jxoXjEvGDWMX XLv7PvFu2rslUq1kKm1fFi2l0pJMqvf6MxtllTLbV8SyEdl92fxbFZfGzcVm/dsZknizS7Jcr8ve rDdJtVJtfYuUMsmkLqkrJyuzUdoH4xrfvC/rrKjOTErbvzRulJrV9StvzsjGpVTti7dTzz18O64h 782ZDLNc1VBT8DB3Vq55Lz5zBigmvTpZn6GU/C/2zj26qur69/vsvfY+IQVUtBYlLzEkOYGck4Tw Dg8RMTxEpAg0OTknIiIiUlTERxFTREWKFBFRERERERURKSIiIo2oESkiIlJERKSpIkXkRxH5aXLX /MzU9tfb25+/P+4Yd9zhOON8MzP32nO95lprzrnWPntFtGvl0eGHIk1jTZMtkxmlw7K3JvPzJiUH pY8u2fDz7SUb8tdfVJ6cl9c1uThZlb21uLRif2aetE9aavusWMv+pf32R0/a9plUMKbfwNiyyLIO GfGbSidGnIrN0f1txua2i7UscwvGxEfHx2XsKDozNjQ+LW9p7p354xNzW63PH9ZtV2J+q5pMU1Db pU9kWcbuzMPddrVNLTqZWJ7VIrE2PT8tmtgQnzdgfHxBUZrUKVLVvj6jLvdQXqIoNbuuS210stSo sn/++vSNxaXtR+Z1zZyQ22f4oZxdmZullFLO3FtiLdsXd98wcFPB+oL1/Qb2298hY1B16cTcHhWb Y7Nzq3Pb5a0ddryyXWVx++rKzm0G5k+s7JGTn5aavz63RzRN+j6+N3688ozKnMxVHTIyR3SfkNUi 0jF/ZEZWzuoOhbEjRfsv3NttSlFa+7q2qekrCpdEerdakxgbW51fU3ygOKho3TYtb2DJ8szDkbJL Rha3zB9Z2SdSml4mPZ84KbVK2vK3TR1ek348OjnXlToWl9t+21JcmD0mb3rx6uJBeYn89XmfFZdm ts7rWjE9zww/1OZk8d7YgiJbluKD3Y9VnV2VlVMVqcqbldk6bUR2XXLokIHJI1UpVWfkLcpfHy3J tnqYtq1taqJX/vqcFaXtuk7ttjjNVMytmJ+bVTI/OTpnRbwwu64422r9LRXR3B49nLxeFSWxlvau XhVD0tdVjMiMSh9XTB60MueNghNdRlZEoyXSxxXbcsfnjBb9z10SWdFqa0XXil5dt3XdFltWMcve t0j+t6MmUbFqeE3B1rZdc5dU9C0YY8dWTcXm/IV5e9K2FYyJtbSja0NsXG683/6iM4umR3b1K0kv L9hasaegOrd/erkdMdkZ9XbUjKrcXXGy4mTm8oTpMC86K7Is++zCOYVPZ0YTXYuGMFJmVt4Zya84 lj8mb3LsYGFK5Y6Kw4kJBdW2VYZUjs9ZV1lrvyszlxeuj/ROlCQmR8pyVsd7V65JpGZOT4yNZ+eO yXCLNuXGi0bFZkey7YibHJ2cXhZd1H1Cz6ejU6PT0/q2WZ5enju+MCtne/sxORvzd2R0zmiXvTW3 T3F2zrcZWblustR+exdsTZvVpbZ4aJuxdqxV5c9Mzo4csbo5K7kgfUvOChlrGYPzd2csTGZX9MpY 0nVbh/yKWa3WJ6+T/5NlFYnkTcWFyXEZD6YlkoXRyZmtczvndS0uzByRHtj/Tk2WJ6d1mBdpmlyW uTNSnlzRd3/aiNzOuXVps5Izsuuy69ISGZ1zF9oyrrCtWC3zRuxgRm08P55f+WDarMJ2tuXKKmtk vknY1o43tZ9BBXfmrM5Ls+Pz28xFuT0iB+Qb3W/HzqFu5fHr4jPis+NT8sdHmhZtyDQdpsW2JFYl lue1zj5bvvF5iU2JpfHFRfPjyxKb7XyWkbBaZ2efznwnRKoi8yJTimckVyfXFWbZeWJ/mZuYH52c l5AxKv+ll7cZWDoxLTW+Or4x/kZ6edr0gpqKRHp5/NuCrZl9K5sXTKw8236ySqYP3NNlX/bMSrcy Jb08NjtvavxgennGmviBitY9puQusXPPivi6yqwee2PTsoL4loyn47viR2JNSw5nrI9vH7470tHO sD0Sdm5O7B++u8uaysGJw7F1eYfP3VL8bbJp+yWFzQubJ0Z1H9L2zMi06KiinYk9ic9y5ySd2Lqu rSPLYhtju7pvin1r221bYmdiVFFe7I2Sz4pGxI70S00GWS2K52XUJo6lV+WssyN1enJjZFlye3FZ 30WJk8m9dsY9XlpTcKjKTS+NNI00rWqeeyJzpx0lU4smJL/Nrhs+M2d78qAdg6uTVcmMTGP1Y31y Y/KNquaZq87d1aouuSt/YZdhmRtyFuQXWw07kGl7Ne9Y+vHYQfs5EjtSsLByfTw/UhoprFxi14js /JHR+fFB8aHDdkWnZ5/dfmT/qliL6Kb0ppkTEq0TpxZuLdyRvzuRJ6MpkRZvEW9ZuK+odX5N7GDa kMSkyuro5vTSoiGVI6OHIx0zHoyUFo2It4jNbj8sutZ+7LWBq4YvHLiq8FC8Kl51YXY8yFvbrSq6 P7onc3/m/siyzD2xvbYkpd1HtY2WRGNHKp9OTE1Mz19ZlCjOzijuXVNZV7mv8lDl0WxrPrRNPXdL /pyiSd2P2fl+YGJIvDxyoMu+jD6JWcWFGXfmj4wsS19x7pbYYju/mvSm0SEFDxYOLhxfuLBgYsGD PdulmdzOlXMqF0Y3pFcVLa08kRYtSq34rKA67sTzo9PjZZFp7RdW1sedRDTeNJFIjIpOSu+Y37+g OtIyv3PlLbGD8Y6VY+IZmZMqb7HaZHtN4iWhvT8+P/Lj8yM/Pj/y/9zzI/8lotp82r/3H9o4xScc L/tkq1H2r5t9tFXc4qHcPpZX12pwbrH9b29umf1vV6ve9q+bvW2o9SayN7cqsX/d7Jqh7ex/61vl DM2y/63OOWb/W9GqZW6L72eI772H0HbvQU4cdHUGOE6zQ//N9+g//X/iB9zzt3T/Km1947eRbm7+ 9zTwjupfvqn2e6r+5fqZ/3Dtf/D9IeX+l+VJs9/WzoCmJ+XTzGkW2E9T+7eF/S+w3xbNWvLJaJZt P/n2b9Nmhc0K7ZWOXJVPof2WNuuNhLJmvZsNajbUfjo2K7ffwP7f0X6qQPmrVDZY1qzM3iPyR1sp o+1nKHJ724+90/btgB/PITSeQzhpTjrtOI1QwKmDKKcOYpw6KOTUQRGnDoo5ddCeUwclnDrowKmD jpw66MSpg86cOujCqYOunDroxqmDUk4ddOfUQQ9OHfTk1EEvTh2cx6mD3pw6OJ9TB304dXABpw76 curgQk4dlHHqoB+nDvr/2Iv/X/RiyJ1peGowtMbaUU7KrP/6bVJqv73tt6yRt+rv/H9O+0O+yFn1 36ST64ts2kH/xJ/f+BV66T/IWfX38lDe/+H3B5V96Q8o87+r86x/Xb4f1Ga9/+H/Dfa7yRkbjvMZ Fn46nGM/WeEx9r+V4ZHhNfYzPrze/i+fQ3yO2m+O5d9i04wMzyTN+nBNuDY8sVHK1vAOS9dw/0ib tn94t/3sA+WvUnVg/PtPtf3I3xokyudp8MQ/4FErbbz9W6+fFNP4SdUP5bbpUk5NkcjlL358v/G/ eL/xN+YbJ8pbjmO85biQtxwX8ZbjYt5y3J63HJfwluMOvOW4I2857sRbjjvzluMuvOW4K2857sZb jkt5y3F33nLcg7cc9+Qtx714y/F5vOW4N285Pp+3HPfhLccX8Jbjvrzl+ELeclzGW4778Zbj/rzl eABvOb6ItxwP4i3HF/OW48G85fgS3nI8hLccj+Atx6N4y/EVvOV4NG85vpK3HI/hLcdX/agZP2rG /0EzQqH80FS8ls1OzOrHVv26k+3ffX//3wv0K3z5+z2v6d/ThOoa79v6b74i81Djd9+/Tv99XtMb v1P/Tv/t2vfXp35fnpg7tPFTbj9V9jMaHOde595kP0PdKe40d4alquz1mxp5Q93ZpBsNf579LrCf eXxG288Ue4dcn2LHUPPG32rd+/1vtXr8VqsxvzNvOCn8Smsav9Kaxa+0nsuvtLbhV1oj/D5rW36f tR2/z1rA77NG/6/JtT6oeH+O0/AeuB88BO4Ct4LHwY+sJmSQfqreFZoMJsChYC9wBThb0B0EFoJ9 4C8B14L7wC3gnaRJgz4G1sCZBD2f0p4BZoB5YClXrwPHgAfBnWA9EkaCKWBXEP/b3Q1Wg3PBGeAB QS8fjIPfSt2p6VQtuZNKm8jv0Tn1i8EhYA8wC3TBNeAEEJn1Z4JI/u4wdFPoE7ZvqzhjfDc4HZwj NfXGQNeDv+cU1ATwNkH3M/DP4OeS3nLsLC56b+m3uOtScCjSLoAeyNVD0LOga0Hke9dC/wn8AvwS /JarZ4M38nwqWuRdAy4CU0g5nxL+FfpJUobAvxBz2ADuBl8BnwZfB58HnwO3IhM5/vuNaHvQPyh0 0J+rv0GyntB+FESC9yz4Ind9BR4Afw7/NRCZ3h/AdZT2CPQp0J9Ce9DaSuvBueD94EfgMkXRW3c7 dDdnkcVSRdFPty/0tWABJWlByamjiZDXJvg/A+vg0JLeeeCt4Erb7CFvGmloSb8ffLTC1MpV9zCc FeB/kGY0mArnPlLug/4lyLh2Sem9A+6HcwL6rEbcbu+iNULU3Y5nwZlcRZpLO7v/iXx61qNnffTN ux7sAaJX3pUgreqD3h1IoH+9vtD0vvVbRabyj0K3ht4CPkBJ5kCvAh8mTVuwUNsN+nTo28lxFLRL LpvBF+DQ78E50GlgGTgbROfdBvATx85p3ktIzkEmY8HOtHJVczxNMTTMpkTnrScu8snXR/esPSMY hn8mfNrTH0r6j8E9cFTC26ABL+JeetC/Dg4aFfwUvpb8FnAxuMa5BLzdpm8P/Ty4UdBMhE6ApyqG fIunSXo7uiVNE7AFeAa4hZRLBVPSFUNHLedc+AXcWwrdBjwP9MEs8GdgKni+Ivm+JrTVTMmlK9gN 7At/lWDwiKDVRsEnwBfA9aTsCb0AfBZODNTyUBc73i9hfFn0p4IekuPwPwM3gK/Cvwn6o0aU2u3l rofBr+A/Dq4mrzHQX0BHoSmt9zuQMtt5A3SbWM4z8J9B8rvQh8A/g9PADykJre29jORc6LOQcxj6 LfidqfscON25WghnLhJUB84El8GhJMaA38CPgO/B0R68ATwKh1pYa1boDoLhMFdPI69Hwfvh0Gte JdgWbAee7nxoJXyNnBMgZTOXKNrVIGTQCtMFXAxOImUR9GXgSMp/J0gJA1o+GELKRaTJA2mZ4AJy Ryu85fDfB+eDW7nrReiVToXF26APgmiI+QlyfglOgPMUd32OTPTTq+WqC03besj33ya9zh5bGxZY fkudN0LtZE6u32HpGXCwB8xvoVfpTC5XfeYEc139Rkkjd5mhYpN4usatdWotXihoysQacdW6WFe/ 12I+nGVyl/+AoLsQ+ayb7kI4rCDuWugasdMsWjp4mtyZn73vKM8i0rBqW5xnOY84Jy2Ww6kOdUSa 5bi/o4TVgu7jXH0KCXdCLybNcnCxM96mvJhctilKvt67DRfaq8z57hPkq7bQMXCrM0rWFLFdvWfq H5R5g5bRVXge6VfRtpPENjNv0fIbaPPXwTeZP8eT1yPki/Xr1de3sniAuv9C0GqgtP98kWPLLPbV OdhgM8hxtvYaOd4tNqQ3S9C9QWxXF3vD07XeF74ZI21ie3MxJVxM78j6spdSXUb6KeR7qdif7or6 acwPwn+3XubbGui36l+W+Vy0wraAtTkNq7y7hR5cSnmWipXuDyb3IbrK0CarKDnl96drW4lFYY5T BqwdQ/t4n0CrDqgNcA8camQm04ZYmz4aEujKey84D7wKROu8m0Da06M3vQ9AbDaTDRYj7UGwIzXC 0jO6DqrVUQR9A4g1YrD0DJaSwWLxvkHCMDAK9oav1s5xUjYBr+bqqdpHXH21cQ2Vq5kgVz0scA8r wmBd2JlB7lJr+WVwOahWdII0nUiDJePnwn8PPvrm0z7+eDhq1ZDeMFIMI8tgqXrY6oaWNGr5dOPe ahCbyvyKlPSLl4RPu/m0qlHLB7vO0CZG7YdWoM4/6aRXm2opSJlNFnxyNHvBS+BgmXha2imgyte6 nwQvB8eREqvVnMu9KoFyGqxEnx7xsK49ZkUfi8sw6j0tD5pjsG+t/ybzAK3nqaVHi3l3gcw8HnXx 1H4eDtLjHiPC+lOCJ7C30RyXnnUfA5HsovkutXNVe7G0zTZQtfcN+PqLPuqR4UEYZjAPaR7tb9Ar iZuwMgriN3n4C66O9GYgVqJX4p4hyNW1WP6vgV8yZhkpBs/FaNv+jrvw9bz5pFkLHz3x8sCecLDV reUg7YxPZ60yh7FpW9VVK111iVw8dMB6znLXImjWAq8CDjO8xyj2usDBrna1X9AZbyKIlhpoF2/R qD8ypbFPhdMLvII06he/iXWtueBFGrWcGeNGc8FHM+rh4jUbtZZVw3UGWEB9y1ijsVjMCOj7wLvA 67HK1MJ5kzS/ZjXHBvOfhJ8ErwLvBrE5PawUDzvBrtGCPcDbkInNY9tQcA+4H5mtsaCw36zuCWpJ PoaeAT4EB+vL60Op/gSNDeyrlbgSpIRGbTm1Uu4BsZDNYOgHQOwfa0UI9nevYSwL/XtwBfgb7lK7 dDp4L9gb1JbE+vK0/GpRF0Nj5bpqDWq+o8DnwONgKxCrz7sULAfVissEaRPvM7ESPWpt1E/B1jXk a22nS+hxSbkL3AmnGno2iB9h1J7EFjVYsN46EOvaYM2aO2hVRoSPPrt4cN7N0BpnwL8L43OFGdcu c5SnVhxrgdE5ZyMWURvuYuz4eM2uIvahyyoWoOFh9eirQOZSazkLv7r+FrGvSI/37T4iHH8MKzsj 3WOW9vBeAyJLPpEijzHl6aqq8R/mZJeZwewC1QffCe7gKiu+u0DnAYlrGdYvl1HsalSBGrlEZlzs VZc2MfmS3nup4VTLuY57twqGtWUqhHa3kZ4Yjqt2xQSQVdXVFRBbNyB6YL1RoWm3QNdNIh7+r6E1 KsXM42OHmBfE9jNDyP1GypNVv1nshIaolX+1cHxWfJ95PsDy8ZkbXW15+tTHbjdEaQLWSv807VlS joQziD7S9Y4Z1ahddCH0AOqrNrDWkSiBj11hiMb4tLbPvOdNoLSDSY89436JhA/hnwPGwMvA4WAZ aR5CzkvQrEoua7E7BTsW/TQ19AW2QRgbL4y1E25JW2H7+WiR0fjMlcifIXFaa91ZDOgj/xPVW/K6 DbwPvBucDN7a2PtDLL4MZ47qHrTGLmhDjyiZW9sQWMlzVItAjePNdzqx0lkMiKVY79thPpQ0jE0f yzMAzVjB0Nf114JS90PUopC7rpVa+E9JvNcl3mIYZT42p6vSsDYNum0oj0/reWpBYS17fbHqv0CX 0E9vOvXCInXHUPcugqEN2Px4HG4MHKsthjSsKZ8W8KmdTwzNEA0LsE4NFq/HWmbQPetrO3imwlGr W+06xmxYI3uqq9XiFbqs5i62t4sl6WMPh7HHPGK5wZ9ljLgzGCnb6z+z/F+QEvvEZY320GpfI8wa 3SoF1fbY1vAq87bQau8Row4YUwERQh9rxFe7ReOrWdIXRq30alJiOfjEx3zK5jcHsVTDzAOpcMJY 4GFWfF81Gd3w0Z8wVoFRy0dtDGLLAdZLUEWOzHhmBd50d2j0KkBbfPVudG4kL58ooiHGa9fEPTYl lr9L5Nald1xmVJcItovlaVZSHua6MG0YRkKYWdrXvu5ASqQZ4p+Gljc6c+rsincZID/AOwjw632s x0DjqMuxHtFqT7XxkJTTPS5ofV7Bb2Vnx1qMQntgJ+qCHH8biP77RIYDWibASvfxTczFztOWo/Me lqo/nDakfwOs5YD50Fc78PPGetk0ru4yED02WmvVQJ1R1Wam9436ODpOWb8M9qdRzwh/MFA7kLUs UL1CfsDq4KNXvnptPwlNtFcZBQE9FWD/B+hAwEoa6HrdC1qtVvTWaPlpgTDWexgL08+CrxrFmmXt 83JLdxI0NeA2QeuvCb0BbNKIR/BAy9FwwVr4SwSb+Iqy/2Ui8NuDXcA2YEvwEkFrWZWzBgneCz7R SNtczGWk+YBcKJs/ADwf/mzB8FJBu46Xo8nlRGMkTQn0HHAlMj+H35F7/wRnD/Qx8BCcctrhRtBB Phxrbwh+AVKe8DXQHyGTfINHwTr408B7wAWkGQz9CXhf472jsM2EfgXcAj5JeXYqWtsnZGbAfxk5 b0P/ETwC/op8X4OeAP4CpPzWKy9HY8vxYaU1aEnvU+gdIL0Tbgci31pi5cy3cm9f8C0450IPA1fB odesxgqORUI98imVtWMFXwUPgIfB95HwNSV/D6QX7Cwn/KFIGwSOlJ1ZOxbKiZCU42sLXg32BL8B 6RE7oqUM3BseiMwz4MfgFIH58EfB3wwHmQbNMQ/BXw7uB+8n/Sbou0gzEhr5/j44pDFVcNqCtL// UxAND48DaRlrB5YzH5azagvfgzOX9nmGiN8zsvdt2Inz5mOZHxdOgG0cMN49LChvKlcfUpQ03nho jWasYd3PxlYhbuMu4+ofWeXHcVXTbCTNAOaEZorC91lfvD+RJpV7iXX4Gg8ph/M6V8+A3q3YMFb8 Jui14LuKlPCvSNZ4pvq/j3N1MVcXc1VXw2OU8x7kfwl9O/gAOBu8H/wK/Bw5T0LfDX0vdH+Q2Kab ACeDKyRHd0J9mXgB2m7kdQlX1TPSCJtGVHRXtz34GOkvAnXXL8a9N8A5TdrTu4F2mALnerAW3Au/ rcbJoY9y70+1v2iBImhsEsMuv9Ee1+iNxnPWw8fLM+dCG1At9vOQPw0cBhJL8YbRzvlwJhB5nkA7 HIYzChxPGu3fn4H9wOHg1eBl4BBwCfgd7UZ93T7gSMqzjavPkNcz0NMVyeVa0jwB52aQ/vXod48e 984CmyITbfTQT/cA9JnQ2CHuFqWp0RbJ0V2h7Qyqlrald9pqL+B/qdfZH/4S7HC1VB8k/SLwDhC9 Mp2he4C9wTL1oJGA5ew9KfINHrrpJXz3YMPZlv8maZ5CjkZ0n4fzPBJehH5R2xZ6mKDR6PQyOAtB 9S8mIGcE9F3MG9gSHj64TyTKG4y0wbT2XO7dQyvNgf8sZRsBXslV7BxPreWLyV1rtAr6C9Ks5N6V 5Pg5HHwZ725o9RBXQm8C1fefS4+c5F49O8Feg3cnae6khAu1Vemd3vDxAV38CK+LcsBbwb7gy2hX AN24Rw+9XetLyWugF4ETwZ3gBpBIcoAFnoLVmsI4SiGeEDA3BhotJ4rot1FbS0obRjfcZ93bBOUs k7nX+kxizzhED+rEq5UaWd9TIiGzQLxvD3vPfYl775Z73ScbOjuyRyP8+fTLS3atlmhnHXzBx+Ss lLuwYTp6JbiPux4j/WQ5ZeTdIynNJ6Hm2EgtRI4z03IGS17mBXIktum+w72HFYXvzZFTVe7dbo4j +1Y1Mg9w+qK4ocry58opKXeIu4p5so55Ukr1iPVKJXpQx2r+e0svkFNP7gx2i+6TM1fuMw0vIH+n aGDoG5lv5RyUuUHQpjkmWhRaKrnAmdGwSWYzob3yRs5KR6LNs/HNJfcqOTNmemOxV4u1b65u6C4W F60x1ymWu2RP0J3b0FvyFTQlICdkzIPQgzkbM51dy3casi1+Kmgl2Lp7H3GuqS27bM8KbQzeypVI nvHdXGbI62SmEs/d/Q9y3yb3us+CT4L3gQ+Bc9lnnEHbHpYdNKshR+HsoaYDZaUm4n230xeO9Pt0 QavJFs3uhmHYitKz7Cy4s7/rI4guzYbzAne9QF1eQP4DcB5gz64n0n5L5OQ/xZt2X0NbXmtYAT0J 3O3IWazDos8NFq2XV0yaMZbeJRKCdpTnQymPu5Da3YufdQdtFUW7pggnuEJor4x8jzg3yfpCqz5O C38ux+esTyptPpMSPi4tbK5vmCK9zPi6hPL/llweB5+n93+r7UaLVeOzPN2oA6vpfYmqzUTyRdS0 Go/yCUo4TEpl0ogtaDxnjJyas9oid80ItXTknJXUqC8lH0L6iaKf1uOoJReR9ib68wQl2UH6dxrm UPdRaBelFZleBVp3hUi2mhagG6LPFXKv/7CUxM6im5Bcy1oguwzDvpPxOKxe+qU61Jrct1Me6d/V rDKfoFGlMhZsjhuknE6BxaXETCYyDz8tpxntGDzFkd1Yi95NDV3gtKQNC6i17NGEoF8F33IaHNlZ EGmktLZ3AXelW04ETBH0zqdPH5bcPR88QdlmNJwvY6ShDTPJ6dQuJrsM0HOQ9hj0XdAPQa8Blzrn OnI+4WorITXUzd71Zf13jnjZBbJCkX5uIz5sr3YLdaIutszmD84XoquN9UqHbznu8oaf2Hvjgrat pF5faY30KjjHudSmySGXOxUb2oMPiLZL2byJzlkWL6eOA0mzyfmrlRaWCIbVve4ylsklztVicnkm dKMjq5vkS+7uC40o997W8BaltfL9P0lNvVFafqmd96jkZX1zubeU6Nl90CHa6m5pH++UkLTYC3De YlZ8LHSB9FFDxGIhmCZo+yLX4qqGn9q7bqEHz6Sc+xu+xrrozvwTIve/UvcrZAVvbI1MoenZy0WL vMvrn3VkL6OAWf0a/D5JeYe0m+VIeV5nBP1BdSA0gPJLrW+nvgWyEvlny4jw2X8Mvy2c8FrhhLFt wtjkfidORHQS+8HHyg2zqgbE3s08bKR5XGXX1SdOFbDCphL5aYJ91YSr5lHSP4ptMxgOZ+rMVYrY 5+yNGux2H2vc/wQf6g3BFCJdYeIwKVgL7j7S3ImdsI672GH0P8YyYR8kjPUevAeeFH5AHVP0PN4v FeVqSgSrA28rJUS+tyITG8yfrUgaduTDd3FVo4LY2OYI9CPwB4AtsFfx2vx0RbxOPamotdZdY939 ofXMdMqvO6p69uBlUmKNB+fQhjvI8U1Kq1FffIQwe+thPTOzgJbBPwpfDK2+21KQcrpY4656i/hE 7gkkfwy+oTSzKF6Pi5/iqj94G1f1nGcqaW6EP1q8P1fPVOiOfw4p91OSntD4sEb9XDyO8AKtHRJ0 Z43oYpCjWoocjSqzd5aCFqWwWxToTopG8zgNFeipkr/t/AqHuwJ6M9AoMa2Uwh50Cvs7ge6PT6JU 79AmtJX3W/RnLPTr9M5V9OxzpEyiLaXw9WxDkv6aIJwwuz9hNNkMRgN1n/pJ7noJVJpSBbofpL4G drW/FjkapdwM523wFcaF7kh20bojH/86pSU5zgP1ZEU6V9njCDTiyonW8LXwNe6t52d+wV17yeU1 cBqIhe9ri2WB3Sgb+yM+/RXWM7fr4KuPT4/49bQV/lGgJ23w70wcD+VTfI0d6Dbn04zqSXdmmNNp +U/BnSDRCcOY9eEbPGvTAo7q52/g4FWF8bjDmWBAGTrgpeLbGmIpZpYiZcCbDp5FGn6xIZoRHCR3 xo63nFwOgcfhZFCXWiRzws2UIEF9/AbwfUX8o/fRorHUnTnKvZGWx/cxbzfiBIvcZfZShhTogcj5 BlQ9ZPSZWpHpn0qf/rrRI5MV7XT67ifI/wv4AWVzoY+B+5BPDMQjfmXw64NfQQ8He+jogH4XZH4O t4JmPrGWv7Qh59ZMEzhN6Ef2iZrorlZ70qjHx06rdxwJl2ncTCNs9Be7sa5GsUqYZ+aA+MJ+R+5i D9pjZyqgDWVrhZizg/0sJbyG9BvhfESpPmI2ZqcjqEMO+zhGz7zpmP0IZKzZMSs9O4N7Z+jIol7M ToGeSWPXzDj0rEM5NU6oe+uM07CudIy1sJ51eZWeOoDMrym/+sjaLzqWh1L+kWAUzAH1PBtetq+n 4LSm9FdYd6jZbQnOgB+Dzy5nmJ0yn1iEv1mRq0i2vRYQuXWI3IoEIg8+PpFhv8bcT8oq+D1BdMan /f2fKo1MIqhh1SV2OcO6u8QKGCY22IQ5uQltEkZ+mDhMmH2fsK41YTShC7rByuV3ck6RuQ6/YJ7Q qSly9tLaHqPE6hCOtS5qxR4gR3bGU9h1DXP2PoU9Hf9WXdl1TdfVXNdf5K8FN4PvgG8ieYtgcA6c HeDH4E5BuzqfIqszmASPCbrw3Vo4F0Pfi7Sx0KS3/il+BPgI+CD4uKB3D+jAOUGOa8A3wNfgTwM3 wvkS+mrwSfA2+OvJNxXOjcicDL4LZzT4KvgK/EtAA/6Ge3PAq8BTkLmfq0uoXU84r4MHkPOf8GmB 4CD8+0j/c7A3SDtYK0iQ1jDI8TZA69WXkFYAn1q4tIC1HE7BcpA0lMHQth4tab3yU7AEhNZSPUfJ NTrXDT3RsxAfy46hrzuDOjpe0bVV1034fbhX98qZAfxpujI2rn1ytZ5c5oDTwVWU81pKQpmt/kvK FiC1boKeNGkA/0qakeAIUMucBa09GIZGN4wP6img45yZPE5e/WVcBPqUzUOkSeUqa7evMU/VroUg 5fReBBeTy/vchc67z8BpxlVK6D4APg/nLOjPoVUb0St3Pjgb/rPQE8BFIKPV3QOSo7cbPEy+e6Ef A7Wvte7NuYpmmhe4qmNH7z0dRPO920Fa2zsNJHdvEumVnwlNLu44ZKpmMo481dWLQPrUi5HmBmj6 zlsHMveaKPvOVbTtW6TUc55HdB2EngX/PO5ijHvlIOM3QPP9lmCFYMqH4J+5OgA+dQ+vhm4D/Xvo VtAvNmrFeWK9EFFZIHQTzlQ0SRetSGHPJeU+iUGlcHLAosSRsBK9D+SuMB5TwCmIMGeuQqzpIfZQ QvrkAqeqQqyzYc7MhHnqKsyZDTNV5AecQgn0FKs+qYdOmk5SqvCp0HqOhRp5zGne29TCBUPg/Mba FWD5S2vcBN5M39HXLuPFvR8+s5P7S/ACkHZ2q8CvQJ2vHgYZU8YTDDHzhGj5EPOh7btTeLZRcBvI fOIxckPMNiFWgRDrgpsBMsZDOo6KwDFgBMwlDXoe3AFHUy6HXwl/KD17LlgHHz10VTOpu8dVdyX0 RPBb8qWVvJ9x9QwkdEQmM5uPTvpbdaUG9Ww/J0C8b5grKInHPObdhRxWQ19pdNJbqSVH89Vz55RU WGMOen6Pk8Y+56LD6o+zP2vUK9HT8tgAQTV8UgZ6FovZw2cNMjoSt1O7avishiHKEDByDT2SwgqY wvzQpB1XmaMClcaot96ZpGeUBcyZ1jcX1NPj7AS52Amunm3mjJCrT1ZyqsplFnX1uUg9G6an3PXZ Q42f4B27upeh1pSealPN54yTpyel9dle3YHS3WR9euUeolLEuOzMLPgUHAO9COzbGDETrOVqG2gi Wr7yh4EVYAIcCl4EjgVLwQtAYpge8UCvAPwI/DP4KUj0zD9Do44gpfU+1Ngj9BpwD1gCPgd2AzuB 4ynzreB54GH4jHe7dgjnBPRK6HPAe8HV8G8HiQHadV/wc/A3YA34JHg/2A58FAm50CvAl8Db4D8O fTNIqbx+oEYgiXN67TUOCdKq5gPaJFfjiqRZCr4HjgPnczUV7A7nOHf1Qk4DnFNBaup1Bl8hPXlZ S1Xwl/CvBj8Dj4JvgkRrvR2gxg8/4a4e0Nqef4HDvYaeNQPg/xF6N7gTvB4kimtU5izon4HEY+3I LWD1kaszwWtB2sT7PbgFfJ2U1NTO88LR3nwNpNd8Tlv5nL8K65Pg53OuVXd+eVbOxar3mVUCfIqw Pu9Qiu82n5OZ3+Lnqk+tsTU9Zc1p1dA+4p/s5aWwL2z06WBOuBk8FKNPuumT+B9QBj07zYlidy7n tLeIHOuzTxAfkBx57t569LeIfcjZVJ5r8Heo9SWcAA8x0CdEOMPgXgj/Bs6OhuA0B4mNhL5Dzh/B 5aSZCf0qdSEGGKojfUf4vTmhembjaW3xPT/jLCtPJAXbQOK3vp5jxJcPOAttniNeQdTUZCKH9vda sQ/yGDs7+FMucdrQ1/houpp70DwjYzQqq34l0WBXbQBiKQFRoICzfD7nHg3PzvvEEzxiiYE+a6On 4vHsjE9ElJXC5+ReWE8DYue4emZYvW+Nwo2grTSyNAt6EHUhUmTCcC4A34TfDOwAXgRq3UtIUyvP J7oTpa9DxE5DxDZDnK8I69lXzi56X3EXuXs9acMq2Vey80CqI8/NWfT1uctHkKz9fgt99DD0DO69 lHs5E25uhl+pZ+zhdCdNCjQjwsC380wxc6lFT8+yVqrO01+cNnd3gbSbGa4nmfHcWeM8HWtuY/xW 5E9E8u3cdTn03TyreCFpiuGPht8GPdTfHHiUe0/nWdcaUGO8+jTiX6gvTxx4aLhPVMRKEMnVglaL ZFywQxFgnZpCcskgF33CiziGN46RqKszzzWEiKyGthClYY120Q1Xnzf8FWW+Q7Tab00cgznBm8TM ELBrr2e9kGwySK/PbemzurWyR+8VIF+fbtC4nJ7t/6OU39fnC9RbrEBON8qpEYlC+A9Q35tIj96G eBrFe4oWU18VKysVPzTMiDCcOwok7urob5yExqaUOd7lN183zjnjyuuuuNqZNO6yieOdpaJtPx/S O8vp6DgNDc7pTlMncM5yspwWTlurIx2d7s6FjpwkdJxBTpUz2hnnXGc9A03bzAk7ZzvnWKqd097p 5PRwypxL5blq52LnMudK5xrneudmhx8VIX1zJ8Vp5bR2xDoocTo7PZ1+zjAn7rjOYGckv5Q60bnF OdPx+g0eXPa/2PsOOC2KbN9zqqqrurr7i8CQhigZJDNEyWGAIYoy5DDkzJBzEJUkoiKiIgIqsoqo CIisoiIiIiKiYkZFRVBklWUVUfGeqmmVmXWv7HXv2/feb6d/86+vuuvrrjp1Ynd9faBl104dSkLv bl3bl4Sl9gzGZ9WQCpdBAagK9aEptIR20B36AAfza54sGA5jYRLMsK01FIMydLZq0IAii/ZQAWba /QUgTqMuDmWhIFSHOtAQmkMryIBM6Et9rQhdydMdAeNgMswKr5oAH0pAOSgENaARtIDW0AF6QD9w oBJcCYNhJIyHKTAb5mTVnJDFfjDIhcXAYn6LqRbLZA0YNZFXsZhmsanFdha7WeybNWDCYD7M4hiL Ey1OtzjX4nVZWaPH8aUW11rcanGfxfcsfmVQiEFjxo4WKRZTLZa2WMFiVYu1LTYYkj0gSzS1mGEx 0+Igi+MszrS4cNTwoQPECourLd5rcdOoMZNGi60Wd1p8xuJeiwcsHrb41qixWaPEUYufWDxl8Qwd zBbnLF4w6AiLnsW4xRSLqWOpcEpbrGCxqsXaFhtYbGqx9djsQWOcDItdLWaOM/v7WhxkcYTFcRYn W5xpcf4EmhFnocVlFldYvMPiWosbJgwfM8TZZHGLxR0Wd1ncY3H/hNFZ45xDFt+x+InF0xbPGZRs woTqNWRgMb/FVItlLFaxWJuwpmxksbnFdIsdLXaz2JOwluxvcZjFcRanWpxrceGESeMmyOUWV1pc bXG9xY0WN08kCsitFndafMbiXosHLB62aNbgM5KPwv9EyUlzlIbL/kefzDvMfg9dkmaHtJmiT5ok 3v8/tE/Rvtx7EKKXiCaqjZO+Sf4LPzPSgmX/mxKh4CUjs99jYC24tSzm32DkkjHlkrHk32GBS8Zy l4D5fhc52bdU++79S/9UlD4Vt3Qy7+u/9BKh4u8iI4tT+Z8oEUpcAua/JKxP1nkBrIB7YSvsgdfh EziLpbEmNseuOBCzcT7ejOtxC+7Gw3gMzzDGkqw0q8mas65sIMtm89nNbD17kn3OC/EKvB5P55l8 GJ/KF/JVfCPfwffxt/gJfk64opCoIOqJdJEJNvoCN4fX+KncdQF56pXy1GteVKfGojqYH/Dk1CWA MzN3Xe28qD3V9VFbFySZKTSj5XL2xs7nlHERltGwLJT728nNuev50nP3pmCe3qYuy10v1jRPvVue +rDc5y82M099We7rFXsgz/fzULN4ap764jz1c7nrJdLz1Fflvl7ZChfVSW+U3Zu7Xi7I/f1yXXPX Ly+dp14mT71c7npVaeuMdG4yhwJV64XlM781j9UGheWYsJwalgt+q3X13WF5ICyPhOWx3KOuUTz3 LNQYlLuXNXfkqe/PXa+1Ok99TZ762jz1LRfxsKlvzVM/kqf9W7nraXm4MK1l7llKG5L7+IB789TX 56lvz1PPM94BO3Off1DJ3McHC/OOTKLkUDhB3vwpa2tM7hKweUYo1hSTrAVKgtSr1XJ9p1qmFqul tEfiZtxMpzLvvkXSQ1uA2TfgcvtmWWHfLOvknJ1X4ZfzqryazZzwkn0rITM9YN+aXrA9tLcq1VMo PsiG1bAXPoTzmJ964tK38+t7gek79X2Eq/UGwrtoDHHyakqSHjf5HxqpzcDxRerZw7Zcrh6h8mWq P2rL5epuYFRbS7hcrSO8mUZs+LYIlFYbgNOIlqn7bblcbaRyKdX/ZMvlF7V8IGz5YNhyU9jyobBl 2F91i73arfZqt9mr/XzkdnvkTnvkrouP6DV2jHfbMa61Y/z5yDp7ZL09co89wojnnsPniPbmzcJo 3yzM7JuFuX2/rbDvt3X07foOkokc38HIaG0z4xQ7MpqXJWDuNpl83SiqCNonh8vh9P2paiqI/7zT +D/vNP4H7zT+lZuKWG663OqVpbL1f3jmPzzzD3kG8S3LNTnxS1Wbn+MP84rlDN9yRmA5I2I5I2o5 I2Y5I245I2E5I2k5I5/ljPyWMwpYzkixnFHQckYhyxmFLWcUEfeL+4lXDH+kWv4oZvmjuOWPEpY/ Slr+KGX5o7Tlj8ssf5Sx/FHW8kc5yx/lLX9UsPxR0fJHJcsflS1/VLH8cbnlj6qWP6pZ/qhu+aOG 5Y+alj9qWf6obfmjjuWPNMsfdS1/1LP8Ud/yRwPLHw0tfzSy/HGF5Y/Glj+aWP5oavmjmeWP5pY/ Wlj+aGnntZWd19Z2XtvYeU2389rWzqvJsvIE2Qpzz3gBbXPgOtrmwkLa5sFiWEZHNsPDcL3NcLbI 2prFsI+2JTbD2VKb4ewGOAmfw40o0IGb8G68B27BjfggrLL5W1bb/C132fwta2z+lrtt/pa1Nn/L Opu/Zb3N33KPzd9yr83fcp/N37KBpbJGcD9rzJrAPtaMNYP9rAVrAS+xVqw1HGBtWVs4yDJYBrzC rmJXwSHWnXWHV9mNbDccZnvYHpTsTfYmKvYp+xRd9jX7GjU7y86ix75l36Jv85AFJj8MRkx+GIya /DAYM/lhMG7yw2DC5IfBpMkPg/lMfhjMb/LDYAF+UqRgCnlXE7GlmCZmYCsxV8zFdJM3BtuavDHY zuSNwfYmbwxmmLwx2MHkjcGOJm8MdjJ5Y7CzyRuDXUzeGOwq9ol9eKXYL/ZjN3FAHMCrxEFxEK8W h8Qh7G6yymCmySqDPUxWGexpsspgL5NVBnubrDLYx2SVwb4mqwz2M1llsL/JKoMDTFYZHGiyymCW ySqDg0xWGRxsssrgEAcdxKEOdzgOc6QjcbjjOi6OMNlmcKTJNoOjTLYZHG2yzeAYk20Gx5psMzjO ZJvB8SbbDGabbDM4wWSbwYkm2wxOMtlmcLLJNoNTTLYZnGqyzeA0k20Gp5tsMzjDZJvBmSbbDM4y 2WZwtsk2g3NMthmca7LN4DynoXMW5zvfON+wRs455zt2hfODc4E1kSiRNZdCCtZCejJgLU1GN9ZG 1pA1WbpsKBuydrKJbMLay9ayNcuQ7WUG6yA7yi6sk7xH3sOulBvk/aybfFW+yq6Wr8nXWHf5hnyD ZcoT8gTrIb+QX7Ceaowaw3qpcSqb9VaT1GTWz3hZbICaoWawgWqems+y1GNqNxusnlfPs0nqoDrI JqtX1atsinpNvcamqiPqCJumPnMHsOk6S69if9Ob9de8sv5ef8/HetrTfJyXz8vHx3tVvMt5trfQ W8Qneku8G/hkb4W3gk/zVnor+XTvLm8Nn+Gt9dbxWd693r18jvcn70E+13vIe4hf423xtvAF3jbv z/xa7ylvF1/qPePt4cu8495xfov3hfcFX+HX8uvwW/1mfjO+ym/jt+W3++39DL7a7+p35Wv8TD+T 3+338fvwtX4/vx9fF/w5eJavN9l++J9Mth/+gMn2wx802X74JpPthz9ksv3wzcHbwWf84UjDSEO+ y1gMs/4F0kOLUS30O9Lov+svexC203+ZPG2Mb3JvuIeBcMA8QHOYQ7GHQ3/AHOUoassgX472snpi jpX7tUYu4XUrl8zKJSfe+RqlmWF8ysww7jIzjE+bGcZnzAzjszR7z+JuMz/4qp2fDDM/bL4ZPdtr RsZeNiNj79FVr7LaEqy2RKstmdWW3GpL12pLz2pL32rLwGrLiNWWUast41ZbJq22zG+1ZWGr5YpZ LVfCarmSVsuVslruMqvlylgtV9ZquXJGv0F5o9+ggtFvUNHoN6hk9BtUNvoNqtg86ZcbvUQ26Yxz lmwSSRDZIZIgskMkQVDHSBDUMxIE9Y0EQQMjQXCFkSBobCQImhoJgmZGgqC5kSBoYSQIWhkJgrZG gsjvIBmBDCMj5HeQjJCvYSKRrkZG4EojI9BN7Va74WojI9DdyAhkGhmBHkZGoKeREehlJAJ6G4mA PkYioK+RCOhnJAIGGImALCMRMMRIBAw1EgHDjETACCMRMMpIBIw2EgHjjETAeCMRkG0kAqYZiYAZ RiJgrpEImGckAuYbiYBrjUTAdUYiYJGRCFhiJAKWGomAG4xE2HnOicR+9oaqm3hMvGDeCiteFC9S PPaSeAmYeFlQPCdeEa/YeOzfwau/yBMfZ3tag/pxo71HA1CRPH9NElaNeLIG1IMYNIDGUBCaQhtI Jd+A+A060maeE/amOL0vbbWhPwyGOjCUfMKGMBIm0Dcmkd/QBu6C+0iuN8Im6AWPwOPU7gl4CobB 0/A8jIYXYT9MhAO0TYaDtE2BV+F1mApH4H2YCR/QtgA+guNwLZygbQmcom0pnIZvyLs4hwxWYkms QN5CZawGD2ANrAEPYy1sAI9gI2wKO7A5toWnMAM7wvPYGTsDWVHsCy9if+wPb+BAHApHcDiOhPdw NE6CD3AKzoMTrB6rB39lDWk+zrIeLAu+YTPZAkS2iq0iD+Fh9jD6bCvbhgF7nD2OUfYE24kxtovt wgQ7wA5gkn3MyCtgJ9hJzM++YF9gCvuSncaC7Aw7g4U5csQivBAvhEV5MV4cU3lJXhKL89L8MizB y/PyWIo4wMHSQokINhExUQtbizqiIY4UV4gBmC2yxHC8TYwU2bjGyXJG4wZnrDMOH3WynQn4mDPZ mYzbnOnOdbjdWegsxOecpc5S3OMsc27G5521zmO439nmfIZHZUTmZwmZIguxwrKILMpSZTFZghWX pWRVVkpWl9VZNVlb1mbVZZpswGrIrrIrS5Pd5NWsrsyUWayBHCyHsNZymLyWrOr1cj0bIo/ID9l8 eUx+zG6Qn8rj7EZ5Up5kN8kv5XfsZvm9/J7dLX+SP7G1CpXD1qmCqhLboKqodLZTtVNZ7E21SC1i X6sn1E52Rh1VH7Cz6jP1PftG/eiW4L5bys3kVd2e7g18iHuj+xW/wz2jC/AfdEHdQ5TUvfRIkaVH 61liop6jbxTX6pv0KrFSv6hfFGv0If2quFu/pl8T6/Qb+k2xXr+t3xX36ff1MbFRf6I/EZu9wAvE w15+r4B4xCvoFRRbvMJeUfGYV8wrIbZ7pbxy4gmvgldBPO118bqIZ7xMr4d41uvl9RLPeX28fmKP N8DLEi94g70RYr83yhslDpF0FaCo6FEbFW2jeGgHeb2CoqKnKAYimaXo53nyej2KivZDQFHRQYhS VHSY7MEb5PUmKSp6h+yByXeTYvPdFLRxdGEbRxex99+K8tf4CYpj7hRfQC3xpdMAFlAkuAUOk7// OnxvfxPh0PlKs9q8tcgkSW4AzUmaTW7VgTACsmE6aaHFcDPcAevhAdgCO2E3SedheAeOkWU6A+fR LKgI/B3A/cf8rf4Tttzm77Tldv/Ptnzcf4rKrfRply23+k/bcpv/jC23+8/a8nH/OSq3Ubs9ttzq P2/Lbf5eW273X7Dl4/6LVG6ndvttudV/yZbb/AO23O6/bMvH/VeofJzaHbLlVv9VW27zD9tyu/+a LR/3nwRGR3cTbvP3EW73DxI+/gco8oYd+WP+kZAyb4aUeSukzNshZd4JKfNuSJH3Qoq8H1Lkg5Ai H4YU+SikyLGQIh+HFPk0pMjxkCKfhRQ5EVLkZEiRL0KKnAop8mVIkdMhRf4SUuR1Gv9j/lFLkU8s RT7/gxT5OqTImZAifw0pcjakyN9CinwbUuRcyCvfhZQ5H1Lm+5AyP4SU+TGkzIWQIj/lUCTAHIoE LIciAc+hSCByKBI4ORQJVA5FAjeHIoHOoUjg5VAk8EOKfGUp8o3hlAAMRQL5xygSRHIoEkRzKBLE cigSxHMoEiRyKBLky6FIkD+HIkGBHIoEKTkUCQrmUCQonEORoEgORYKiObwSpOZQJigWUqZ4SJkS IWVKhpQpFVLkspAiZUKKlA0pUi6kSPkcigSBoUiQtBQpZDglKP0HKVIxpEilkCKVQ4pUCSlyeUiR aiFFqocUqRFSpGZIkVohReqEFEkLKVI3pEi9kCL1Q4o0DCnSKKTIFSFFGoe80iSkTNOQMs1CyjQP KdMipEwFS5GqliK1LUUaGE4xT0JMv+2TkEyoiJ/h5/glnsfv8QL+xDiFK4p5LMKiLMGSrABLYYt5 PT6MD+cj+Eg+io/mY/hYPo6P59l8Ap/IJ/HJfAqfyqfx6XyGMzWYSudN4HGTNw5P4klAPIWnyKac Q5Ie/AF/pJCI/kAxwQS4TDIJmtEGHvNZAD6LsThEWD7zywW2iC2CBK/L60KSd+NDIZ8zxZkC5YMp wRTy7RgUAY/v5S/wffxFvp+/xA/wl/lB/ooZJfVvhh2laXMHv5Ov5nfxNfxuvpav4+v5PX/X5r8/ j/GeC13kPde0T5DAtthrcy+ZFqkXtah10TEGjNlFFdSTe+0TsHb2CWbtX5/y8A3ASUGsNiW/l8r7 bH2NKam+xjz5gii/P9x7f7gXgVG/X7SrPGJ8Fb+dL+FL+Q18Gb+RL+c38Zv5LXwFv5Wv5LeZqNTS GOyYGH+APwgBf5Q/Sr40I584lTfhzXgL3oqn83a8A+/E+/J+vD8fwAfyLD6ID+ZD+NDfmnczFt7Y ZIjiTXlTs/aYN6fzt+QtqZdteBsQvC1vCw7P4BkgeUfeERTNZx9wibPG0/hzrt6Yvt2cvtWGWmdQ q278Kn41784zeQ/ek/fivXmf3+JEe/Um5v331Hvz66cWvAVdvRVvRVdP5+l09Xa8HV29A+9AV+/E O9HV+xI3uZYOv169CV29BV09na7e4Tev/hv0MFEU9bsZXb0lXZFR39vRFTvSVST1dgZF1jnnpzam hTlujl6qTNnzN7aja27H1caOKMOOxcgEnd8pzpaS1lLookYPfQwwglGMYRwTmMR8mB8LYAoWxEJY GItgUUzFYlgcS1B8UgpL42VYBstiOSyPFbAiVqJ4pQpejlWxGlanqKUmxSy1sQ6mYV2sh/WxATak +OUKbIxNsCk2oyimBbbEVtga22A6tsV22J5img7YETtRVNMFu1JU0w2vwquxO2ZiD+yJvbA39sG+ 2I8inQEU52ThIByMQ3AoDqN4ZwSOxFEU8YzBsTgOx2M2TsCJOAknU/wzFafhdJyBM3EWzsY5OBfn 4Xy8BhfgQ/gVfo1n8W9sEBvMhrChbBgbzkawkWwUG83GsLFsHBvPstkENpFNYpPZFDaVTWPT2QyK nmax2WwOm8vmsfnsGraALWHn2HfsPPue/cB+ZBfYT2SwkTPOueAOl1xxl2vucZ8HPMKjPMbjPMGT PB/PzwvwFF6QoqfCvAgvylNNBMVLUARVysRPvAwvy8tRDFWBV+SVeGXRSrQWbUS6aCvaifYiQ3QQ HUUn0Vl0EV3FlaKbuEpcLbqLTNFD9BS9RG/RR/QV/UR/MUAMpChrkBgshoihYpgYLkZQvDVKjBZj xFgxTowX2WKymCk3y4flI/JRuUU+JrfKbXK7fFzukE/InfLP8kn5lNwln5bPyGflbvmc3COfl3vl C3KffFHuly/JA/JleVC+Ig/Rdpi212k7It+Ub8m35TvyXfmefF8elR/ID+VHJp6Sn5h4Sn5G20n5 OW2nKKY6Lf8iv5JfyzPyr/Ks/Jv8Rn4rz8nv5HmKtH6QP8oL8icFFGkxxZVQjpJKKVdp5SlfBSqi oiqm4iqhkhSHFVKFVRFVVKWqYqq4KqFKqlKqtLpMlVFlVTlVXlVQFVUlVZlitctVVVVNVVc1VE1V S9VWdVSaqqvqqfqqgWqoGqkrVGPVRDVVzVRz1UK1VK1Ua9VGpau2FOG1Vxmqg+qoOqnOqovqqq5U 3dRV6mrVXWWqHqqn6qV6qz6qrxqkBqshaqgapoarEWqkGqVGq3wqvyqgUlQ/1V8NUANVlnpLva3e Ue+q99T7JlZUH6qP1DH1sfpEfaqOu++677nvu0fdD9wP3Y/cY+7H7ifucfcz94R70v3c/cI95X7p nnb/4n7lnne/d39wf3QvuD9p0EjmkmuhHS210q7W2tO+juiojum4Tuikzqfz6wK6hC6pS+nS+jJd RpfV5XQlXVlfrqvqarq6rqFr6lq6tq6j03Q9fYVurJvoprqZbq5b6la6tW6j03Vb3U631xm6g+6o O+kuuqu+UnfTV+mrdXedqXt4aV5dr55X32vgNfQaeVd4jb0mXlOvmdfca+G19Fp5rb02XrrX1mvn tfcyvA5eR6+T15ni0q7elV437yrvaq+7iU+9nhSf9qbotK/Xz+tP8elAL8sbRBHqEG+oN8wb7o3w RlKkOtob4431xnnjvWxvgjfRm+RN9qZ4U71pwbfBueC74HzwffBD8GNwIfgpAhGM8IiIOJErTHSb cw8LN+EmmIOn8S8wF8/gX2G+vatl8scuhvvsva0N9t7WO/beliumiWmo7b0tz9w5xGflarkWn7d3 svabqB/fdh23BJ52K7qZTNv7WfWDt4OP2azg0+AzttDez1pCNvo6st1J8g7KQTr5ojPNGiL3U7sO gz7p4JeVIXFIgVRdnup3a/Jv1FpdkXCdrvJL27r0aQnFygGdrxAUhzK6vtmjybtTK3RDwpW6EeEq 3eKX73S2n8h/oPGmkjNSmpU2v9xhZcgrqcLIo2XVWDXyDWqxWnRmJJ9Z/nx2qEKeDiO7QV412RXf IkUJ5jOVppYIawnjX8BJ2gDX4TqT2Q/voxYP4IMgLuGsbcPztP0nzsqcYezRv7N8/w6792+yev8v WTv23f+uvZOvytfkG/KE/EL51u5tIYv3hLVEu5RL9sZYuefJwhnblmPZDl+iTTv5O7bs7y2ZIhv2 q/X62TL832bFfrVUg8j26outGfkOj1qvwXgMxl94Sj6pBuf4C2ooeQt75T4VGF9BReTLxIXDiPtG G4772eaxqbntnc7Sg/RgPUQP1cP0cD1Cj9ST9GQ9RU/V0/R0PUPP1LP09XqhXqQX6yV6qb5BL9M3 /qaV/PQP2MngEixleV1BV7T2sspvWsy6ZDPr6wa6oW6Uy3a2+IfWs/O/yH7mtp6d/xX2U25XQ37X hjaGa8C8Y2wp7KWIYx/shxZwAF6H1nAETkAn+AIdGGgt7Cx2BWsMs1lT1grmsjasM1zHurJusJxd zfrALawfGwB3siyWBWtsfH83e459C2tFQdES3hCTxCTkTl+nLwqnv9MfHWegMxClM8mZhMpE/+g6 Z5xvyC6fc85h1Dnv/Igx5yfJMJ8UUmFBqWV+LCpTZHEsL0vK6lhd1pQNsJmkDdvJlrI1tpfpsh12 JJs+ALvILDkcB8uRZNlHyXvkRlwvH5CbcKMao8bjg2qCmoQPqylqKm5R09U83KquUQvxSbVbPYe7 1fNqH+5R+9XruM88B8TX1F/JK3jdLUhewftuZzcTj7sD3Sn4F3eGu5I57h3un1kp92n3TdZCn/Hq sN7ebG82W+u39FuydcGJ4AxbH5wNvmEPRRpFGrFH7D0CRpFc1K52WwIvhHva5tqzDwaIeWK+uEYs ENeK68T1YqFYJBaLJWKpuEEsEzeK5eImcbO4RawQt4qV4jaxStwu7sBr8Tq8HhfiIlyMS3Ap3oDL 8EZcjjfhzXgLrsBbcSXehqvwdrwD78TVeBeu4Yv4Yj6Tz+Kz+Rw+l8/j8/k1fAG/9g/tu45fzxfa +xvC/rbiGlgNReyditoU4c6ANHunoq+9U9Gf2jWAIv+Tvpv7MfbcOfdqilx0r8Y8F2XkEY0yTzxZ bVaHvKT6jHwqYy/JMyJbCVKdUJ+Dq06pr8B3pasg7mqX/DA3za0LKW59txEUcpu4LSCVNNZRKEX6 6hMoYzQSVHQvaITKRotANdIiaVDD6A6oQ7qjBdT9u/7Usf2pxqaYe1PUnzTbn/rkqTUij1VQr2aD Q72aBy5Z8AWgbd8827eI7VvS9i2/G3Xj1KukmwJFbT9L2n6Wdtu4baGc297tRH0zva1qe1vD9jbN 9rYe6U4HGpHmDKCJ7Xkr2/M2pN3aQnvSbZ2hY/isNoP+P7Q9T7Nj+cb6e/DLHvOJ/FnyzpK/7GPk eVWBn393YvYxKERjrRvSXtixShrrHFB2Bnw71oh6Qj0BUYqnjkKMvPAzEFdn1fdEdYdGWcYt5Jag EVSkkTV2u7iZMJgsyGcwmmzFVzDdPU+jmU/6vwDcSlq/PtxF89AZdpBu7gEHyT6NhCNkk2bBUbJD N8Lx0GtuRH0aRNcuZXx/aG6iOehinmXDle67ehUcvOR25t4f/19q/etcDLQUzeGrzhfNRd1f5wK6 kU7/eR8jPV7pormoa9bjqx9cAeCWdCuAdnvQdcydMp7TE9uHUvbq1cNe/owdrY5KtfIcWF/9XvLV yWM39y/pCkWgJMVBVXAttViA5j7sYtMKluD9ZkUv/onwBvMNWGZ13ELy+n9dYdPX9q8e7Q/sGhaA z2lDYw2AyQFyAHC5Tq4Docar8eCoSWoSSe48NQ+Ud5d3F7jeWm8taG+btw087ynvKaDoAyqHa2MW 22s+RTZOWhsXJxt3CPLBMdoKETcch8LokKUrIiqLKlDUrk4pZlenlCRLdB5KOT86F6C09KUPZWRU RqGsLCqLQjlZQpaA8rK8rAAVZGVZGSqZ59dQ2a5UqWLXqFxu16hUtWtUqssr5VVQWw6Sw6Eu2aZs uELOl/OhFUWgq6G1XcHSxq5gSbfrVdrZ9SrtvaXeDZDh/cl7ADraNSSdvce9HdDFe9bbA1fa1SPd /Vp+Lcj02/htoIddMdLTrhLpbSnKWRPWml1l57kxWXFgrciKI+tG9tvcwN5IHPeD+lFdUD+54KLL XO4K4pBSbmn3MreMW9Yt55Z3KxC39HR7ub3dPm5ft5/b3x3gfu2ecf/qnnX/5n7jfuuec7/TKbqg LqQL6yK6qE7VxXRx3VP30r11H91X99P99QA9UI/So/UYPVaP0+N1tp6gJ+rZeo6eq+fp+foavUBf q6/Ty/VN+mZ9i16hb9Ur9W0kCYz0Idlh4l2yw8S7ZIdJH54g+S9Kvl8Bipm7kLRfTv7oSEgjH3QW 6bfrSdrTc6wrxf0zLefNxfnhnuli1kV7fp9O5jszxOyLvhOnyPoFMUctkiPUtEv6JQSdQzaWbS5a 574a2uOjuA2fwKdwN+7F/XgQD+MRfIdX42/yt/m7/H3+Af+If8w/5Z+J1WKNWCvWi3vFBrFRPCA2 iS3iiHhLvCPeE0fFh+JT8Zk4KU6Lr8QZcU6cFxcc34k4MSfh5HMKOAWdwk5Rp5hTwinlXOaUdco7 lZwqTlWnulPTqe2kOfWD/cGB4GBwKDgcvP6fddX/n6yrjoIg9cYd6bi/s4aR+FnsE/vFAXHQriD5 vZVkWP4r8areqDfrrXqnfkbv1Qf0Yf2W/lAf16f0GX1OX/CE53lxL8VL9Up7FbyqXm2KjJpSFJRB MU8mRTeDKJIZR1HLTG++t9Bb5q3w7iBtvsHbRLpuh7fL2+Pt9w55R7z3vGPeCe+0d9Y77wOp4sBP +oX84n4Zv5Jf3U/zG/nN/XS/o9/N7+n394f4o/xsf6o/21/gL/aX+yv91f56f6O/2d/q7/Sf8ff6 B/3X/Xf8D/3j/in/jH/OvxCIwAviQUqQGpQOKgRVg9pBg6Bp0DrICLoGmUHfYFAwIhgXTA5mBvOD hcGyYEVwR7A22BBsCrYEO4JdwR6SnkPBkeC94Bh5/afJ5z9P8ZaMBJFkpFCkeKRMpFKkeiSNooDm kfRIx0i3SM9I/8iQyKhIdmRqZHZkQWRxZHlkZWR1ZH3kgcgjke2RJyO7I/siByOvR96JfBg5HjkV ORM5F7kQFVEvGo+mRFOjpaMVolWjtaMNok2jraMZ0a7RzGjf6KDoiOi46OTozOj86MLosuiK6B3R tdEN0U3RLdEd0V3RPdH90UPRI9H3oseiJ6Kno2ej52MQk7EglowVihWPlYlVilWPpcUaxZrH0mMd Y91iPWP9Y0Nio2LZsamx2bEFscWx5bGVsdWx9bGNsc2xrbGdsWdie2MHYodjb8WOxj6JfR77KvZN 7Ic4i7vxaDx/vEi8ZLxcvEq8ZrxevHG8ZbxdvHP86njv+MD4sPiY+MT49Pjc+HXxpfGb46via+Ib 4pviW+I74rvie+MH4ofjb8WPxj+Jfx7/Kn4ufiEhEl4inkhJpCZKJyokqifSEo0SzRPpiY6Jbome if6JIYlRiezE1MTsxILE4sTyxMrE6sT6xMbE5sT2xJOJ3Yl9iYOJI4n3EscSJxKnE2cT55NkSJLR ZP5kkWTJZLlklWTNZL1k02TrZEayazIz2Tc5KDkiOS45OTkzOT+5MLksuSJ5R3JtckNyU3JLckdy V3Jv8kDyv9j7Eqiojq3dPt3NIJNIz/PcjajYgIpzFFGJ1wHFECSYq4AGCQoiiopBRAUnEBSZRETi NUaNIUoUx+AEiohDDEGiiEOMMcY5xin6qr4+3miuWfe9//3/ve+tdT1rfbXPrl27dtWpU2efxr3P GY8mjxaPax43Pe55PPJ4LuALnATuAqlALTAKvARWQTdBb0GAIEgQLAgVRAgiBTGCKYIkwWxBmiBD sEywQlAoKBWsF2wSVAh2CPYKDgrqBGcEzYLLghuCe4JHgudCvtBJ6C4UC5VCvdBT6C3sIuwp7Ccc JBwqHCUME74vjBbGChOEM4VpwgxhtjBPWCwsE24QbhFuE1YJ9wsPC+uEp4RNwlbhNeFN4T3hI+Fz EV/kJHIXiUVKkVHkJbKKuol6iwJFQ0TBolBRhChSFCOaIkoSzRali5aIVoiKRWWiDaItom2i3aJq UY2oXnRWdF50VXRDdEf0UPRMzBU7it3EYrFabBR7ia3ibuLe4gBxkHi4eLQ4XDxOPFEcJ04Uzxan i5eIV4iLxeXijeKt4krxbnG1uEZcLz4jbhK3iK+Kb4jviB+Kn0m4EkeJm0QokUu0ErPEW9JN0lsS KBkiCZaESiIkkZIYyRRJkmS2JF2yRJIjyZeUSMolGyVbJZWS3ZJqSY2kXnJW0ixplVyT3JQ8kDyR cqT2Uheph1QqVUuNUi+pr7SnNEA6RBosDZVGSCOlsdIE6QzpHOkC6TLpCmmhtFS6XrpJWiHdId0v rZHWS89Im6Qt0qvSG9I70ofSZzKuzFHmJhPK5DKtzCzrKPOVdZf1lQXKhspGyyJk0bI4WZJstixN liFbJlshK5SVytbLNskqZDtke2UHZUdlDbKzsmZZq+ya7KbsnuyJnCt3lLvLxXKlXC/3lHvLu8h7 yvvJB8mHykfJw+WR8hj5FHmSfLY8TZ4hXyZfIS+Ul8o3yLfIt8mr5PvlNfJ6+Rl5k7xFflV+Q35H /lD+TMFXuCiECqVCr/BUeCu6KHorAhRBiuGKUMX7imhFrCJBMUMxR5GuWKTIURQqShXrFZsUFYod ir2Kg4qjigbFWUWzolVxTXFTcU/xSPFcyVc6Kd2VYqVSqVd6Kr2VXZQ9lf2Ug5RDlaOUYcr3lROV U5QzlKnKDGW2Ml9Zqlyv3KSsUO5Q7lUeVB5VNijPKpuVrcprypvKe8pHyucqvspJ5a4Sq5QqvcpT 5a3qouqp6qcKUgWrwlTjVDGqBNVMVZoqQ7VMtUJVqCpVrVdtUlWodqj2qg6qjqoaVGdVzapW1TXV TdU91SPVczVf7aR2V4vVSrVe7an2VndR91T3Uw9SD1WPUoep31dHq2PVCeoZ6jnqdPUidbY6T12s LlNvVFeoq9TV6qPqU+omdav6mvqm+p76kfq5hq9x0rhrxBqlRq/x1Hhrumh6avppBmmGakZpwjTv a6I1cZokzRzNAs0yTZ6mRLNes0VTqdmrOag5qmnQnNU0a1o11zQ3Nfc0jzTPtXytk9ZdK9YqtXqt p9Zb20XbU9tPO0g7VDtKG6Z9XxutjdUmaGdo52jTtYu02do8bbG2TLtBu0W7TVul3a89rK3TntI2 as9rL2uva29pH2if6Dg6e52LzkMn1al1Rp2XzqrrpuutC9AF6YbrRuvCdeN0E3VxukTdTF2qboFu iS5Hl68r0ZXrNuq26ip1e3WHdfW6s7rzuqu6m7oHumd6vt5F76GX6tV6o95Lb9V30/fWB+iD9MP1 o/Xh+nH6GH2CfqY+Tb9In6Mv1JfpN+i36Lfpq/T79Yf1dfpT+kb9ef1l/XX9Lf0D/RMDx2BvcDF4 GKQGtcFo8DJYDd0MvQ0BhiBDsCHMMM4QY0gwzDSkGRYZsg15hmJDmWGDYYthm6HKsN9w2FBnOGVo NJw3XDZcN9wyPDA8M3KNjkY3o9AoN2qNZmNHo6+xu7GvMdA4xBhsDDVGGCONMcYpxiTjbGOaMcO4 zLjCWGgsNa43bjJWGHcY9xoPGo8aG4xnjc3GVuM1403jA+MzE9/kYhKalCajqaPJ19Td1NcUaBpi CjaFmiJMkaZYU6JptindtMS0wlRsKjdtNG01VZp2m6pNNaZ60xlTk6nVdN10x/TIzDE7mt3NUrPa bDR7ma3mbube5gBzkHm4OdT8vnmieYp5hjnVnGHONueZi81l5g3mLeZt5irzfvNhc535lLnRfN58 2XzdfMv8wPzEQl8qXSweFqlFbTFavCxWSzdLb0uAJcgy3DLaEm4ZZ5loibMkWmZaUi0LLEssOZZ8 S4ml3LLRstVSadltqbbUWOotZyxNlhbLVcsN6vUxXwC/BO4CHgTWAOuADcAzxBckCFlPoD2Lu4D7 gM2IHKe0I3Q7QsYRMo4svwZYB2wA0lZOkHECx4nlXCToDL4LtLlAmwvLOQisAdYBG4C0rStk3KCh LVq1Bd0OdDtY0g4a2oHvAf0eqPVAWw/UekC/B/R7QL8H00hwLCRFLO4DUj1icMTQIAZfDL4EtAS0 FH1JISmFpBR9SdGXFH1J0ZeUzDpF2qMcreRoJUcrOeSV4CvBV4KvBF8Fjgr9qjAn85kKYCWwCngA eAR4DHgCeJpcbYKQ/QS4kMUq4F7gOYKZ0JqJ2kzUZqI2E1ozoTUTWjMhvxgyi8FZbOPw6a9BS2B7 LbTVQlstJGthYy201UJbLW1r3xe1WZjRbIw1G3QO2ubAhhy0zQE/F5pzUZuLtrmozYXmXGjOhVW5 5D2Vy2mBZB6Le4FUzypwVkHDKvBXgZ8PLEAvBZApgEwBeilALwXopQC9FJA5pkj7KkKrIrQqQqsi yK8GfzX4q8FfDX4JOCXovYTOIWNPJQlWAquAB4BHgMeAJ4Dk2lKErBfQkcUq4F4g1doGtBN0O0HG CTJOLP8I8BjwBPAcfvmtAp4A2jhkbhhX8N2gzQ3a3FjOAeAR4DHgCSBt2xYy7tDQDq1wxzIC0AJY IoAGAfhC6BeiVoi2QtQKoV8I/ULoF9K5Z/4KSQmLe4EX8T8WKoFVwL1AypeBloGWoy85JOWQlKMv OfqSoy85+pLTq02Q9qhEKyVaKdFKCXk1+Grw1eCrwdeAo0G/GjonXCO9w7mdgX7cDIJ9gAHAQOBg G1INhF5EcBg4ITYEPwT8MHCigTHAWGCcDSGZCDrZhuCkgC6gGVe4K+j9x82jOxFBatUOYAE4Ragt h+RxnjfBGjoi7lE6XoJHXt7f3OPgnEBtI5XkcSD/lF17FS9XHU8D5FAOj0trec5UksPnXQd+CzwH /A54AXgRT7FdrNQl4BXg98AfUN+AekcWqS5H7NCO0OgIjY7Q6AiNjqxGF8i6gPZg8VvgOeB3wAtA 2s7D1o6PJynBLyjSFoQ+CJrqkLJI+W6QdIOkG8s5CJrKKFn8Fk8BavF8cObzGoFNQDwLeOeBLdjn q1ipVuBl4FXgNdSfQH0mi43Yyw+AbgI2A88DqcZMVmMtZJeCzmWxEdgEbAaeB9J2ubZ2/C70ihKs oEhbEPoAaKqjgEXK7w3J3pDszXIOgKYyq1lsxM6J/ZByCDYCm4DNwPPAFuyNVaxUK/Ay8CrwGuox H4wTi41YlQdANwGbgeeBVKMTq9ENsrhWjJDFRmATsBl4HkjbCdn5iMQoIzHKSIwyEqOMhA45i5Qf C8lYSMaynAOgqYyaxUbsLfQK8uEfuAA9gFKCPOqLED/EVn7Jli/5X+AesdXzmWb4K55AJ2hwo2g3 lXLswsFxYr0ueJv8cuAGeveAdgTtAtoFtAdoD9Ai0CLQUtBS0M7QTPrHfWSzhvhsrKdm49psU9r8 WP4egnbwhOywLuz4hwl6wzYHm+cKvgP4DnieO/CrcX/XYdS0hD9LuBQPkRFmwVNrw3qsdbCM0s7Q 5QxfzJl/AGM7RHS4YEbpLAEh5YYe2xKaR/zUOvDa2njoyR2y7tDrjtp2oNvZaEi2g6V0Br5kyxqU Nss9WMsFLNLWIhuiV4KwXQRdYtSIUUNoaKTlPluJXiWQkdhotJLAVil/N/AQsBpr5iC7huowGzLs TDK0lEMLVjBHAVrBerWUVsEnVKFWhT7mw+epBeYCC+hfHqh/RZ62trKSLV/yK7CHHSNPDFtJ9+JP 4IkthoYsupLslZRD/78HfMu9qLV5kvCa+euA9K+XmaAzQdeCrgWdCzoXdB7oPNAFoAtAL8GqnU9s oLudzWbih7Lep417Dmerbf44Vu0CzMACzMBnsCoDnAxwMrBSMzDXxN/GeGkJjxzXJJNeDfuu8DsX 0ZnlncL8LkYfS6BrCeZ9CVbqUly9WqzXWswonSW6crIgm4V+s7E+stmVk23job/laLEcM70cLXJA 59hoSObAXjr2SrY8grKCnROb/StYpK3zbIheCTK1mGGqaxVqVqGG+OSYR3LG0OdgPury0XM+pPNh YwHWaQFGWgBbClhbCrBWuJxC7JCFaFkELUWgi0EXsx46pUvgm5egtgR9LLH1BJkiePqrgfP5vxK8 QWefn8bgyQO/zg0oBMrxtzS5bXVQ75LODM5f8ivwFLLV29vWC/Hkj8HT3gtvma7iq5RjfwIcF9Zb xlsCXY8E6d/rnUA7gXYD7QZaCFoIWgJaAloOWg7aFZrt6WxT7xrWCG1rmZQ2rs02te39g65lxgFe PXZaBjstY4VtbWxvHOC3Ab8NfOw29NrQtwyM2sm2LojF1UBy9Rw48LCd2TeNY7CM0q7Q5Qof2pWP dwy6oumbBnS42xBS7uiR7qc8inRtMe1sPPTkAVkP6IVnR+aS0gIbDUkBLBXaVhHKIygr2JmphG0i aBKhtcSG6FXCHIMu7KXkXYPWSFEjta1oyoOEDHUyGw1pGWyU0xVN8BCwGmvFZovctqIZBbwUBVoq oQUeI6MCrWLfQs7hPYO+f2hQq0EfrraeIKPE24waaI8VXUsluZ3xTmB7L3n1XUHpsBSYB8wHFgKz gMXAEmApcDkwlyLdXQg2gLON/q8Uh21En63MY8t8tixkyyy2LGbLErYk2h2eUWsI5gHzgYXALGAx sARIrdHCei2s18J6LezWwm4t7NbCYi0s1kNeD3k95PUYrR6t9GilRys99OvRVs+2pSPUsyPUsyPU syPUsyPUsyPUsyPUsyPU20boCIsdYbEjLCZYCMwCFgNLgNQCIyw2wmIjLDbCYiMsNsJiIyw2svLL gbl4F60D0uvjBT1e0OMFPV7Q4AUNXtDghbZeaNsRtZ1ZLAaWAEuBy4G5WFN1QNqLH3rxQy9+6MUP 1vpBjx/0+EGPH/T4QY8f9Phhfv3Y+fVj59ePnV8/dn792Pn1Y+fXj51fP3Z+x2B+x2B+x2B+x2B+ x2B+x2B+x2B+x8CCPg5LgCuBq4AFwGXAIuBq4BpgNjAHuIIi3TsIngCHjqEPsirQciVbrmLLArZc xpZFbLmaLdewZTZb5rDlClJyuQGwNQC2BsDWAFgZACsDYGUA7AuAfYGQD4R8IOQDMbZAtApEq0C0 CsTYAtE2kG1LxuaYTTUQXAlcBSwALgMWAVcD1wCzgTlAOjuDYcNg2DAYNgyGDYNhw2DYMBg2DIYN g2m2VoJlwHXAbGAOEDox44Mx48Ogfxj0D4P+YdA8DJqHQfMwaBgGDSMgPwIyIaBD0DYEbUNgWwhb WwRcDVwDXAssA64DZgNzgNS2ENgWAtvCoD8M+sOgPwz6w6A/DPrDoD8M+sOgLQzawqAtDNc/jF1P Yex6CmPXUxi7nsLY9RTGrqcwdj2FsespjF1PYex6CmPXUzTsi4Z90bAvGvZFw75o2BcN+6JhXzTs i4Z90bAvGqONxmijoTuatTWatTWatTWatTWatTWatTWatTUatnId72LF3cWKu4sVdxcr7i5W3F2s uLtYcXdhUwzGEIMxxGAMMbA+BtbHwPoY2B0Du2MhHwv5WMjHYsyxaBWLVrFoFQv9sWgby7ZdAaT2 xrLjjGXHGcuOM5YdZyw7zlh2nLHsOGNt42wjpnYQXAlcBSwALgMWAVcDqR1xsDsOdsfB7jjYHQe7 42B3HOyOY+XXAstIn3HMEVgeh7HEYSxxNg6uXxyuXyJ6SEQPieghEboToTsRuhOhIREakiCfBJlk 0Mlom4y2ybAuma0tAq4GrgFmA3OA1JJkWJIMS1KgLQXaUqAtBdpSoC0F2lKgLQXaUqAtBdpSoC0F c53CXqMU9hqlsNcohb1GKew1SmGvUQp7jVLYaxSOaxSOaxSOaxSOaxSOaxSOaxSOaxQOO176QEvZ Mo8t89mykC2z2LKYLUvYshS9xtEnGME8YD6wEJgFLAaWAG0+is0vWcqWeWyZz5aFbJnFlsVsWcKW tl5T0Wsqek1Fr6noNRW9pqLXVPSayj65bU/rpWyZx5b5bFnIlllsWcyWJWxp6zUHveag1xz0moNe c9BrDnrNQa856HUVfqlebkP4snmUbnMW9CpgPvv7dh2Q0muAB4BbgOWoLWfpRoIbQG8CHsMv24ds CC/5KKWdpKDhr3Pr2F/FjwEpfRr4C7AV2IjaRpb+hmAz6Bbgc+h/ZENwfkMvEbZa4Av2t/RjQErj r0Y8L6AI6IxaZ5YmvfDaghbgDfc/Gdv+k7HtPxnb/qcytjlyGFsmGe4/y3HzMgONE7mru3PTXol0 opxe3Pm/xxoxlzm3uEqulqsnEl6E58eN5sZwY7lx3ETy7p7iUOVwgcaQv+lwuP/6QbS8fuj/8XCU vH7QmPQ3Hl5/ODrSiPXXDr9/PByDXz/IWP7kcLz++kHG/PoR+6ajjevrB5ml1480HL+fJ/7hSCJH 8p8cKW862oz8wxH1h2P6H47M1w/O/4sRVgynhaPg9OYEcILIU4B+g/D37w+mkv16CSeHk88p4ZST XX8rp5Kzm1PNqSE7/BlOE/V8kMXg/xT1/yX0+6/gn8RRqTkuvFP8NLvH9pH25Q6JDjMc0p1KndY5 7XDaz/nvjG2yxXO5kELNmDn0e7scppR+lRMxWVuYz+lXtOlfg5htzHZC0wyQPGYHsxNRHLsIvZvZ Q2iaDZLH7GeqCU1zQvKYQwz9fgrNDMljapmj+B5IHaGPM/WEplkiecxJ5hShaa5IHvM1c5Z+E534 PDzmW5qXH3kjecx3zHf0u/LMeUJfYC4QuoVpJfQl7kKyu9FMkjxuJjeT0DSfJI+7mEe/GUyzSvJ4 Vt4Z+n1l+osoecIV02+683/i8Pg3+TcJTfNM8ux6OSzmMDZ/3GG7C7ETOSd5Lt+49uHgWz6YIS5n G/tFGZr/ncvGsXzJ5sOsIjTNBW+LaWGQEZ6LyBYGeeG57BdRaHZ4LqJcGOSIt30dhUGmeC4iXhjk i+ci7oVB1nguol8Y5I7nsvNAs2jy8E0K2wzYxs4gQobhdaaeJ+JkGJoFntA0WoahueAJTWNmGJoR ntA0coaheeEJTeNnGJodntA0ioahOeIJTWNpGJopntA0ooah+eIJTeNqGJo1ntDX6QwjxoahmeI5 XETaMDRfPKFpvA1Ds8YTmkbdMDR3PKFp7A1DM8gTmkbgMDSPPKE38jcSpHE4DM0mT2gajcPQnPKE /oxfQfqikTkMzS9PONv5ZI3xT/PJVUOsDkNzyhM+jdhhaGZ5QtO4HYbmlyc0jd5haJZ5QtMYHobm mic0jeRhaMZ5Ql/iXyHaaFQPQ7PPEw6N7WFoDnpC0wgfhmaiJ/QNrCga7cPQrPSEQ2N+GJqbntA0 8oehGeoJfZ//kEjSKCCGZqsnHBoLxNCc9YR+yn9GamlcEEPz13O4iA5iaLZ6QtMYIYbmrCc0jRRi aOZ6QtN4IYbmryc0jRpiaBZ7QtPYIYbmsic0jSBiaEZ7QtM4IobmtSc0jSZiaHZ7QtOYIobmuKfZ wuzUhNbYaQhN44sYmu+e0DTKiKFZ7wlNY40Ymvue0DTiiKEZ8AntaedJ7ikafcTQbPiEQ2OQGJoT n9A0EomhmfEJTeORGJofn9A0KomhWfIJTWOTGJorn9A0QomhGfMJ7W/nTzTTaCWGZs8nnJ70/sUX Qxh8MYTBF0MYfDGEwRdDGHwxhMEXQxh8MYTBF0MYfDGEwRdDGHwxhHHYRncAxEExNC88h4toKIZm hyc0jYliaI54QtPIKIZmiic0jY9iaL54QtMoKYZmjefQVH4cRLyy30aURJNSCC5HEmFNl4TZt/HK CMr41ZVx4JalS94mrIFchvFxtraxt+vgxuPK7TjW8fZOHewZPpPuzyX3T4h1pLXjKxxluTpNSR6M 9BjBiSQvQfHksTiBvOBMIK9D5LDqXlHGF/4yurN94eeJPSekRwSnK0ril9WcdipL9/CxpvPHWdN5 Q8t4XIbLdfLe3O588IuINcerX7ZWEVMSfDpY29vz3uE7C/QD4hNmJU76ICZJ6xnVXuvTo4e/dtik qMT4afETk7QD4hMTvH3UVqVNWPR6TXzi+KRJ8VN8dFYNrecJpL/Xj4qPT9L2n54UE584KWmWVS1x tfpbu/uSf34+Vt9wiauPLzntSpjkX7h1FuaKKLEXcN8J8RFY29ETR4HTu+OnxUya8kES6cbd6kaZ DgKHUROiJ8dPiX5pmNOfGWaw6myGyV+tj56gDZn0wRSiVRs8oL81ndFbXf9+ARnGjsNLZ9pyCN+J m84wnJ2zPmocu31gj41dtvg0PzZ1fTu5+qmmtHbg1NunB10/u+zQh0NHRT4o4h4a1vR2XGdj3wlf NRh2OgftnDv9wsB9m5a7BR8xdbhX9oOrQXO6v/FJZNFJ2cC/rRyiKTqxvbP+0JBOc+LPidS9lvVw 73FhX/sHE3t1YnxfPLcEbfgyjsksebp7W9Tc9McRZfMWLMyuuFeV9/HJ7huCF0osmcMvWB9y+jyo edxn3v6Mn+N6fOLd5WGl9+dOH0XmzpxYUjjNNePze4fva3eN8MiKOt7xnO9A2a09Q/J7BYdIGyaO nLXps8yjoX3XpgcvmmL3RdcDKcZ9oyb2KRpe3yHVb8qCwfanS08NyeBOyeCsr868GMLlkYX/8bwn 1nm/WgVkOlUmvovVyd6RLF07OwfyWJ5XTrkMf16xdV5Bmvt7pxJuT0osNYxMFW4blv3i+LrEf/16 S2/LOcBZ2rv3onan+z6Munmxn7UttVHAMC/4dlbyBv3CqqIMN76YL6xXNczgJLz3+d3mw8OLRwZ6 fxwYdcfqTKvb8vnkNsp45dbh0RWRsnlr6hDzvYa9w5PKwyxJXtO3Z/y2eWjeTM6wH+t+kp6fdMSt fM597oCausz6RyH1B9fuC42/ExX4aSDnVv7R4m+UVc5rZa553zarP2v/0e2fN0zbsrylR3afwti9 3SefWfS54beLPzZOapO7aN/zS5w9Xe7/Ouexu4e33U/t81cGfOg5dWf35a0OrsfGxpzYl9b/w4kb 9+zck92l7h7Pfc7sX860BlxMeX7p0pbnDy9+47o9oXHFlRE7upfP6XS2z3ddnCP9uWvnxRoWP4yI Wl4RvqfHt+OWvbNA7vdLr8KydJfyvy7d3nHnur8d39ys3fGVVbZQK3T12jvqQf/W961XVnhOyjyQ cPn+J5sb0gISZ7iRPWY22WMi2T1mvL1lHvZCx1fvIzuyz/wb72q64XQnO42vr49vl65d6YZjtfrQ Uz96ap03/3/ENlcsHLJ0+cNGBI96Kc77E/F/uvfsS6xc/INy7cLapKpxEbxufUp+K5pd3H6QvuKT zJCfbw3qWfuenfO7G3fW2dV/PTR5cMLC7d8fv/jBDx//lmRZ+cHab5fwAq01vx7bfaynyjE0cITE 0fVxpSxmk1H51O7dhT8eGe6g8//kp4aOnXcEnNDZfdJ47WvPd2sVsxvad3M4UfpO/Z67+p82Gta7 tj/49NSh8L5RfWo7vu2cMmvhnUW3p+4bEH7l4+2u9995amq9rP36h+L38/7m18lz7ruKd2JdfANv T4yLv9O95Db3s+J1Fwod3N16SyddnjV8kLB117JT0yeXbOGUdAr4ZWRV+IOZA+f/6D2nw56xJ2Tj PT/LG+B0JDbgxZe+W9e317eIr3/N7j2PrPN+efPe8/tdbDg9zWvovqff655MVReJTkseH96wBJdP 1Zbe9eRGdkjDvqEy8KVWcdqbb/tAKqDh97H2svYo8y/rmuEXk5SU0LNz56jEOO/JL6+hd1T85M4J H06i3M4JifHR06OSpnUeEEIWnjdhWYNeWsgw/N7WntbuL8+t3IyOrMLk5OQ3KZyQ+IqmpD/cUNh9 BrQ/GbUv7sq0yYeKvp3ssqhXTdC02aaGjpf9U9Z0WbvP0LD/YlPErHYfCkZqmahdib86Xqn5aKSX 2PPs6R9We52Uup4RTM1tfzN03+PGI66dP5/QafKwge1DExeMeOtMrKp/5KezIrLv1CYvOc719F5T W9Lh+11ebS7cLLj8/eys990Xhay7MG5EcuHUcRvf65H79WYPjd2PhwZ++vXBkbs+rzr/zH4B50HS x9+9qFeVGewcrlq6HizIkW1KH2e5/nRBB/Vp/vHsk+mu324cNqDf9DMtF5JvL4n4sG1m9PLK3Tt3 b/5gtG7gpiExP4x+f6kw4oOZN3MieO65jmuM2oLrFzntEj59vC0xYefWywfXirlk91lDdp+Ftt3H Pda5aEQ1x7S53XcDNWGzPyj/4x707/F1ull7+HSz+li7dPGnW08Pcvpv8HVGT5o8YVrS+MkJ/7u+ znn/KU8/PxowZKr0aENQ35DqJ5uFuzv67vEYMero/J/7+p1722eF547c6FZN8ILdB/9yeq7do9vT 9y+t3fjN1kkJE2daJl7fsfP2wl0nbm36zWO98xh9+84n+50L5StmfDk5evKQ0d9duNvy1dr5tWkX 5w7l+uf9Ul3qGKqOGXziXPWMiM4f7TDxK0Pfi1VGvUib0/vWN3zTsB7JSQ5jD0Y0Zfh3nH7M7Ya6 R5s5M56viZsyu/Vm3+UFpVPd/uo1Qho5zrf0zPzhHfQRMQOXtnRe4B687fGX8qy4W6bVgkfH3b9d 6PYgfca0bjWrZpfXj7O/aVeR4bfzUd57C/ovCFuYN6VC0zGoPr5kQGvs9bnm7A9t+00640lmxPim Hcfx/w9vx92+DftmIWKoC8N5ZaOMvz78rYJdXTb/JWP53pIbW3r1H1Bzyir7ewMhl++iduKEcKaT t5ABnP6ve0L/4Ea9YYPKG9bO5+Cc4D3tsteNd2DcliUMzLo9bfS+t9rYdXpRNTJkofLnHrk7Pw51 blm2o5fi9NMtnxzb+cVInSLecVLqh7xy/aCf4yonz9FXDfp6wf2stvsdlnQ78FPqjwljB65dcaa+ 4UJ29aWvvE7MuXlsq+83mbuORx3udlqq+2pGS6/i7YpppbpFTZWVHqOXPSg5OGFIsae5ZNyStr1q BRNmBu05+dn8niMqIsNarD/+2EN1ZfG95h7zHgt0y6LTouz5+feKuQM6pwxatPsF99yEx0NamnlJ K7fbTXGpX3Pec/ycoLuSkna67lxl5hb7I/m+Vd/3qwnps+/TxS3XJ/pnPdDnl9RXJI8e2bMxMXCb 4SHZoDaRDWrF392jvE5wj9r8+9yjf9gI4B5Z/X27kq3J1wd7lJ/t1IeeWudt/1e4RxaryXaqnjJg UkLMhERtYMhA7cCQ4T39+3f37dSte/f+nXoM6uHrY7IabGNSvj6mTiF0UNqQCYkzJkVN+Kfb26p5 TtoA6cjZ51b9vPq385mnn7otF9zY5O/pMeP5sODNMwq8Vg5u/TR0Evf7vNRhC7+bO/X2dM53ewbE PY3fMvVOh9NzVjTkSdasO7L78a+pF8Zf6mRVl5g7zXjr2qD87K1Ni/2b6m/fP/neoWcxrfeil6++ fsjj8cf7FzxrXNpg12cfMyPYwnu0YKc4I2vc/rHtO/Y++bffCsO7qkaIq7s3qce/1afb9lChKHlV L/cnnIqVl8f6b7bsieoYJJz3zpW4G592WJW1yC31Y87fko0OhV4JvCovY05xy5Fy/V++GjrGPnl0 4oCKvtEXVi5wDNvx/MfMt9t02779kd+nqUPLZ831HdPerfTLX1p7l751c1CvV92p3zcEz1WLvuL2 +qk5b/dHg9o+Of4gdc2L0695Sm/cMf5vPKWkaQlR4/9bPKWXmpLevFm/5v/ZV79pt+Lc2vLs8plF E+vaXwnfdYKTniqJOGIc47Fn468ffpv5POv4lzM0Cv3DXy/VVe7qz8j9Pwvyz094Uu/3ieeyKucd SQLPndunX/Jqc3npiIuFbxXs7OIx74b7BdX53dEnhwf3GrrkN9kF09Zv8jNv/OXw93ce95eMZX56 d9FHM2Z/H/88U7tlZcmy4q/+Ki8TWY2t5anjc1Xt2x96O6fngPmLb7V8M//CiI5de/3Qvz+ziePi fK/xbUVDQFZKxf1OWWPbX9qfNTdXNKNy3FOhZVO8R1SAZ1jPJb2W9ru680j9ineVg0I/XH58xbBQ O07dI2u/gcMvyhbt+8X9zgX5RU915ch7ya3mK3vazPM4r+55aqBPOr+I7FiruAxjnZf5b3xle+1F 8vefusrmHaZPJ/ayteH5uLz6Oxrp9/czZx8366u1IrJr/L0h34cs9ZADnx/STJ7ieGZgbsJJ/tyH B0R1ddboV5q4+IRaR5d5pXlyhnEmcaI4iZx4/BQ3kZPE0XJGc2ZxEsjZB4Q/nlAxnFnrzGnGP12n SbMS4j9IHJ8QM6vzH/YlfjrDKY5tTMyY1KfjRybNkUfCNV2+WJl20vLeQmbuV+sfScdM77qpf+iZ moUfbS68c0RiWNAw+L1yj7odlzN3l86VTf601LV6+mKn8fNnfXGpQ1L1qtaBxo1Prx4+9+WzC5vy A37qMy3ZeMx5s3NQr9ZpfVdf35pW25QSlp3eyXH2qrHRS7srf+w5KHJjxXsf3baIJXppcvUXMSH3 16zMatYXtDz50eHwe+4dQ2NHJiu3XOr329eP4vs0Wi6nO8/rVr3Sw2uf6s6e3ivn+9+b187+2dSc EDfeJ3va/rJn4vVC4bv+dRm5d9y1YT/3ut/4TmXDukVRF6MTvbzDe02/4pKt++nXnbOHPDuxPSg9 7/6AHbPafbIunauxpnMVv18je590rgthOf7LF+MfH5CvPbYd2MVYNtYqfXUlOv/+sy9D+vx7jZ1P W/J4pU9Sqw95pvqS5+kfF+LMnDPfZYW4/q9x7948p007OL4r2WVfDFrpBEoiPZluVy4ck2XPeSLQ ZsfVxHxh/5Jnu34GGRYwdcq/n5B50kHkYMD3V5+917Nl7pA8H7zEya6csfWiYtACHt9vesaSO9YG T9ONcxKtDit8xlcgZicUfOCmT3PWdpMO2T9rHPR+9d62LlkbGB/scjC6WkxSiVGLzfveSclkrouP 9QX/RtxcU8Nxl69suQuzQGDAyqJdtk4bNbXn87ZlcWtxX+abt3D6UQfz71/r0vYV3Myb92nrovCr LidmZwQGLZRYNNEmTUn63J6Fcq4Zm/VWW784/+KbUue2JRo3ZMzSn8h9DQuP6frvkzujyUbl+u3f Xt4mco3sb7/V3MgsZK31KKzz+sB/IdGpQV41HQCTu5hiDQplbmRzdHJlYW0NCmVuZG9iag0KMTM1 IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSAxMzUvV1sgMSA0IDJdIC9Sb290IDEgMCBSL0luZm8g MjIgMCBSL0lEWzwwODkyN0E0MzBDOEYzNDQzODM2NzM0MUUyQjUyNUI3RT48MDg5MjdBNDMwQzhG MzQ0MzgzNjczNDFFMkI1MjVCN0U+XSAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMTE+Pg0K c3RyZWFtDQp4nDXSSTKDYRCH8fcTxJAgMkdiJohZkJjHSAyJORMh4hqqrG3tbKyUSziADeIAysYd 7MSXfuhF/6qruqt68VdKr1JJ07tFqTJX8CRon4I1J9iM8C3YHwTHneB0QBBeBJcTfgT3veC5FiIh IeoVYn4h9Sikk0ImrlSF/otPnUMeLuAM/lYK+kE28T9pUAEGqIQqqAYjtEIt1EA91IEZTNAIDWCB JrBCM9jBBk5wgBtc0AIe8IEXeqAd2uASOqEDuqELesEPfdAP4xCAARiCQRiBYRiDUZiAU1iGGQjC JEzBNIQgDEswC3MwDwuwCAmIwgqswhqsQwQ2IA4x2IQt2IYdOIEj2IU92IcDOIQsHEMSUpCGDOT0 fOZvJNeF1zLa24dQfC9jMAUEc0oI3cIzfAnholK/PEk5jw0KZW5kc3RyZWFtDQplbmRvYmoNCnhy ZWYNCjAgMTM2DQowMDAwMDAwMDIzIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAw MDEyNSAwMDAwMCBuDQowMDAwMDAwMTg4IDAwMDAwIG4NCjAwMDAwMDA0NzkgMDAwMDAgbg0KMDAw MDAwNDk1OCAwMDAwMCBuDQowMDAwMDA1MTI3IDAwMDAwIG4NCjAwMDAwMDUzNjcgMDAwMDAgbg0K MDAwMDAwNTU0MSAwMDAwMCBuDQowMDAwMDA1Nzg2IDAwMDAwIG4NCjAwMDAwMDU5MTAgMDAwMDAg bg0KMDAwMDAwNTk0MCAwMDAwMCBuDQowMDAwMDA2MDkzIDAwMDAwIG4NCjAwMDAwMDYxNjcgMDAw MDAgbg0KMDAwMDAwNjM5OCAwMDAwMCBuDQowMDAwMDA2NTU5IDAwMDAwIG4NCjAwMDAwMDY3ODQg MDAwMDAgbg0KMDAwMDAxNzk3NiAwMDAwMCBuDQowMDAwMDE4NDYwIDAwMDAwIG4NCjAwMDAwMTg3 MjcgMDAwMDAgbg0KMDAwMDAyMjY5NSAwMDAwMCBuDQowMDAwMDIyODcxIDAwMDAwIG4NCjAwMDAw MjMxMTggMDAwMDAgbg0KMDAwMDAwMDAyNCA2NTUzNSBmDQowMDAwMDAwMDI1IDY1NTM1IGYNCjAw MDAwMDAwMjYgNjU1MzUgZg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAwMDI4IDY1NTM1IGYN CjAwMDAwMDAwMjkgNjU1MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAwMDAwMDMxIDY1NTM1 IGYNCjAwMDAwMDAwMzIgNjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQowMDAwMDAwMDM0IDY1 NTM1IGYNCjAwMDAwMDAwMzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBmDQowMDAwMDAwMDM3 IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUzNSBmDQowMDAwMDAw MDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2NTUzNSBmDQowMDAw MDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0NSA2NTUzNSBmDQow MDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAwMDA0OCA2NTUzNSBm DQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAwMDA1MSA2NTUz NSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAwMDAwMDA1NCA2 NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAwMDAwMDA1 NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0KMDAwMDAw MDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUgZg0KMDAw MDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1MzUgZg0K MDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAwNjggNjU1MzUg Zg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAwNzEgNjU1 MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAwMDAwMDAwNzQg NjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYNCjAwMDAwMDAw NzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1IGYNCjAwMDAw MDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1NTM1IGYNCjAw MDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1IDY1NTM1IGYN CjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAwMDg4IDY1NTM1 IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAwMDAwMDkxIDY1 NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQowMDAwMDAwMDk0 IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBmDQowMDAwMDAw MDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUzNSBmDQowMDAw MDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUzNSBmDQow MDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2NTUzNSBm DQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEwOCA2NTUz NSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAwMDExMSA2 NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAwMDAwMDEx NCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0KMDAwMDAw MDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUgZg0KMDAw MDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1MzUgZg0K MDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAyNDk3MCAwMDAwMCBuDQowMDAwMDI1NTUwIDAwMDAwIG4NCjAwMDAxMTg3NDkgMDAw MDAgbg0KMDAwMDExODk5MyAwMDAwMCBuDQowMDAwMTk5NzIzIDAwMDAwIG4NCjAwMDAyMDAwMjQg MDAwMDAgbg0KMDAwMDIxMTA5MSAwMDAwMCBuDQowMDAwMjExMTQ0IDAwMDAwIG4NCjAwMDAyMTEx NzIgMDAwMDAgbg0KMDAwMDIxMTQwOCAwMDAwMCBuDQowMDAwMzA5Mjc5IDAwMDAwIG4NCnRyYWls ZXINCjw8L1NpemUgMTM2L1Jvb3QgMSAwIFIvSW5mbyAyMiAwIFIvSURbPDA4OTI3QTQzMEM4RjM0 NDM4MzY3MzQxRTJCNTI1QjdFPjwwODkyN0E0MzBDOEYzNDQzODM2NzM0MUUyQjUyNUI3RT5dID4+ DQpzdGFydHhyZWYNCjMwOTc5Mw0KJSVFT0YNCnhyZWYNCjAgMA0KdHJhaWxlcg0KPDwvU2l6ZSAx MzYvUm9vdCAxIDAgUi9JbmZvIDIyIDAgUi9JRFs8MDg5MjdBNDMwQzhGMzQ0MzgzNjczNDFFMkI1 MjVCN0U+PDA4OTI3QTQzMEM4RjM0NDM4MzY3MzQxRTJCNTI1QjdFPl0gL1ByZXYgMzA5NzkzL1hS ZWZTdG0gMzA5Mjc5Pj4NCnN0YXJ0eHJlZg0KMzEyNjczDQolJUVPRg== --Boundary_(ID_HfLKwcgNbqq2wZiLKCL3SA)-- From jmoisand@juniper.net Tue Feb 4 07:34:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3D1A011C for ; Tue, 4 Feb 2014 07:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSVyDGdYxWlx for ; Tue, 4 Feb 2014 07:34:09 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5127F1A012F for ; Tue, 4 Feb 2014 07:34:06 -0800 (PST) Received: from mail86-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE027.bigfish.com (10.3.207.149) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Feb 2014 15:34:05 +0000 Received: from mail86-am1 (localhost [127.0.0.1]) by mail86-am1-R.bigfish.com (Postfix) with ESMTP id 43DFC4402DB; Tue, 4 Feb 2014 15:34:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz9371Ic89bhc857hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h9a9j1155h) Received-SPF: pass (mail86-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(377454003)(189002)(199002)(31966008)(47976001)(50986001)(81542001)(81342001)(15202345003)(83322001)(19580395003)(74316001)(19300405004)(69226001)(74366001)(76796001)(74662001)(19580405001)(76786001)(76576001)(18717965001)(47736001)(74876001)(65816001)(85306002)(46102001)(54316002)(90146001)(94946001)(54356001)(56776001)(92566001)(53806001)(76482001)(81686001)(94316002)(87936001)(2656002)(56816005)(74502001)(80976001)(49866001)(47446002)(33646001)(4396001)(51856001)(85852003)(66066001)(83072002)(81816001)(77982001)(59766001)(2201001)(86362001)(74706001)(93136001)(80022001)(16236675002)(79102001)(15975445006)(19609705001)(63696002)(93516002)(87266001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB716; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:ECC7F215.9EC293C2.B9D1BD83.98E6CB80.204B0; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail86-am1 (localhost.localdomain [127.0.0.1]) by mail86-am1 (MessageSwitch) id 1391528042590052_7341; Tue, 4 Feb 2014 15:34:02 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.247]) by mail86-am1.bigfish.com (Postfix) with ESMTP id 8ABCB30024E; Tue, 4 Feb 2014 15:34:02 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Feb 2014 15:34:02 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 4 Feb 2014 15:33:56 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) with Microsoft SMTP Server (TLS) id 15.0.868.8; Tue, 4 Feb 2014 15:33:53 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0868.013; Tue, 4 Feb 2014 15:33:53 +0000 From: Jerome Moisand To: "Songhaibin (A)" , "mikebianc@aol.com" , "S.Majee@F5.com" , "ddolson@sandvine.com" , "sfc@ietf.org" Thread-Topic: [sfc] SFC using VLANs Thread-Index: AQHPHHg8Xodgkk+OUUueGo6j3mu4UZqbD+YAgAoxDEA= Date: Tue, 4 Feb 2014 15:33:52 +0000 Message-ID: References: <1636122887.9122.1390948057480.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 01128BA907 Content-Type: multipart/alternative; boundary="_000_eda3e86dfe534994925865faea79af37CO2PR05MB716namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:34:14 -0000 --_000_eda3e86dfe534994925865faea79af37CO2PR05MB716namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5kZWVkLCBxdWl0ZSBhIGZldyB1c2UgY2FzZXMgY2FuIGJlIGFkZHJlc3NlZCBieSBhIHNpbXBs ZSBjb21iaW5hdGlvbiBvZiBwb2xpY3ktcm91dGluZyBhbmQgdHVubmVscyAoTDIgb3IgTVBMUyBv ciBMMykgY29uc3RydWN0cyDigJMgd2hpY2ggaXNu4oCZdCBleGFjdGx5IG5ldyENCg0KTW9yZSBj b21wbGV4IHVzZSBjYXNlcyBjb3VsZCBiZSBhZGRyZXNzZWQgYnkgcHJvZ3JhbW1pbmcgb3IgY29u dHJvbGxpbmcgc29tZSBmb3JtIG9mIGZvcndhcmRpbmcgcnVsZXMgaW4gYW4gaHlwZXJ2aXNvciBv ciBhIHN3aXRjaCBvciB3aGF0ZXZlciBkZXZpY2Ugb24gdGhlIGRhdGEgcGF0aC4NCg0KTWF5YmUg dGhlIGJyb2FkZXIgcG9pbnQgd291bGQgYmUgdG8gZm9ybWFsbHkgaWRlbnRpZnkgJiBkb2N1bWVu dCB3aGF0IGNhbiBiZSBkb25lIHdpdGggcmVndWxhciByb3V0aW5nIG1lY2hhbmlzbXMsIGFuZCB0 byB3aGljaCBleHRlbnQgdGhpcyBjYW4gYWRkcmVzcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIHdo aWxlIHNlcGFyYXRpbmcgd2hhdCBpcyB0cnVseSBub3QgYWRkcmVzc2VkLg0KDQoNCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU29uZ2hhaWJpbiAo QSkNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgMTA6NDUgUE0NClRvOiBtaWtlYmlh bmNAYW9sLmNvbTsgUy5NYWplZUBGNS5jb207IGRkb2xzb25Ac2FuZHZpbmUuY29tOyBzZmNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgdXNpbmcgVkxBTnMNCg0KV291bGQgbGlrZSB0 byBoZWFyIG1vcmUgYWJvdXQgRGF2aWTigJlzIGltcGxlbWVudGF0aW9uIHRvby4NCg0KQmVzdCBS ZWdhcmRzIQ0KLUhhaWJpbg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOSwgMjAxNCA2OjI4IEFNDQpUbzogUy5NYWpl ZUBGNS5jb208bWFpbHRvOlMuTWFqZWVARjUuY29tPjsgZGRvbHNvbkBzYW5kdmluZS5jb208bWFp bHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIHVzaW5nIFZMQU5zDQoNClRoZXJlIGFyZSBhIG51 bWJlciBvZiB3YXlzIHRvIGRvIHRoaXMgd2l0aG91dCBTRkMuICBZb3UgY291bGQgY3JlYXRlIHlv dXIgY2hhaW4gdXNpbmcgRFNDUCBtYXJraW5ncyBhbmQgdXNlIE9GIGluIHRoZSB1bmRlcmxheSB0 byBmb3J3YXJkIHRyYWZmaWMgd2l0aCBtYXJraW5ncyBzZXQgKGRlZmF1bHRpbmcgdG8gc3RhbmRh cmQgSVAgbmV0d29ya2luZyBpZiBub3Qgc2V0KS4gIE1hbnkgcm91dGVyIHZlbmRvcnMgc3VwcG9y dCBhIGZvcm0gb2YgUG9saWN5IEJhc2VkIFJvdXRpbmcgKGFrYSBmaWx0ZXIgYmFzZWQgZm9yd2Fy ZGluZykgdGhhdCBjYW4gYmUgdXNlZCBjb2RlIGluIHRoZSBjaGFpbnMgcGVyIGZsb3cuICBZb3Ug Y291bGQgZXZlbiBydW4gYW4gb3ZlcmxheSBsaWtlIFZYTEFOIG9yIENvbnRyYWlsIG9yIE51YWdl IHRoYXQgc3VwcG9ydCBhIGNoYWluaW5nLWxpa2UgZmVhdHVyZS4gIEFuZCwgeWVzLCB5b3UgY291 bGQgYnVpbGQgYSBHUkUgZW5jYXBzdWxhdGlvbiBvdmVybGF5IGFzIHdlbGwuDQoNCk15IGhvcGUg aXMgZm9yIFNGQyB0byBwcm92aWRlIGEgc3RhbmRhcmQsIHNpbXBsaWZpZWQgbWV0aG9kIG9mIGRv aW5nIHRoaXMuDQoNCkknbSBkZWZpbml0ZWx5IGludGVyZXN0ZWQgdG8gaGVhciBtb3JlIGFib3V0 IERhdmlkJ3Mgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24sIHByb2JsZW1zIHdvcmtlZCBhcm91bmQs IGFuZCBmZWF0dXJlcyBzdGlsbCBub3QgcG9zc2libGUgdG8gaW1wbGVtZW50IHdpdGggdGhlIGN1 cnJlbnQgY29uZmlndXJhdGlvbi4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogUy5NYWplZUBGNS5jb208Uy5NYWplZUBGNS5jb208bWFpbHRvOlMuTWFqZWVARjUu Y29tJTNjUy5NYWplZUBGNS5jb20+Pg0KVG86IERhdmUgRG9sc29uPGRkb2xzb25Ac2FuZHZpbmUu Y29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0 DQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIHVzaW5nIFZMQU5zDQpZZXMgaXQgd291bGQgYmUgaW50 ZXJlc3RpbmcuIFRoZXJlIGFyZSBvdGhlciBzb2x1dGlvbiB3aGljaCBhbHNvIGJ1aWxkIGEgZHlu YW1pYyBjaGFpbiBiYXNlZCBvZiBzZXJ2aWNlIGNoYXJhY3RlcmlzdGljLiBWTEFOIHRhZyBpcyB0 aGUgbW9zdCBvYnZpb3VzIGNob2ljZSBidXQgaXMgaXQgbm90IHBvc3NpYmxlIHRvIHVzZSBvdGhl ciBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3kgbGlrZSBHUkUgcGVyaGFwcz8NCg0KRnJvbTogRGF2 ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNv bT4+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IGF0IDEwOjM1IEFNDQpUbzogInNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIFNGQyB1c2luZyBWTEFOcw0KDQpHcmVldGluZ3Ms DQpBdCBTYW5kdmluZSB3ZSBoYXZlIGJlZW4gZGVwbG95aW5nIGEgZm9ybSBvZiBTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluaW5nIChhbGJlaXQgdW5kZXIgZGlmZmVyZW50IG5vbWVuY2xhdHVyZSkgZm9y IGFib3V0IDUgeWVhcnMgbm93Lg0KT3VyIFBvbGljeSBUcmFmZmljIFN3aXRjaCAoUFRTKSBwbGF0 Zm9ybSBjYW4gaW5pdGlhdGUgYW5kIHRlcm1pbmF0ZSBjaGFpbnMsIHN0ZWVyaW5nIHRyYWZmaWMg dG8gZGlmZmVyZW50IGNoYWlucyBiYXNlZCBvbiBhIHZhcmlldHkgb2YgdHJhZmZpYyBhbmQgc3Vi c2NyaWJlciBjb25kaXRpb25zLg0KVGhlIGVuY2Fwc3VsYXRpb24gaXMgVkxBTiB0YWdnaW5nLCBh bmQgdGhlIHJlcXVpcmVtZW50IG9uIHRoZSBTRiBub2RlIGlzIHRvIHRyYW5zcGFyZW50bHkgYnJp ZGdlIGFuIEV0aGVybmV0IHRydW5rLCBmb3J3YXJkaW5nIG9yIGluamVjdGluZyB0cmFmZmljIHVz aW5nIHRoZSBzYW1lIEV0aGVybmV0IGFkZHJlc3NlcyBhbmQgVkxBTiB0YWcuDQpXZSBoYXZlIGFk ZHJlc3NlZCBpc3N1ZXMgb2YgY2hhaW4gc3ltbWV0cnksIGhlYWx0aCBjaGVja2luZywgZmFpbHVy ZSwgbG9hZCBiYWxhbmNpbmcgYW5kIHNlbmRpbmcgZGlmZmVyZW50IGNoYWlucyB0aHJvdWdoIHRo ZSBzYW1lIG5vZGUuDQpBIGJlbmVmaXQgb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGV4cGxpY2l0 IGNoYWluIGNvbmZpZ3VyYXRpb24gaXMgbm90IHJlcXVpcmVkIGluIHRoZSBTRiBub2RlIGl0c2Vs Zi4NCkFuIG9idmlvdXMgY29uIGlzIHRoZSBsaW1pdGVkIG51bWJlciBvZiBWTEFOIHRhZ3MgKG5v IG1vcmUgdGhhbiA0MDk1KSwgYW5kIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzd2l0Y2ggY29uZmln dXJhdGlvbiBtYXkgbG93ZXIgdGhhdCBmdXJ0aGVyLg0KSWYgdGhpcyBncm91cCBpcyBpbnRlcmVz dGVkLCBJIGNvdWxkIGVsYWJvcmF0ZSwgaW5jbHVkaW5nIHRoZSBkZXRhaWxzIGFuZCBwcm9zL2Nv bnMsIGVpdGhlciBvbiB0aGlzIG1haWxpbmcgbGlzdCBvciBpbiBhIGRyYWZ0LiBBbnkgaW50ZXJl c3Q/DQpEYXZpZCBEb2xzb24NClNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIElu Yy4NCg== --_000_eda3e86dfe534994925865faea79af37CO2PR05MB716namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9 kzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJueazqOah huaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrm ibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGlu IDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5kZWVkLCBxdWl0ZSBhIGZldyB1c2Ug Y2FzZXMgY2FuIGJlIGFkZHJlc3NlZCBieSBhIHNpbXBsZSBjb21iaW5hdGlvbiBvZiBwb2xpY3kt cm91dGluZyBhbmQgdHVubmVscyAoTDIgb3IgTVBMUyBvciBMMykgY29uc3RydWN0cyDigJMgd2hp Y2ggaXNu4oCZdCBleGFjdGx5IG5ldyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1vcmUgY29tcGxleCB1c2UgY2FzZXMg Y291bGQgYmUgYWRkcmVzc2VkIGJ5IHByb2dyYW1taW5nIG9yIGNvbnRyb2xsaW5nIHNvbWUgZm9y bSBvZiBmb3J3YXJkaW5nIHJ1bGVzIGluIGFuIGh5cGVydmlzb3Igb3IgYSBzd2l0Y2ggb3Igd2hh dGV2ZXIgZGV2aWNlIG9uIHRoZQ0KIGRhdGEgcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHRoZSBicm9h ZGVyIHBvaW50IHdvdWxkIGJlIHRvIGZvcm1hbGx5IGlkZW50aWZ5ICZhbXA7IGRvY3VtZW50IHdo YXQgY2FuIGJlIGRvbmUgd2l0aCByZWd1bGFyIHJvdXRpbmcgbWVjaGFuaXNtcywgYW5kIHRvIHdo aWNoIGV4dGVudCB0aGlzIGNhbiBhZGRyZXNzIHRoZQ0KIHByb2JsZW0gc3RhdGVtZW50LCB3aGls ZSBzZXBhcmF0aW5nIHdoYXQgaXMgdHJ1bHkgbm90IGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNvbmdoYWliaW4gKEEpPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjgsIDIwMTQgMTA6NDUgUE08YnI+DQo8 Yj5Ubzo8L2I+IG1pa2ViaWFuY0Bhb2wuY29tOyBTLk1hamVlQEY1LmNvbTsgZGRvbHNvbkBzYW5k dmluZS5jb207IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gU0ZD IHVzaW5nIFZMQU5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvdWxkIGxpa2Ug dG8gaGVhciBtb3JlIGFib3V0IERhdmlk4oCZcyBpbXBsZW1lbnRhdGlvbiB0b28uDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LUhhaWJpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgWzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Ij5taWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51 YXJ5IDI5LCAyMDE0IDY6MjggQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpTLk1h amVlQEY1LmNvbSI+Uy5NYWplZUBGNS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBz YW5kdmluZS5jb20iPg0KZGRvbHNvbkBzYW5kdmluZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb c2ZjXSBTRkMgdXNpbmcgVkxBTnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlcmUgYXJlIGEg bnVtYmVyIG9mIHdheXMgdG8gZG8gdGhpcyB3aXRob3V0IFNGQy4gJm5ic3A7WW91IGNvdWxkIGNy ZWF0ZSB5b3VyIGNoYWluIHVzaW5nIERTQ1AgbWFya2luZ3MgYW5kIHVzZSBPRiBpbiB0aGUgdW5k ZXJsYXkgdG8gZm9yd2FyZCB0cmFmZmljIHdpdGggbWFya2luZ3Mgc2V0IChkZWZhdWx0aW5nDQog dG8gc3RhbmRhcmQgSVAgbmV0d29ya2luZyBpZiBub3Qgc2V0KS4gJm5ic3A7TWFueSByb3V0ZXIg dmVuZG9ycyBzdXBwb3J0IGEgZm9ybSBvZiBQb2xpY3kgQmFzZWQgUm91dGluZyAoYWthIGZpbHRl ciBiYXNlZCBmb3J3YXJkaW5nKSB0aGF0IGNhbiBiZSB1c2VkIGNvZGUgaW4gdGhlIGNoYWlucyBw ZXIgZmxvdy4gJm5ic3A7WW91IGNvdWxkIGV2ZW4gcnVuIGFuIG92ZXJsYXkgbGlrZSBWWExBTiBv ciBDb250cmFpbCBvciBOdWFnZSB0aGF0IHN1cHBvcnQgYSBjaGFpbmluZy1saWtlDQogZmVhdHVy ZS4gJm5ic3A7QW5kLCB5ZXMsIHlvdSBjb3VsZCBidWlsZCBhIEdSRSBlbmNhcHN1bGF0aW9uIG92 ZXJsYXkgYXMgd2VsbC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXkgaG9wZSBpcyBmb3IgU0ZDIHRvIHByb3Zp ZGUgYSBzdGFuZGFyZCwgc2ltcGxpZmllZCBtZXRob2Qgb2YgZG9pbmcgdGhpcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J J20gZGVmaW5pdGVseSBpbnRlcmVzdGVkIHRvIGhlYXIgbW9yZSBhYm91dCBEYXZpZCdzIHNwZWNp ZmljIGltcGxlbWVudGF0aW9uLCBwcm9ibGVtcyB3b3JrZWQgYXJvdW5kLCBhbmQgZmVhdHVyZXMg c3RpbGwgbm90IHBvc3NpYmxlIHRvIGltcGxlbWVudCB3aXRoIHRoZSBjdXJyZW50IGNvbmZpZ3Vy YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRv bTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIi IHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPkZyb206 IDwvYj48YSBocmVmPSJtYWlsdG86Uy5NYWplZUBGNS5jb20lM2NTLk1hamVlQEY1LmNvbSI+Uy5N YWplZUBGNS5jb20mbHQ7Uy5NYWplZUBGNS5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+RGF2 ZSBEb2xzb24mbHQ7PGEgaHJlZj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29u QHNhbmR2aW5lLmNvbTwvYT4mZ3Q7LHNmY0BpZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5UdWVzZGF5 LCBKYW51YXJ5IDI4LCAyMDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTRkMgdXNp bmcgVkxBTnM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPlllcyBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZy4gVGhl cmUgYXJlIG90aGVyIHNvbHV0aW9uIHdoaWNoIGFsc28gYnVpbGQgYSBkeW5hbWljIGNoYWluIGJh c2VkIG9mIHNlcnZpY2UgY2hhcmFjdGVyaXN0aWMuIFZMQU4gdGFnIGlzIHRoZSBtb3N0IG9idmlv dXMgY2hvaWNlIGJ1dCBpcyBpdCBub3QgcG9zc2libGUgdG8gdXNlIG90aGVyIGVuY2Fwc3VsYXRp b24gdGVjaG5vbG9neQ0KIGxpa2UgR1JFIHBlcmhhcHM/IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGF2ZSBEb2xzb24gJmx0 OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmluZS5j b208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDI4LCAyMDE0IGF0 IDEwOjM1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2ZjXSBTRkMg dXNpbmcgVkxBTnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkdyZWV0aW5ncyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQg U2FuZHZpbmUgd2UgaGF2ZSBiZWVuIGRlcGxveWluZyBhIGZvcm0gb2YgU2VydmljZSBGdW5jdGlv biBDaGFpbmluZyAoYWxiZWl0IHVuZGVyIGRpZmZlcmVudCBub21lbmNsYXR1cmUpIGZvciBhYm91 dCA1IHllYXJzIG5vdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3Vy IFBvbGljeSBUcmFmZmljIFN3aXRjaCAoUFRTKSBwbGF0Zm9ybSBjYW4gaW5pdGlhdGUgYW5kIHRl cm1pbmF0ZSBjaGFpbnMsIHN0ZWVyaW5nIHRyYWZmaWMgdG8gZGlmZmVyZW50IGNoYWlucyBiYXNl ZCBvbiBhIHZhcmlldHkgb2YgdHJhZmZpYyBhbmQgc3Vic2NyaWJlciBjb25kaXRpb25zLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZW5jYXBzdWxhdGlvbiBpcyBW TEFOIHRhZ2dpbmcsIGFuZCB0aGUgcmVxdWlyZW1lbnQgb24gdGhlIFNGIG5vZGUgaXMgdG8gdHJh bnNwYXJlbnRseSBicmlkZ2UgYW4gRXRoZXJuZXQgdHJ1bmssIGZvcndhcmRpbmcgb3IgaW5qZWN0 aW5nIHRyYWZmaWMgdXNpbmcgdGhlIHNhbWUgRXRoZXJuZXQgYWRkcmVzc2VzDQogYW5kIFZMQU4g dGFnLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBoYXZlIGFkZHJl c3NlZCBpc3N1ZXMgb2YgY2hhaW4gc3ltbWV0cnksIGhlYWx0aCBjaGVja2luZywgZmFpbHVyZSwg bG9hZCBiYWxhbmNpbmcgYW5kIHNlbmRpbmcgZGlmZmVyZW50IGNoYWlucyB0aHJvdWdoIHRoZSBz YW1lIG5vZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgYmVuZWZp dCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgZXhwbGljaXQgY2hhaW4gY29uZmlndXJhdGlvbiBp cyBub3QgcmVxdWlyZWQgaW4gdGhlIFNGIG5vZGUgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BbiBvYnZpb3VzIGNvbiBpcyB0aGUgbGltaXRlZCBudW1iZXIg b2YgVkxBTiB0YWdzIChubyBtb3JlIHRoYW4gNDA5NSksIGFuZCB0aGUgY29tcGxleGl0eSBvZiB0 aGUgc3dpdGNoIGNvbmZpZ3VyYXRpb24gbWF5IGxvd2VyIHRoYXQgZnVydGhlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhpcyBncm91cCBpcyBpbnRlcmVzdGVk LCBJIGNvdWxkIGVsYWJvcmF0ZSwgaW5jbHVkaW5nIHRoZSBkZXRhaWxzIGFuZCBwcm9zL2NvbnMs IGVpdGhlciBvbiB0aGlzIG1haWxpbmcgbGlzdCBvciBpbiBhIGRyYWZ0LiBBbnkgaW50ZXJlc3Q/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRhdmlkIERvbHNvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZW5pb3IgU29mdHdhcmUgQXJjaGl0 ZWN0LCBTYW5kdmluZSBJbmMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_eda3e86dfe534994925865faea79af37CO2PR05MB716namprd05pro_-- From ddolson@sandvine.com Tue Feb 4 11:22:44 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B758B1A0187 for ; Tue, 4 Feb 2014 11:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 fL9OOmlHQski for ; Tue, 4 Feb 2014 11:22:34 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 976BA1A01E5 for ; Tue, 4 Feb 2014 11:22:34 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Tue, 4 Feb 2014 14:22:33 -0500 From: Dave Dolson To: Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQ Date: Tue, 4 Feb 2014 19:22:33 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> In-Reply-To: <52E91413.6040808@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:22:45 -0000 Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't=20 posted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From prvs=106d539d1=Nicolas.BOUTHORS@qosmos.com Wed Feb 5 07:18:22 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92A1A0205 for ; Wed, 5 Feb 2014 07:18:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Art2flY8Bg for ; Wed, 5 Feb 2014 07:18:19 -0800 (PST) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0E1A0189 for ; Wed, 5 Feb 2014 07:18:19 -0800 (PST) Received: from smtp-ex4.fr.colt.net (smtp-ex4.fr.colt.net [213.41.78.193]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s15FIIO6025828 for ; Wed, 5 Feb 2014 16:18:18 +0100 Received: from mx3.qosmos.net ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex4.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WB4Ez-0002CU-1V for ; Wed, 05 Feb 2014 16:18:17 +0100 X-IronPort-AV: E=Sophos;i="4.95,786,1384297200"; d="scan'208,217";a="833376" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 05 Feb 2014 16:18:14 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Wed, 5 Feb 2014 16:18:14 +0100 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGw== Date: Wed, 5 Feb 2014 15:18:12 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com> 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: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3DFA66LILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Subject: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:18:22 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3DFA66LILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_76B41B8FACE1514795D30EC137FF391D3DFA66LILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The model uses an IP address as a way to identify a Service Function= . I assume that this address is for management and control point of view.

Otherwise it raises a couple of questions

- A service function could be reachable via different IP addresses as = the traffic comes from different directions. 
Would this be  in line with the specification of the service-function-chain <= /span>container<= span style=3D"line-height: 16px; font-size: 10pt;"> ?

- Also  a service function = for example responsible to load balance traffic to other virtual service fu= nctions 
could be best attached to a set of IP addresses on a private subnet. &= nbsp;So these addresses might not be usable 
for say a management application to locate the service function.

So if those addresses are for management and control purposes, where s= hould the addresses used to route the traffic fit in the model? 
--_000_76B41B8FACE1514795D30EC137FF391D3DFA66LILASjungleqosmos_-- From Ron_Parker@affirmednetworks.com Wed Feb 5 07:23:36 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3981A01CB for ; Wed, 5 Feb 2014 07:23:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oqFN81D6k2w for ; Wed, 5 Feb 2014 07:23:33 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6871A01BF for ; Wed, 5 Feb 2014 07:23:33 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 07:23:06 -0800 From: Ron Parker To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGwAA+NqA Date: Wed, 5 Feb 2014 15:23:31 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F240MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:23:36 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F240MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nicolas, I think each service function will need one or more management IP addresses= . Whether or not a service function requires IP addresses for data plane = operations is dependent on the choice of transport encapsulation. If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required. However, if, for example, GRE tunnels are used for tran= sport, then the service function will require one or more iP addresses to t= erminate its GRE tunnels. In such a case, the IP addresses for GRE tunnel= termination will likely be different than the management IP address. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 05, 2014 10:18 AM To: sfc@ietf.org Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F240MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nicolas,

 <= /p>

I think each service func= tion will need one or more management IP addresses.   Whether or = not a service function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation.   If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required.   However, if, for example, GRE tunnels are use= d for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels.   In such= a case, the IP addresses for GRE tunnel termination will likely be differe= nt than the management IP address.

 <= /p>

   Ron

 <= /p>

 <= /p>

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: sfc@ietf.org
Subject: [sfc] Question on draft-penno-sfc-yang-00=

 

The model uses an IP address= as a way to identify a Service Function. I assume that this address is for= management and control point of view.

 

Otherwise it raises a couple= of questions

 

- A service function could b= e reachable via different IP addresses as the traffic comes from different = directions. 

Would this be  in line = with the specification of the service-function-chain container&nb= sp;?

 

- Also  a service = function for example responsible to load balance traffic to other virtual s= ervice functions 

could be best attached to a = set of IP addresses on a private subnet.  So these addresses might not= be usable 

for say a management applica= tion to locate the service function.

 

So if those addresses are fo= r management and control purposes, where should the addresses used to route= the traffic fit in the model? 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F240MBX021W3CA2exch_-- From prvs=106d539d1=Nicolas.BOUTHORS@qosmos.com Wed Feb 5 07:31:47 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAF1A01E2 for ; Wed, 5 Feb 2014 07:31:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH1IVpuxshEX for ; Wed, 5 Feb 2014 07:31:45 -0800 (PST) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8869A1A01BB for ; Wed, 5 Feb 2014 07:31:45 -0800 (PST) Received: from smtp-ex3.fr.colt.net (smtp-ex3.fr.colt.net [213.41.78.196]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s15FViv9031407 for ; Wed, 5 Feb 2014 16:31:44 +0100 Received: from smtp.qosmos.eu ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex3.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WB4Ry-0002gs-2S for ; Wed, 05 Feb 2014 16:31:43 +0100 X-IronPort-AV: E=Sophos;i="4.95,786,1384297200"; d="scan'208,217";a="833409" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 05 Feb 2014 16:31:43 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Wed, 5 Feb 2014 16:31:43 +0100 From: Nicolas BOUTHORS To: Ron Parker , "sfc@ietf.org" Thread-Topic: Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGwAA+NqAAAA3hxA= Date: Wed, 5 Feb 2014 15:31:41 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3DFA7A@LILAS.jungle.qosmos.com> References: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.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: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3DFA7ALILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:31:48 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3DFA7ALILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ron I agree with you that these addresses are then for management purposes, and= that there could be more than one. The question remains of how the information model identifies the overlay ad= dresses (IP address, Ethernet addresses) required at each step to locate th= e next hop. This has to be part of the configuration information, so I would think it should be part of the model described in this draft. Nicolas ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 05, 2014 4:23 PM To: Nicolas BOUTHORS; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Nicolas, I think each service function will need one or more management IP addresses= . Whether or not a service function requires IP addresses for data plane = operations is dependent on the choice of transport encapsulation. If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required. However, if, for example, GRE tunnels are used for tran= sport, then the service function will require one or more iP addresses to t= erminate its GRE tunnels. In such a case, the IP addresses for GRE tunnel= termination will likely be different than the management IP address. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 05, 2014 10:18 AM To: sfc@ietf.org Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_76B41B8FACE1514795D30EC137FF391D3DFA7ALILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ron

I agree with you that these addresses are then for management purposes= , and that there could be more than one.

The question remains of how the information model identifies the overl= ay addresses (IP address, Ethernet addresses) required at each step to loca= te the next hop. This has to be part of the configuration information, = ;
so I would think it should be part of the model described in this draf= t.

Nicolas


From: Ron Parker [Ron_Parker@affirmednetw= orks.com]
Sent: Wednesday, February 05, 2014 4:23 PM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

Nicolas,

 

I think each service fu= nction will need one or more management IP addresses.   Whether o= r not a service function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation.   If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required.   However, if, for example, GRE tunnels are use= d for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels.   In such= a case, the IP addresses for GRE tunnel termination will likely be differe= nt than the management IP address.

 

   Ron=

 

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: sfc@ietf.org
Subject: [sfc] Question on draft-penno-sfc-yang-00

 

The model uses an IP addre= ss as a way to identify a Service Function. I assume that this address is f= or management and control point of view.

 

Otherwise it raises a coup= le of questions

 

- A service function could= be reachable via different IP addresses as the traffic comes from differen= t directions. 

Would this be  in lin= e with the specification of the service-function-chain container&= nbsp;?

 

- Also  a servic= e function for example responsible to load balance traffic to other virtual= service functions 

could be best attached to = a set of IP addresses on a private subnet.  So these addresses might n= ot be usable 

for say a management appli= cation to locate the service function.

 

So if those addresses are = for management and control purposes, where should the addresses used to rou= te the traffic fit in the model? 

--_000_76B41B8FACE1514795D30EC137FF391D3DFA7ALILASjungleqosmos_-- From Ron_Parker@affirmednetworks.com Wed Feb 5 07:37:24 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE51A017B for ; Wed, 5 Feb 2014 07:37:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DWpwZc-gSev for ; Wed, 5 Feb 2014 07:37:21 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8E1A01F7 for ; Wed, 5 Feb 2014 07:37:21 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 07:36:54 -0800 From: Ron Parker To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGwAA+NqAAAA3hxAAAFIS0A== Date: Wed, 5 Feb 2014 15:37:20 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com>, <76B41B8FACE1514795D30EC137FF391D3DFA7A@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3DFA7A@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F2A0MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:37:24 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F2A0MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The original concept, as I understood it, was that for data plane operation= s, each service function would be identified with a name (i.e., a chain of = "sf-a", "sf-b", etc.). A separate "locator table" would map the service f= unction names to one or more transport-dependent addresses. In my previou= s example, that locator could provide a VLAN for simple L2 transport, or co= uld provide an IP address and GRE key for GRE transport, or any other trans= port we choose to support. Ron From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Wednesday, February 05, 2014 10:32 AM To: Ron Parker; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Hi Ron I agree with you that these addresses are then for management purposes, and= that there could be more than one. The question remains of how the information model identifies the overlay ad= dresses (IP address, Ethernet addresses) required at each step to locate th= e next hop. This has to be part of the configuration information, so I would think it should be part of the model described in this draft. Nicolas ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 05, 2014 4:23 PM To: Nicolas BOUTHORS; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Nicolas, I think each service function will need one or more management IP addresses= . Whether or not a service function requires IP addresses for data plane = operations is dependent on the choice of transport encapsulation. If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required. However, if, for example, GRE tunnels are used for tran= sport, then the service function will require one or more iP addresses to t= erminate its GRE tunnels. In such a case, the IP addresses for GRE tunnel= termination will likely be different than the management IP address. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 05, 2014 10:18 AM To: sfc@ietf.org Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F2A0MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The original concept, as = I understood it, was that for data plane operations, each service function = would be identified with a name (i.e., a chain of “sf-a”, “sf-b”, etc.).   A separate “locator tableR= 21; would map the service function names to one or more transport-dependent= addresses.   In my previous example, that locator could provide = a VLAN for simple L2 transport, or could provide an IP address and GRE key = for GRE transport, or any other transport we choose to support.

 <= /p>

   Ron

 <= /p>

 <= /p>

From: Nicola= s BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com]
Sent: Wednesday, February 05, 2014 10:32 AM
To: Ron Parker; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

 

Hi Ron

 

I agree with you that these = addresses are then for management purposes, and that there could be more th= an one.

 

The question remains of how = the information model identifies the overlay addresses (IP address, Etherne= t addresses) required at each step to locate the next hop. This has to be part of the configuration information, 

so I would think it should b= e part of the model described in this draft.

 

Nicolas

 

 

From: Ron Parker [Ron_Parker@affir= mednetworks.com]
Sent: Wednesday, February 05, 2014 4:23 PM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

Nicolas,

 

I think each service func= tion will need one or more management IP addresses.   Whether or = not a service function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation.   If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required.   However, if, for example, GRE tunnels are use= d for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels.   In such= a case, the IP addresses for GRE tunnel termination will likely be differe= nt than the management IP address.<= /o:p>

 

   Ron

 

 

From: sfc [mailto:sfc-b= ounces@ietf.org] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: sfc@ietf.org
Subject: [sfc] Question on draft-penno-sfc-yang-00

 =

The model uses an IP address= as a way to identify a Service Function. I assume that this address is for= management and control point of view.

 

Otherwise it raises a couple= of questions

 

- A service function could b= e reachable via different IP addresses as the traffic comes from different = directions. 

Would this be  in line = with the specification of the service-function-chain container&nb= sp;?

 

- Also  a service = function for example responsible to load balance traffic to other virtual s= ervice functions =

could be best attached to a = set of IP addresses on a private subnet.  So these addresses might not= be usable 

for say a management applica= tion to locate the service function.

 

So if those addresses are fo= r management and control purposes, where should the addresses used to route= the traffic fit in the model? 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A79F2A0MBX021W3CA2exch_-- From prvs=106d539d1=Nicolas.BOUTHORS@qosmos.com Wed Feb 5 07:49:46 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8FB1A019C for ; Wed, 5 Feb 2014 07:49:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmyXN9I7ddIt for ; Wed, 5 Feb 2014 07:49:45 -0800 (PST) Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF221A01C8 for ; Wed, 5 Feb 2014 07:49:42 -0800 (PST) Received: from smtp-ex1.fr.colt.net (smtp-ex1.fr.colt.net [213.41.78.194]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s15FnfWH028918 for ; Wed, 5 Feb 2014 16:49:41 +0100 Received: from smtp.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex1.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WB4jM-00062g-0P for ; Wed, 05 Feb 2014 16:49:41 +0100 X-IronPort-AV: E=Sophos;i="4.95,787,1384297200"; d="scan'208,217";a="833445" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 05 Feb 2014 16:49:39 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Wed, 5 Feb 2014 16:49:39 +0100 From: Nicolas BOUTHORS To: Ron Parker , "sfc@ietf.org" Thread-Topic: Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGwAA+NqAAAA3hxAAAFIS0AAAQTdR Date: Wed, 5 Feb 2014 15:49:37 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3DFA98@LILAS.jungle.qosmos.com> References: <76B41B8FACE1514795D30EC137FF391D3DFA66@LILAS.jungle.qosmos.com>, <76B41B8FACE1514795D30EC137FF391D3DFA7A@LILAS.jungle.qosmos.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: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3DFA98LILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:49:47 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3DFA98LILASjungleqosmos_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good point, service-functions have a mandatory name in the model. Looking at the model, a service-node holds a list of service-functions. The= service-node also has an ip-address field (for management?). So we need at some point a spec for this locator table which will be shared= somehow. Nicolas ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 05, 2014 4:37 PM To: Nicolas BOUTHORS; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 The original concept, as I understood it, was that for data plane operation= s, each service function would be identified with a name (i.e., a chain of = =93sf-a=94, =93sf-b=94, etc.). A separate =93locator table=94 would map t= he service function names to one or more transport-dependent addresses. I= n my previous example, that locator could provide a VLAN for simple L2 tran= sport, or could provide an IP address and GRE key for GRE transport, or any= other transport we choose to support. Ron From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Wednesday, February 05, 2014 10:32 AM To: Ron Parker; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Hi Ron I agree with you that these addresses are then for management purposes, and= that there could be more than one. The question remains of how the information model identifies the overlay ad= dresses (IP address, Ethernet addresses) required at each step to locate th= e next hop. This has to be part of the configuration information, so I would think it should be part of the model described in this draft. Nicolas ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 05, 2014 4:23 PM To: Nicolas BOUTHORS; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Nicolas, I think each service function will need one or more management IP addresses= . Whether or not a service function requires IP addresses for data plane = operations is dependent on the choice of transport encapsulation. If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required. However, if, for example, GRE tunnels are used for tran= sport, then the service function will require one or more iP addresses to t= erminate its GRE tunnels. In such a case, the IP addresses for GRE tunnel= termination will likely be different than the management IP address. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 05, 2014 10:18 AM To: sfc@ietf.org Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_76B41B8FACE1514795D30EC137FF391D3DFA98LILASjungleqosmos_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Good point, service-functions have a mandatory name in the model.

Looking at the model, a service-node holds a list of service-functions= . The service-node also has 
an ip-address field (for management?). 

So we need at some point a spec for this locator table which will be s= hared somehow.

Nicolas
From: Ron Parker [Ron_Parker@affirmednetw= orks.com]
Sent: Wednesday, February 05, 2014 4:37 PM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

The original concept, a= s I understood it, was that for data plane operations, each service functio= n would be identified with a name (i.e., a chain of =93sf-a=94, =93sf-b=94, etc.).   A separate =93locator table=94 would map th= e service function names to one or more transport-dependent addresses. = ;  In my previous example, that locator could provide a VLAN for simpl= e L2 transport, or could provide an IP address and GRE key for GRE transport, or any other transport we choose to support.

 

   Ron=

 

 

From: Nico= las BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com]
Sent: Wednesday, February 05, 2014 10:32 AM
To: Ron Parker; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

 

Hi Ron

 

I agree with you that thes= e addresses are then for management purposes, and that there could be more = than one.

 

The question remains of ho= w the information model identifies the overlay addresses (IP address, Ether= net addresses) required at each step to locate the next hop. This has to be part of the configuration information, 

so I would think it should= be part of the model described in this draft.

 

Nicolas

 

 

From: Ron Parker [Ron_Parker@a= ffirmednetworks.com]
Sent: Wednesday, February 05, 2014 4:23 PM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

Nicolas,

 

I think each service fu= nction will need one or more management IP addresses.   Whether o= r not a service function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation.   If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required.   However, if, for example, GRE tunnels are use= d for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels.   In such= a case, the IP addresses for GRE tunnel termination will likely be differe= nt than the management IP address.

 

   Ron=

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: sfc@ietf.org
Subject: [sfc] Question on draft-penno-sfc-yang-00

 

The model uses an IP addre= ss as a way to identify a Service Function. I assume that this address is f= or management and control point of view.

 

Otherwise it raises a coup= le of questions

 

- A service function could= be reachable via different IP addresses as the traffic comes from differen= t directions. 

Would this be  in lin= e with the specification of the service-function-chain container&= nbsp;?

 

- Also  a servic= e function for example responsible to load balance traffic to other virtual= service functions 

could be best attached to = a set of IP addresses on a private subnet.  So these addresses might n= ot be usable 

for say a management appli= cation to locate the service function.

 

So if those addresses are = for management and control purposes, where should the addresses used to rou= te the traffic fit in the model? 

--_000_76B41B8FACE1514795D30EC137FF391D3DFA98LILASjungleqosmos_-- From repenno@cisco.com Wed Feb 5 12:03:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4681A01C8 for ; Wed, 5 Feb 2014 12:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9wtj6pyBdVD for ; Wed, 5 Feb 2014 12:02:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC181A00E2 for ; Wed, 5 Feb 2014 12:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13695; q=dns/txt; s=iport; t=1391630579; x=1392840179; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=i3zsVSVBjcnelag/4QCviR08x5Gx5CJQto3uNIDbDUE=; b=IrfbV8cxjrm0zNrPYrbK+vABOZkfM9UcCmtjlcMaTBJOaggyf6gEQ36q LFPan2qVfljpo6Ne4lzsJkNDjQdWRTitq5EKiafkYPXDlxfOQErRYWF3S 6Mq+YzshKqjGofT3ut2I6x3dAnQFzqOfUD2EEnJliDFF/1RHJ6NMaGBi9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoGAE+Y8lKtJXG+/2dsb2JhbABPCoJIRDhXtXiIVIEQFnSCJQEBAQQORhEmAQgRAwEBASg5FAkIAQEEARKIBQ3PABeOGUsXAQKENgSYK4EykG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,788,1384300800"; d="scan'208,217";a="18249192" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 05 Feb 2014 20:02:58 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s15K2v3Q028658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 20:02:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 14:02:56 -0600 From: "Reinaldo Penno (repenno)" To: Nicolas BOUTHORS , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Question on draft-penno-sfc-yang-00 Thread-Index: Ac8igcbGKXLfHO8XQpiN9ZcY6YgpGwAA+NqAAAA3hxAABX2PgA== Date: Wed, 5 Feb 2014 20:02:56 +0000 Message-ID: In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3DFA7A@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.2.3.120616 x-originating-ip: [10.21.124.12] Content-Type: multipart/alternative; boundary="_000_CF17CF8889C8repennociscocom_" MIME-Version: 1.0 Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:03:03 -0000 --_000_CF17CF8889C8repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the question. There are a few things we are working on the next = revision and one of them is what you brought up. We left this out of the draft on purpose because we are discussing how to p= roperly reference the interfaces and IP management Yang models (http://tool= s.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16) (http://tools.ietf.org= /html/draft-ietf-netmod-ip-cfg-12) in SFC without creating strong coupling. We assume that each Service Function will have data plane interfaces and th= ose will follow the models above. The idea is to enhance the Service Funct= ion Path module and insert for each Service Function the next-hop identifie= r which would be based on the above models. If we identify we need to def= ine something else we will do it, but at this point this is not clear. Another change in the next revision would be addition of statistics and con= sequently a operational data tree. Thanks, Reinaldo From: Nicolas BOUTHORS > Date: Wednesday, February 5, 2014 at 7:31 AM To: Ron Parker >, "sfc@ietf.org" > Subject: Re: [sfc] Question on draft-penno-sfc-yang-00 Hi Ron I agree with you that these addresses are then for management purposes, and= that there could be more than one. The question remains of how the information model identifies the overlay ad= dresses (IP address, Ethernet addresses) required at each step to locate th= e next hop. This has to be part of the configuration information, so I would think it should be part of the model described in this draft. Nicolas ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 05, 2014 4:23 PM To: Nicolas BOUTHORS; sfc@ietf.org Subject: RE: Question on draft-penno-sfc-yang-00 Nicolas, I think each service function will need one or more management IP addresses= . Whether or not a service function requires IP addresses for data plane = operations is dependent on the choice of transport encapsulation. If, for= example, a simple VLAN is used for transport, then no additional IP addres= ses are required. However, if, for example, GRE tunnels are used for tran= sport, then the service function will require one or more iP addresses to t= erminate its GRE tunnels. In such a case, the IP addresses for GRE tunnel= termination will likely be different than the management IP address. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 05, 2014 10:18 AM To: sfc@ietf.org Subject: [sfc] Question on draft-penno-sfc-yang-00 The model uses an IP address as a way to identify a Service Function. I ass= ume that this address is for management and control point of view. Otherwise it raises a couple of questions - A service function could be reachable via different IP addresses as the t= raffic comes from different directions. Would this be in line with the specification of the service-function-chain= container ? - Also a service function for example responsible to load balance traffic = to other virtual service functions could be best attached to a set of IP addresses on a private subnet. So th= ese addresses might not be usable for say a management application to locate the service function. So if those addresses are for management and control purposes, where should= the addresses used to route the traffic fit in the model? --_000_CF17CF8889C8repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5F31C7341E74F14085B23A49DC6B40A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the question. There are a few things we are working on the = next revision and one of them is what you brought up.

We assume that each Service Function will have data plane interfaces a= nd those will follow the models above. The idea is to enhance  the Ser= vice Function Path module and insert for each Service Function the next-hop= identifier which would be  based on the above models.  If we identify we need to define something else we= will do it, but at this point this is not clear. 

Another change in the next revision would be addition of statistics an= d consequently a operational data tree. 

Thanks,

Reinaldo


From: Nicolas BOUTHORS <Nicolas.BOUTHORS@qosmos.com>=
Date: Wednesday, February 5, 2014 a= t 7:31 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Question on draf= t-penno-sfc-yang-00

Hi Ron

I agree with you that these addresses are then for management purposes= , and that there could be more than one.

The question remains of how the information model identifies the overl= ay addresses (IP address, Ethernet addresses) required at each step to loca= te the next hop. This has to be part of the configuration information, = ;
so I would think it should be part of the model described in this draf= t.

Nicolas


From: Ron Parker [Ron_Parker@affirmednetworks.com]
Sent: Wednesday, February 05, 2014 4:23 PM
To: Nicolas BOUTHORS; sfc@ietf.org
Subject: RE: Question on draft-penno-sfc-yang-00

Nicolas,

 

I think each service function will = need one or more management IP addresses.   Whether or not a serv= ice function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation. &nb= sp; If, for example, a simple VLAN is used for transport, then no additiona= l IP addresses are required.   However, if, for example, GRE tunn= els are used for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels. &= nbsp; In such a case, the IP addresses for GRE tunnel termination will like= ly be different than the management IP address.

 

   Ron

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: sfc@ietf.org
Subject: [sfc] Question on draft-penno-sfc-yang-00

 

The model uses an IP address as a way to identi= fy a Service Function. I assume that this address is for management and con= trol point of view.

 

Otherwise it raises a couple of questions

 

- A service function could be reachable via dif= ferent IP addresses as the traffic comes from different directions. 

Would this be  in line with the specificat= ion of the service-function-chain container ?

 

- Also  a service function for exampl= e responsible to load balance traffic to other virtual service functions&nb= sp;

could be best attached to a set of IP addresses= on a private subnet.  So these addresses might not be usable 

for say a management application to locate the = service function.

 

So if those addresses are for management and co= ntrol purposes, where should the addresses used to route the traffic fit in= the model? 

 --_000_CF17CF8889C8repennociscocom_-- From linda.dunbar@huawei.com Wed Feb 5 12:52:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539A91A020C for ; Wed, 5 Feb 2014 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 7ebiHkop9GH9 for ; Wed, 5 Feb 2014 12:52:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 623461A01FC for ; Wed, 5 Feb 2014 12:52:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDH22201; Wed, 05 Feb 2014 20:52:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 20:51:30 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 20:52:10 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 12:51:57 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnK82A Date: Wed, 5 Feb 2014 20:51:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> In-Reply-To: <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 05 Feb 2014 20:52:16 -0000 Paul, et al,=20 What is the difference between "network locators for SFs" and the "Service = Function Forwarder (SFF)"?=20 The first bullet of 3.2 stated that SF is not longer viewed as a bump in th= e wire. Then how do you describe the topology between SFs and their network= locators or Service Function Forwarders? Isn't it either "bump in a wire"= or "one armed"? Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Wednesday, January 29, 2014 8:58 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.tx= t Hi folks, The only change to this version is that we moved to two editors, and listed= the other co-authors in a contributors section. As always, your comments and feedback is appreciated! Paul >=20 > A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 > successfully submitted by Paul Quinn and posted to the IETF=20 > repository. >=20 > Name: draft-quinn-sfc-arch > Revision: 04 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-01-28 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 04.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 4 >=20 > Abstract: > This document describes an architecture used for the creation of > Service Function Chains (SFC). It includes architectural concepts, > principles, and components used in the construction of composite > services through deployment of SFCs in a network. This document does > not propose solutions, protocols, or extensions to existing > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From linda.dunbar@huawei.com Wed Feb 5 13:46:50 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2A1A021C for ; Wed, 5 Feb 2014 13:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 H8qsxfAyjpVY for ; Wed, 5 Feb 2014 13:46:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7A1A0100 for ; Wed, 5 Feb 2014 13:46:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAV20207; Wed, 05 Feb 2014 21:46:47 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 21:45:51 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Feb 2014 21:46:46 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Wed, 5 Feb 2014 13:46:36 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnO0lQ Date: Wed, 5 Feb 2014 21:46:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C78D55@dfweml701-chm.china.huawei.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> In-Reply-To: <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 05 Feb 2014 21:46:50 -0000 Paul, et al,=20 The "SFC Network Forwarder (SNF)" introduced is to "forward traffic based = on the information contained in the SFC encapsulation".=20 If SFC encapsulation is to carry Metadata/context data (Bullet 4 of Section= 1) to be shared, is it possible that the network forwarding nodes could fo= rward traffic based on policies that are not in the SFC encapsulation? Linda =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Wednesday, January 29, 2014 8:58 AM To: sfc@ietf.org Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.tx= t Hi folks, The only change to this version is that we moved to two editors, and listed= the other co-authors in a contributors section. As always, your comments and feedback is appreciated! Paul >=20 > A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 > successfully submitted by Paul Quinn and posted to the IETF=20 > repository. >=20 > Name: draft-quinn-sfc-arch > Revision: 04 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-01-28 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-= 04.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-0= 4 >=20 > Abstract: > This document describes an architecture used for the creation of > Service Function Chains (SFC). It includes architectural concepts, > principles, and components used in the construction of composite > services through deployment of SFCs in a network. This document does > not propose solutions, protocols, or extensions to existing > protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From walter.haeffner@vodafone.com Wed Feb 5 17:21:15 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C71A027E for ; Wed, 5 Feb 2014 17:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] 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 QTpOccLTnOAf for ; Wed, 5 Feb 2014 17:21:12 -0800 (PST) Received: from mailout10.vodafone.com (mailout10.vodafone.com [195.232.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1C44E1A016D for ; Wed, 5 Feb 2014 17:21:11 -0800 (PST) Received: from mailint10.vodafone.com (localhost [127.0.0.1]) by mailout10.vodafone.com (Postfix) with ESMTP id 03B43301EFD for ; Thu, 6 Feb 2014 02:21:10 +0100 (CET) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id E9216301BD7; Thu, 6 Feb 2014 02:21:09 +0100 (CET) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.224]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0146.002; Thu, 6 Feb 2014 02:21:09 +0100 From: "Haeffner, Walter, Vodafone DE" To: Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDOiUWgb3nPGUW9HHOvqa65GpqlciKAgAID1jA= Date: Thu, 6 Feb 2014 01:21:08 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:21:15 -0000 Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 Chuong.D.Pham@team.telstra.com Wed Feb 5 18:24:09 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA30A1A0228 for ; Wed, 5 Feb 2014 18:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQbGmh0nhUP4 for ; Wed, 5 Feb 2014 18:24:07 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 182F11A01E0 for ; Wed, 5 Feb 2014 18:24:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,790,1384261200"; d="scan'208";a="183756463" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 06 Feb 2014 13:24:06 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7340"; a="146881638" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Feb 2014 13:24:05 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 6 Feb 2014 13:24:05 +1100 From: "Pham, Chuong D" To: "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Date: Thu, 6 Feb 2014 13:24:04 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: Ac8i2cA9zf49KEERQjGsDHX7J+RRYAABTydw Message-ID: <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 02:24:10 -0000 Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From paulq@cisco.com Thu Feb 6 06:58:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCB71A017A for ; Thu, 6 Feb 2014 06:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usKgKWNpPrFy for ; Thu, 6 Feb 2014 06:58:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A6E541A012E for ; Thu, 6 Feb 2014 06:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2919; q=dns/txt; s=iport; t=1391698733; x=1392908333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8lvz1qkZaeLDoe6tDNAEFQkYWsawyLKp2RZn7RwQ9+k=; b=R1vYY6gAiILnZ4Ac/UCcY7oj4H06aUnC3MXYfUnmWq8OTZIg60zTXByA CR1MvRSJ84TLWxkXAel6H+oWSYLYyP7lT6EUXX0aS6OB+hTcXdijR0OVA jSV1Ekvvgn8S5PR7hmfJ/dhkdE/BvO0n8Jy+vDXZNe0+Ax+sFlcMmAOQX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukFACGi81KtJXG//2dsb2JhbABZgww4UQa+cYEKFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEBAwEBHwkHJwsUAwYIAgQOBQkSh2IICAXOJBeORzMHBoMegRQEmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="302320363" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2014 14:58:52 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s16Ewqi9004811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 14:58:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 08:58:52 -0600 From: "Paul Quinn (paulq)" To: Linda Dunbar Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnK82AgAGWpYA= Date: Thu, 6 Feb 2014 14:58:51 +0000 Message-ID: <80DBC0E1-FBF6-432F-9D12-989D9B798705@cisco.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.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="us-ascii" Content-ID: <4B49056B7D62ED428BFB73FC59EE44F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 06 Feb 2014 14:58:55 -0000 Linda, On Feb 5, 2014, at 3:51 PM, Linda Dunbar wrote: > Paul, et al,=20 >=20 > What is the difference between "network locators for SFs" and the "Servic= e Function Forwarder (SFF)"?=20 >=20 The SFF is a logical entity that performs actually forwarding of packets to= service functions. The term network locator is used in the traditional se= nse, that is a data plane address (i.e. where it is connected to the networ= k). > The first bullet of 3.2 stated that SF is not longer viewed as a bump in = the wire. Then how do you describe the topology between SFs and their netwo= rk locators or Service Function Forwarders? Isn't it either "bump in a wir= e" or "one armed"? It's not a matter of topology, rather, instead of the SF being "inserted" a= s a bump, it is "consumed", regardless of placement in the network. The te= rm Overlay Service Topology is used in the doc to describes the service cha= ining topology. >=20 > Linda >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) > Sent: Wednesday, January 29, 2014 8:58 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.= txt >=20 > Hi folks, >=20 > The only change to this version is that we moved to two editors, and list= ed the other co-authors in a contributors section. >=20 > As always, your comments and feedback is appreciated! > Paul >=20 >=20 >>=20 >> A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 >> successfully submitted by Paul Quinn and posted to the IETF=20 >> repository. >>=20 >> Name: draft-quinn-sfc-arch >> Revision: 04 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-01-28 >> Group: Individual Submission >> Pages: 21 >> URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -04.txt >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 04 >>=20 >> Abstract: >> This document describes an architecture used for the creation of >> Service Function Chains (SFC). It includes architectural concepts, >> principles, and components used in the construction of composite >> services through deployment of SFCs in a network. This document does >> not propose solutions, protocols, or extensions to existing >> protocols. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From paulq@cisco.com Thu Feb 6 07:02:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A51A0116 for ; Thu, 6 Feb 2014 07:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exsPdzAHZBA3 for ; Thu, 6 Feb 2014 07:02:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18E1A012E for ; Thu, 6 Feb 2014 07:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2586; q=dns/txt; s=iport; t=1391698940; x=1392908540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=n9SpwuKSzTW2H01JpPnTQEqb+sQ+mqBeeM5EvSZlNjg=; b=cgTGp178vTG6CaIWwDQFZemL5+xdO5vm0UMzcv1woXfPxhVqF+I2/4QA dv/43wgqooyOum9Z9kAewkD/LGITI0HRnUUh6/0Fn+Yw1DCP3TkHFEK5d lcKMTZLVbChYra/h3zlDmXYZCnrntFnUbV2s4tRc+Go/cEinVjBkC3+3m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukFAPei81KtJV2b/2dsb2JhbABZgww4UQa+cYEKFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEBAwEBHwkHJwsUAwYIAgQOBQkSh2IICAXOIxeORzMHBoMegRQEmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="18459383" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2014 15:02:20 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s16F2Kxa004869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:02:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:02:20 -0600 From: "Paul Quinn (paulq)" To: Linda Dunbar Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnO0lQgAGIIYA= Date: Thu, 6 Feb 2014 15:02:19 +0000 Message-ID: <60F86310-A1E6-47B1-8118-99D9B426995A@cisco.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78D55@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C78D55@dfweml701-chm.china.huawei.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="us-ascii" Content-ID: <64756F743087344BB30BED050A929283@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 06 Feb 2014 15:02:23 -0000 Hi Linda, On Feb 5, 2014, at 4:46 PM, Linda Dunbar wrote: > Paul, et al,=20 >=20 > The "SFC Network Forwarder (SNF)" introduced is to "forward traffic base= d on the information contained in the SFC encapsulation".=20 >=20 > If SFC encapsulation is to carry Metadata/context data (Bullet 4 of Secti= on 1) to be shared, is it possible that the network forwarding nodes could = forward traffic based on policies that are not in the SFC encapsulation? >=20 I'm not sure exactly what you mean, can you give me a bit more context (no = pun intended!), or even better, an example? Thanks Paul > Linda =20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) > Sent: Wednesday, January 29, 2014 8:58 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.= txt >=20 > Hi folks, >=20 > The only change to this version is that we moved to two editors, and list= ed the other co-authors in a contributors section. >=20 > As always, your comments and feedback is appreciated! > Paul >=20 >=20 >>=20 >> A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 >> successfully submitted by Paul Quinn and posted to the IETF=20 >> repository. >>=20 >> Name: draft-quinn-sfc-arch >> Revision: 04 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-01-28 >> Group: Individual Submission >> Pages: 21 >> URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -04.txt >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 04 >>=20 >> Abstract: >> This document describes an architecture used for the creation of >> Service Function Chains (SFC). It includes architectural concepts, >> principles, and components used in the construction of composite >> services through deployment of SFCs in a network. This document does >> not propose solutions, protocols, or extensions to existing >> protocols. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From linda.dunbar@huawei.com Thu Feb 6 07:29:56 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54B51A03E6 for ; Thu, 6 Feb 2014 07:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 SBGhNcggMXgz for ; Thu, 6 Feb 2014 07:29:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF9121A03DB for ; Thu, 6 Feb 2014 07:29:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDH98900; Thu, 06 Feb 2014 15:29:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 15:28:45 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 15:29:27 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 07:29:21 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnO0lQgAGIIYD//6BYIA== Date: Thu, 6 Feb 2014 15:29:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C791FD@dfweml701-chm.china.huawei.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78D55@dfweml701-chm.china.huawei.com> <60F86310-A1E6-47B1-8118-99D9B426995A@cisco.com> In-Reply-To: <60F86310-A1E6-47B1-8118-99D9B426995A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 06 Feb 2014 15:29:57 -0000 For example, a possible policy could be "ingress port #", or even an event.= Just to emphasize that SNF might not use bits/fields in SFC header to forw= ard traffic to the next Service Function Node.=20 Another question, your ServiceFunctionForwarder (SFF) forwards traffic to s= ervice functions, so SFF has to be SF header aware. Is it necessary for SNF= to be SF header aware? Linda=20 -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Thursday, February 06, 2014 9:02 AM To: Linda Dunbar Cc: sfc@ietf.org Subject: Re: New Version Notification for draft-quinn-sfc-arch-04.txt Hi Linda, On Feb 5, 2014, at 4:46 PM, Linda Dunbar wrote: > Paul, et al, >=20 > The "SFC Network Forwarder (SNF)" introduced is to "forward traffic base= d on the information contained in the SFC encapsulation".=20 >=20 > If SFC encapsulation is to carry Metadata/context data (Bullet 4 of Secti= on 1) to be shared, is it possible that the network forwarding nodes could = forward traffic based on policies that are not in the SFC encapsulation? >=20 I'm not sure exactly what you mean, can you give me a bit more context (no = pun intended!), or even better, an example? Thanks Paul > Linda >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn=20 > (paulq) > Sent: Wednesday, January 29, 2014 8:58 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: New Version Notification for=20 > draft-quinn-sfc-arch-04.txt >=20 > Hi folks, >=20 > The only change to this version is that we moved to two editors, and list= ed the other co-authors in a contributors section. >=20 > As always, your comments and feedback is appreciated! > Paul >=20 >=20 >>=20 >> A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 >> successfully submitted by Paul Quinn and posted to the IETF=20 >> repository. >>=20 >> Name: draft-quinn-sfc-arch >> Revision: 04 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-01-28 >> Group: Individual Submission >> Pages: 21 >> URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -04.txt >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 04 >>=20 >> Abstract: >> This document describes an architecture used for the creation of =20 >> Service Function Chains (SFC). It includes architectural concepts, =20 >> principles, and components used in the construction of composite =20 >> services through deployment of SFCs in a network. This document does =20 >> not propose solutions, protocols, or extensions to existing =20 >> protocols. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From linda.dunbar@huawei.com Thu Feb 6 07:36:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB551A013D for ; Thu, 6 Feb 2014 07:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 QAcKLetOdfwM for ; Thu, 6 Feb 2014 07:36:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF51A018E for ; Thu, 6 Feb 2014 07:36:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDH99456; Thu, 06 Feb 2014 15:36:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 15:35:59 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 15:36:41 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 07:36:32 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnK82AgAGWpYD//6QNoA== Date: Thu, 6 Feb 2014 15:36:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7922A@dfweml701-chm.china.huawei.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.com> <80DBC0E1-FBF6-432F-9D12-989D9B798705@cisco.com> In-Reply-To: <80DBC0E1-FBF6-432F-9D12-989D9B798705@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.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, 06 Feb 2014 15:36:52 -0000 Paul,=20 See my suggestion below: -----Original Message----- > The first bullet of 3.2 stated that SF is not longer viewed as a bump in = the wire. Then how do you describe the topology between SFs and their netwo= rk locators or Service Function Forwarders? Isn't it either "bump in a wir= e" or "one armed"? It's not a matter of topology, rather, instead of the SF being "inserted" a= s a bump, it is "consumed", regardless of placement in the network. The te= rm Overlay Service Topology is used in the doc to describes the service cha= ining topology. [Linda] Even with Service Functions being "consumed", it is still very impo= rtant to SFF or/and SNF on "Where to steer traffic to consume the "service = function"", correct?=20 When the "to be consumed" service functions are placed as "One Armed", the = SFF is in full control of where the next hop is. If the "to be consumed ser= vice functions" are placed as "bump in the wire", the SF has to be informed= of the next hop after the treatment.=20 Linda >=20 > Linda >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn=20 > (paulq) > Sent: Wednesday, January 29, 2014 8:58 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: New Version Notification for=20 > draft-quinn-sfc-arch-04.txt >=20 > Hi folks, >=20 > The only change to this version is that we moved to two editors, and list= ed the other co-authors in a contributors section. >=20 > As always, your comments and feedback is appreciated! > Paul >=20 >=20 >>=20 >> A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 >> successfully submitted by Paul Quinn and posted to the IETF=20 >> repository. >>=20 >> Name: draft-quinn-sfc-arch >> Revision: 04 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-01-28 >> Group: Individual Submission >> Pages: 21 >> URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -04.txt >> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 04 >>=20 >> Abstract: >> This document describes an architecture used for the creation of =20 >> Service Function Chains (SFC). It includes architectural concepts, =20 >> principles, and components used in the construction of composite =20 >> services through deployment of SFCs in a network. This document does =20 >> not propose solutions, protocols, or extensions to existing =20 >> protocols. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at tools.ie= tf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From cpignata@cisco.com Thu Feb 6 07:42:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2021A018E for ; Thu, 6 Feb 2014 07:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PixA-ip25XGX for ; Thu, 6 Feb 2014 07:42:23 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id CED4E1A0143 for ; Thu, 6 Feb 2014 07:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24229; q=dns/txt; s=iport; t=1391701342; x=1392910942; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w+2p/KsnAmF8TbhTERVRdxenFIavbNVSuijVmJPSaC4=; b=jGPrqk5khlRqsWNJ8UIJRe+9sgLuEAdZbU1yU4nv7xzu5HbsJ2GC633b rKNMbZok4h1d++N/SVX5JGThsjSQa9gidq4RgGwZPkP3RNDrZF29OpaYf DgENVVEIYobZIR3P8VqUbyGAz4QxgYSJ+vhys6bvKQ0W46rGLSF/zeHvt s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAOur81KtJV2Y/2dsb2JhbABPCoJIRDhXgwGne5N1gQsWdIIlAQEBAwEBAQEgSwsFCwIBCA4DAQIBAQEhBwMCAicLFAMGCAIEDgUODYdWAwkIDax9oSMTBIxkgToELhkRBgGCbzWBFASQP4EyhjqSIYMtgWhC X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="asc'?scan'208,217";a="18471877" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 06 Feb 2014 15:42:21 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s16FgLUQ023309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:42:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:42:20 -0600 From: "Carlos Pignataro (cpignata)" To: Jerome Moisand Thread-Topic: [sfc] SFC using VLANs Thread-Index: AQHPI1IFHNqG7zyjQfCY48eCbUP0Cw== Date: Thu, 6 Feb 2014 15:42:19 +0000 Message-ID: References: <1636122887.9122.1390948057480.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/signed; boundary="Apple-Mail=_6EF65E31-7B80-41F6-B9C8-10B49423179A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "sfc@ietf.org" , "Songhaibin \(A\)" , "S.Majee@F5.com" , "ddolson@sandvine.com" , "mikebianc@aol.com" Subject: Re: [sfc] SFC using VLANs X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:42:25 -0000 --Apple-Mail=_6EF65E31-7B80-41F6-B9C8-10B49423179A Content-Type: multipart/alternative; boundary="Apple-Mail=_889AE57E-1039-4A7B-9753-24CD972A2964" --Apple-Mail=_889AE57E-1039-4A7B-9753-24CD972A2964 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Jerome, Please see inline. On Feb 4, 2014, at 10:33 AM, Jerome Moisand = wrote: > Indeed, quite a few use cases can be addressed by a simple combination = of policy-routing and tunnels (L2 or MPLS or L3) constructs =96 which = isn=92t exactly new! > =20 Indeed, but not without issues. And the issues associated with such = approaches have been extensively discussed over the past few months on = the mailing list as well as documented within the problem statement WG = document (Please see, for example, items 1., 6., 8., and 9. from S2 of = draft-ietf-sfc-problem-statement-00). While there is little disagreement = that some form of service chaining can be applied using these = current-state-of-the-art techniques, it is also true that a number of = issues arise (even called out in the charter). We probably do not need = to re-hash old discussions on this same list.=20 > More complex use cases could be addressed by programming or = controlling some form of forwarding rules in an hypervisor or a switch = or whatever device on the data path. > =20 Again the problem statement (items 9. and 12. more specifically) spells = out the issues with current service insertion models and these issues = are the focus of this WG's work. As a WG we need to produce an = architecture with associated standards that is able to address all of = the issues.=20 > Maybe the broader point would be to formally identify & document what = can be done with regular routing mechanisms, and to which extent this = can address the problem statement, while separating what is truly not = addressed. > =20 Asked a different way -- what gaps do you see in the problem statement = document? We need to have a complete problem statement, which includes = all things that are not resolved with legacy schemes. Thanks, -- Carlos. > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Songhaibin (A) > Sent: Tuesday, January 28, 2014 10:45 PM > To: mikebianc@aol.com; S.Majee@F5.com; ddolson@sandvine.com; = sfc@ietf.org > Subject: Re: [sfc] SFC using VLANs > =20 > Would like to hear more about David=92s implementation too. > =20 > Best Regards! > -Haibin > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com > Sent: Wednesday, January 29, 2014 6:28 AM > To: S.Majee@F5.com; ddolson@sandvine.com; sfc@ietf.org > Subject: Re: [sfc] SFC using VLANs > =20 > There are a number of ways to do this without SFC. You could create = your chain using DSCP markings and use OF in the underlay to forward = traffic with markings set (defaulting to standard IP networking if not = set). Many router vendors support a form of Policy Based Routing (aka = filter based forwarding) that can be used code in the chains per flow. = You could even run an overlay like VXLAN or Contrail or Nuage that = support a chaining-like feature. And, yes, you could build a GRE = encapsulation overlay as well. =20 > =20 > My hope is for SFC to provide a standard, simplified method of doing = this. > =20 > I'm definitely interested to hear more about David's specific = implementation, problems worked around, and features still not possible = to implement with the current configuration. > =20 > =20 >=20 > From: S.Majee@F5.com > To: Dave Dolson,sfc@ietf.org > Sent: Tuesday, January 28, 2014 > Subject: Re: [sfc] SFC using VLANs >=20 > Yes it would be interesting. There are other solution which also build = a dynamic chain based of service characteristic. VLAN tag is the most = obvious choice but is it not possible to use other encapsulation = technology like GRE perhaps? >=20 > =20 >=20 > From: Dave Dolson > Date: Tuesday, January 28, 2014 at 10:35 AM > To: "sfc@ietf.org" > Subject: [sfc] SFC using VLANs >=20 > =20 >=20 > Greetings, > At Sandvine we have been deploying a form of Service Function Chaining = (albeit under different nomenclature) for about 5 years now. > Our Policy Traffic Switch (PTS) platform can initiate and terminate = chains, steering traffic to different chains based on a variety of = traffic and subscriber conditions. > The encapsulation is VLAN tagging, and the requirement on the SF node = is to transparently bridge an Ethernet trunk, forwarding or injecting = traffic using the same Ethernet addresses and VLAN tag. > We have addressed issues of chain symmetry, health checking, failure, = load balancing and sending different chains through the same node. > A benefit of this approach is that explicit chain configuration is not = required in the SF node itself. > An obvious con is the limited number of VLAN tags (no more than 4095), = and the complexity of the switch configuration may lower that further. > If this group is interested, I could elaborate, including the details = and pros/cons, either on this mailing list or in a draft. Any interest? > David Dolson > Senior Software Architect, Sandvine Inc. > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_889AE57E-1039-4A7B-9753-24CD972A2964 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Jerome,

Please see inline.

On = Feb 4, 2014, at 10:33 AM, Jerome Moisand <jmoisand@juniper.net> = wrote:

Indeed, quite a few use cases can be addressed by a = simple combination of policy-routing and tunnels (L2 or MPLS or L3) = constructs =E2=80=93 which isn=E2=80=99t exactly = new!
 

Ind= eed, but not without issues. And the issues associated with such = approaches have been extensively discussed over the past few months on = the mailing list as well as documented within the problem statement = WG document (Please see, for example, items 1., 6., 8., and 9. from = S2 of draft-ietf-sfc-problem-statement-00). While there is little = disagreement that some form of service chaining can be applied using = these current-state-of-the-art techniques, it is also true that a = number of issues arise (even called out in the charter). We = probably do not need to re-hash old discussions on this same = list. 

More complex use cases = could be addressed by programming or controlling some form of forwarding = rules in an hypervisor or a switch or whatever device on the data = path.
 

Aga= in the problem statement (items 9. and 12. more specifically) spells out = the issues with current service insertion models and these issues are = the focus of this WG's work. As a WG we need to produce an architecture = with associated standards that is able to address all of the = issues. 

Maybe the broader point = would be to formally identify & document what can be done with = regular routing mechanisms, and to which extent this can address the = problem statement, while separating what is truly not = addressed.
 

Ask= ed a different way -- what gaps do you see in the problem statement = document? We need to have a complete problem statement, which includes = all things that are not resolved with legacy = schemes.

Thanks,

-- = Carlos.

 
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Songhaibin = (A)
Sent: Tuesday, January 28, 2014 = 10:45 PM
To: mikebianc@aol.com; S.Majee@F5.com; ddolson@sandvine.com; sfc@ietf.org
Subject: Re: [sfc] SFC using = VLANs
 
Would like to hear more about David=E2=80=99s = implementation too.
 
Best = Regards!
-Haibin
 
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: Wednesday, January 29, 2014 = 6:28 AM
To: S.Majee@F5.com; ddolson@sandvine.com; sfc@ietf.org
Subject: Re: [sfc] SFC using = VLANs
 
There are a = number of ways to do this without SFC.  You could create your chain = using DSCP markings and use OF in the underlay to forward traffic with = markings set (defaulting to standard IP networking if not set). =  Many router vendors support a form of Policy Based Routing (aka = filter based forwarding) that can be used code in the chains per flow. =  You could even run an overlay like VXLAN or Contrail or Nuage that = support a chaining-like feature.  And, yes, you could build a GRE = encapsulation overlay as well. =  
 
My hope is = for SFC to provide a standard, simplified method of doing = this.
 
I'm = definitely interested to hear more about David's specific = implementation, problems worked around, and features still not possible = to implement with the current = configuration.
 

 

From: S.Majee@F5.com<S.Majee@F5.com>
To: Dave Dolson<ddolson@sandvine.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, January 28, = 2014
Subject: Re: [sfc] SFC using = VLANs

Yes it would = be interesting. There are other solution which also build a dynamic = chain based of service characteristic. VLAN tag is the most obvious = choice but is it not possible to use other encapsulation technology like = GRE perhaps?

 

From: Dave Dolson = <ddolson@sandvine.com>
Date: Tuesday, January 28, = 2014 at 10:35 AM
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] SFC using = VLANs

 

Greetings,
At = Sandvine we have been deploying a form of Service Function Chaining = (albeit under different nomenclature) for about 5 years = now.
Our Policy Traffic Switch (PTS) = platform can initiate and terminate chains, steering traffic to = different chains based on a variety of traffic and subscriber = conditions.
The encapsulation is = VLAN tagging, and the requirement on the SF node is to transparently = bridge an Ethernet trunk, forwarding or injecting traffic using the same = Ethernet addresses and VLAN tag.
We = have addressed issues of chain symmetry, health checking, failure, load = balancing and sending different chains through the same = node.
A benefit of this approach is = that explicit chain configuration is not required in the SF node = itself.
An obvious con is the = limited number of VLAN tags (no more than 4095), and the complexity of = the switch configuration may lower that further.
If this group is interested, I could elaborate, = including the details and pros/cons, either on this mailing list or in a = draft. Any interest?
David = Dolson
Senior Software = Architect, Sandvine = Inc.
___________________________________= ____________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mail= man/listinfo/sfc

= --Apple-Mail=_889AE57E-1039-4A7B-9753-24CD972A2964-- --Apple-Mail=_6EF65E31-7B80-41F6-B9C8-10B49423179A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLzrVsACgkQtfDPGTp3USw5EACghPAV6JwEjGe9njjsUDl7k9xR v2MAniUq60CEZk1/6A2hu3yZ+rPKwW2x =OOkV -----END PGP SIGNATURE----- --Apple-Mail=_6EF65E31-7B80-41F6-B9C8-10B49423179A-- From cfrederick@sandvine.com Thu Feb 6 07:51:10 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304211A01E7 for ; Thu, 6 Feb 2014 07:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 v6C985FfqGCL for ; Thu, 6 Feb 2014 07:51:08 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id D7F731A03CE for ; Thu, 6 Feb 2014 07:51:07 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Thu, 6 Feb 2014 10:51:06 -0500 From: Chris Frederick To: "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQgAJzAwCAABGWAIAAip1Q Date: Thu, 6 Feb 2014 15:51:06 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:51:10 -0000 Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Chuong.D.Pham@team.telstra.com Thu Feb 6 15:11:57 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB26C1A0511 for ; Thu, 6 Feb 2014 15:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk8n3PdLZgoL for ; Thu, 6 Feb 2014 15:11:54 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3F1A04C8 for ; Thu, 6 Feb 2014 15:11:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,796,1384261200"; d="scan'208";a="193110043" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Feb 2014 10:11:50 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7341"; a="191925297" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 07 Feb 2014 10:10:50 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 7 Feb 2014 10:10:49 +1100 From: "Pham, Chuong D" To: Chris Frederick , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Date: Fri, 7 Feb 2014 10:10:48 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: Ac8jU0frRa2MqZBFT0WAK4lGi7qVmgAOmTXg Message-ID: <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 23:11:58 -0000 Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Thu Feb 6 17:47:22 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5271A058F for ; Thu, 6 Feb 2014 17:47:22 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwmVQ_6gadXJ for ; Thu, 6 Feb 2014 17:47:19 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 988031A0587 for ; Thu, 6 Feb 2014 17:47:19 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 17:47:18 -0800 From: Ron Parker To: "Pham, Chuong D" , Chris Frederick , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDNx7z7hVsl0kmLmsfjrb5gPZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62gD//6MqwA== Date: Fri, 7 Feb 2014 01:47:18 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 01:47:22 -0000 The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 paulq@cisco.com Fri Feb 7 07:21:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42CF1A8034 for ; Fri, 7 Feb 2014 07:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv19kgDyIliL for ; Fri, 7 Feb 2014 07:21:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B0CF91AC4C1 for ; Fri, 7 Feb 2014 07:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6840; q=dns/txt; s=iport; t=1391786508; x=1392996108; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G9KQRY6O1VrhFdl5aeYy3hYA/Ip6YMQih8rWXK/CHuM=; b=jXdCiN6ZF7pyq58G6jH6EQ1qs+yYJF3NGC+8DCDT3IjQPi63tcYbU6Ri PGqd/+Zg12coTXuMzTTtVCpCrL15uAkbt8cd9jfehFa6BDaGfLGDuSxKf vV4ti8l22HiYAwcUGbwNyv1Vk+FMEbd3IeXfua07gdML8EKuoqlsJWg9u 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAOT49FKtJV2Y/2dsb2JhbABZgkhEOFe+aIEOFnSCJgEBBAEBAWsLEAIBCBItBycLFAMOAgQBDQUJh3wNzFcXjilUB4MkgRQEmCuSIYMtgio X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208,217";a="302555799" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 07 Feb 2014 15:21:47 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s17FLlQP030395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 15:21:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 09:21:46 -0600 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: [sfc] SFC WG Agenda: London Thread-Index: AQHPH3JY7vfIB63+W06bsptZEKAjcZqqVkwA Date: Fri, 7 Feb 2014 15:21:46 +0000 Message-ID: <21F85EC8-FE49-45AA-AB63-3C916AE8D257@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_21F85EC8FE4945AAAB633C916AE8D257ciscocom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC WG Agenda: London X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 15:21:52 -0000 --_000_21F85EC8FE4945AAAB633C916AE8D257ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Thomas, I'd like a slot on the agenda for the architecture draft (http://www.ietf.o= rg/internet-drafts/draft-quinn-sfc-arch-04.txt) thanks, Paul On Feb 1, 2014, at 12:23 PM, Jim Guichard (jguichar) > wrote: Greetings, It's time to start putting together an agenda for the SFC meeting in London= . We've requested one 2.5 hour slot . Because face-to-face time is precious= , we intend to focus on: - WG chartered items for which we have WG-adopted IDs, or IDs that appear h= eaded for WG adoption. - Specific topics where feedback is needed, and mailing list discussions ha= ve not converged. We also do not intend to give agenda time to everyone who has a draft - the= WG sessions do not have time for that, nor is it necessarily an effective = use of time. We also do not intend to give agenda time for drafts for which= little or no mailing list interest has been generated. For the upcoming session, we expect to focus on: 1) Problem satement (hopefully not much time needed -- are there any actual= open issues?). 2) Use cases. 3) Architecture. If you have a draft (or plan to submit one) and would like to present (or m= ore specifically, would like the working group to do something with your dr= aft), please: 1) Let us know now (even if the draft is not published yet), so we can star= t planning; 2) Indicate which WG deliverable the draft relates to; and 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Thanks! Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_21F85EC8FE4945AAAB633C916AE8D257ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Jim, Thomas,

I'd like a slot on the agenda for the architecture draft (http://www.= ietf.org/internet-drafts/draft-quinn-sfc-arch-04.txt)

thanks,
Paul

On Feb 1, 2014, at 12:23 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Greetings,

It's time to start putting together an agenda for the SFC meeting = in London. We've requested o= ne 2.5 hour slot . Because face-to-face time is precious, we intend to f= ocus on:

- WG chartered items for which we have WG= -adopted IDs, or IDs that appear headed for WG adoption.

- Specific topics where feedback is neede= d, and mailing list discussions have not converged.

We also do not intend to give agenda time= to everyone who has a draft - the WG sessions do not have time for that, n= or is it necessarily an effective use of time. We also do not intend to giv= e agenda time for drafts for which little or no mailing list interest has been generated.

For the upcoming session, we expect to fo= cus on:

1) Problem satement (hopefully not much t= ime needed -- are there any actual open issues?).

2) Use cases.

3) Architecture.

If you have a draft (or plan to submit on= e) and would like to present (or more specifically, would like the working = group to do something with your draft), please:

1) Let us know now (even if the draft is = not published yet), so we can start planning;

2) Indicate which WG deliverable the draf= t relates to; and

3) Indicate what you want the WG to do wi= th your draft. E.g., do you want this to become "THE" WG document= for a particular deliverable? Or, is there content in the document you bel= ieve should be added to another document? etc. Please do not just respond "I want it to become a WG document". = It would be better to explain in what context, and how your draft relates t= o other drafts that have been submitted.

Thanks!

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

--_000_21F85EC8FE4945AAAB633C916AE8D257ciscocom_-- From cfrederick@sandvine.com Fri Feb 7 08:55:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782581A0425 for ; Fri, 7 Feb 2014 08:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 eSCf8ssI83uK for ; Fri, 7 Feb 2014 08:55:33 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id B36DE1A0177 for ; Fri, 7 Feb 2014 08:55:32 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Fri, 7 Feb 2014 11:55:32 -0500 From: Chris Frederick To: Ron Parker , "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQgAJzAwCAABGWAIAAip1QgADRuACAACu6AIAAo4cQ Date: Fri, 7 Feb 2014 16:55:32 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:55:35 -0000 I agree that PCRF signaling on a per-flow basis in this context seems impra= ctical; also that consolidating the flow recognition + decision-making enti= ty in a single node reduces the complexity (that's how we do our SFC implem= entation). Fwiw, I have a supplemental comment on the idea of service function reclass= ification, in general. I know the working group has been contemplating this for some time. "Per-Se= rvice Reclassification" is one of the items in the Problem Statement, but t= he problem seems to be framed more in terms of the resource overhead incurr= ed by the classification + sharing of metadata between service functions in= this context (which are valid concerns).=20 However, imo, there is also an inherent assumption of 'flow stickiness' tha= t is important; therefore, service function reclassification should be the = exception rather than the rule, I would think.=20 It's conceivable that permitting service functions to play a role in reclas= sification might be desirable, in certain cases, but once a service chain i= s selected, it should generally not be changed, because modification of the= flow path by a service function within the chain could result in a 'breaki= ng' of the chain or flow.=20 If there is not bidirectional symmetry in the flow and service function ele= ments in the chain can make routing decisions, this is a recipe for problem= s.=20 Each service function in the chain should be agnostic about its upstream an= d downstream nodes. Allowing service functions within a chain to second-gue= ss the ordering can break bidirectional flows.=20 I would think that any service function re-classification must necessarily = be limited in scope viz the output chains it can select; it shouldn't be po= ssible for a downstream service function to be bypassed. Therefore, any re-= classification would need to be constrained to sub-chains that return to th= e original chain, I would think. Thx, /c -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, February 06, 2014 8:47 PM To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 Ron_Parker@affirmednetworks.com Fri Feb 7 09:21:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599DF1ACCDA for ; Fri, 7 Feb 2014 09:21:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-A3q43wst-m for ; Fri, 7 Feb 2014 09:21:21 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id EAF011ACCF9 for ; Fri, 7 Feb 2014 09:21:15 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 09:21:16 -0800 From: Ron Parker To: Chris Frederick , "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDNx7z7hVsl0kmLmsfjrb5gPZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62gD//6MqwIABhlEA//9/W5A= Date: Fri, 7 Feb 2014 17:21:14 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:21:32 -0000 Hi, Chris. I think that the service function reclassification is more to achieve branc= hing within the overall service function graph, but I do agree that it will= in practice be the exception rather than the rule in many typical deployme= nts. You raise the issue of bidirectional chains and I think that will be the ru= le rather than the exception in many typical deployments. Bidirectional, = perhaps, could also be addressed more generally as directionally correlated= flows. That is, for a given "forward" chain X, there exists a "reverse" = chain Y that is not necessarily an exact inverse sequence of X. I feel the group should give much attention to the important topic of how t= o achieve (but not require) directionally correlated chains. Ron -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, February 07, 2014 11:56 AM To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson;= Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; s= fc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt I agree that PCRF signaling on a per-flow basis in this context seems impra= ctical; also that consolidating the flow recognition + decision-making enti= ty in a single node reduces the complexity (that's how we do our SFC implem= entation). Fwiw, I have a supplemental comment on the idea of service function reclass= ification, in general. I know the working group has been contemplating this for some time. "Per-Se= rvice Reclassification" is one of the items in the Problem Statement, but t= he problem seems to be framed more in terms of the resource overhead incurr= ed by the classification + sharing of metadata between service functions in= this context (which are valid concerns).=20 However, imo, there is also an inherent assumption of 'flow stickiness' tha= t is important; therefore, service function reclassification should be the = exception rather than the rule, I would think.=20 It's conceivable that permitting service functions to play a role in reclas= sification might be desirable, in certain cases, but once a service chain i= s selected, it should generally not be changed, because modification of the= flow path by a service function within the chain could result in a 'breaki= ng' of the chain or flow.=20 If there is not bidirectional symmetry in the flow and service function ele= ments in the chain can make routing decisions, this is a recipe for problem= s.=20 Each service function in the chain should be agnostic about its upstream an= d downstream nodes. Allowing service functions within a chain to second-gue= ss the ordering can break bidirectional flows.=20 I would think that any service function re-classification must necessarily = be limited in scope viz the output chains it can select; it shouldn't be po= ssible for a downstream service function to be bypassed. Therefore, any re-= classification would need to be constrained to sub-chains that return to th= e original chain, I would think. Thx, /c -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 06, 2014 8:47 PM To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com] Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 jguichar@cisco.com Fri Feb 7 09:31:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EAB1A0416 for ; Fri, 7 Feb 2014 09:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPzqk8EiKhHn for ; Fri, 7 Feb 2014 09:31:12 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 54C121ACCE2 for ; Fri, 7 Feb 2014 09:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15195; q=dns/txt; s=iport; t=1391794272; x=1393003872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zTdTxA98TxfIO3kjseA7I6dLlJcl0BmIGIts07Y7tmg=; b=mbDfs43WezLesjerBhdFLALlI4/Tg8+7088LbvuH995wQ6qr1mHsQ8q9 B6L33AS9EWK9OHM0Dkfj9dqDfij7pAGAy4fhMCQAVDdBjU/60G8nifGUD ZX/gRt0BWoMAqsb0ijrrqcuZ6YXmLdEEvXUYvOfPJ2w4PoshylwyDELbS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAOgX9VKtJV2Z/2dsb2JhbABZgww4V75ogQ4WdIIlAQEBBAEBAWQHCwwEAgEIDgMBAgEBASgHJwsUAwYIAgQBDQUJh3wNzBMXjhAVUwUCBQaEMgSJEY8agTKLL4VAgy2BaEI X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="18781277" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 07 Feb 2014 17:31:11 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s17HVBsu015282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 17:31:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 11:31:10 -0600 From: "Jim Guichard (jguichar)" To: Chris Frederick , Ron Parker , "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDONoNCsKACHkWaTZiaKJL0qZql53uAgAH2hQCAABGVAIAA4XwAgAB62gCAACu5AIAA/cIA//+2HgA= Date: Fri, 7 Feb 2014 17:31:10 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.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: [10.98.43.188] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <58559AA8AA70F84EB8B5A169F7F70D5F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:31:16 -0000 Chris, If you take the stance that a reclassification of a flow along an original chain (that forces said flow away from the original chain) forwards the flow into a *new* chain, then in the reverse direction of the *new* chain there may or may not be a need for symmetry (for either the *new* or *original* chain). In the case where symmetry is required for the *original* chain then presumably it is true that a correlation between the *original* and the *new* chains is necessary and there are several ways in which that could be achieved. On 2/7/14, 11:55 AM, "Chris Frederick" wrote: >I agree that PCRF signaling on a per-flow basis in this context seems >impractical; also that consolidating the flow recognition + >decision-making entity in a single node reduces the complexity (that's >how we do our SFC implementation). >Fwiw, I have a supplemental comment on the idea of service function >reclassification, in general. >I know the working group has been contemplating this for some time. >"Per-Service Reclassification" is one of the items in the Problem >Statement, but the problem seems to be framed more in terms of the >resource overhead incurred by the classification + sharing of metadata >between service functions in this context (which are valid concerns). >However, imo, there is also an inherent assumption of 'flow stickiness' >that is important; therefore, service function reclassification should be >the exception rather than the rule, I would think. >It's conceivable that permitting service functions to play a role in >reclassification might be desirable, in certain cases, but once a service >chain is selected, it should generally not be changed, because >modification of the flow path by a service function within the chain >could result in a 'breaking' of the chain or flow. >If there is not bidirectional symmetry in the flow and service function >elements in the chain can make routing decisions, this is a recipe for >problems.=20 >Each service function in the chain should be agnostic about its upstream >and downstream nodes. Allowing service functions within a chain to >second-guess the ordering can break bidirectional flows. >I would think that any service function re-classification must >necessarily be limited in scope viz the output chains it can select; it >shouldn't be possible for a downstream service function to be bypassed. >Therefore, any re-classification would need to be constrained to >sub-chains that return to the original chain, I would think. Thx, >/c > > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Thursday, February 06, 2014 8:47 PM >To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave >Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >The use case of the offline (mirrored feed) DPI interacting with the SFC >is an interesting one. Wrt the inline DPI case, since we've said that >any service function can reclassify, at first glance it isn't any >different than any other service function. > >Putting the 2 cases together, do we want to portray the flow recognition >entity separately from the per-flow decision making entity? This is >somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, >there are severe scaling constraints to actually engage the PCRF on a >per-flow basis. Of course, choosing to portray these as separate >entities means that a protocol needs to be defined between them. By >assuming that the flow recognition entity is also the decision making >entity (i.e., the policy decision point in some of the drafts), the >complexity of the problem is reduced. > >Thoughts? > > Ron > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Thursday, February 06, 2014 6:11 PM >To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chris, > >It depends on how you look at the issue. > >In this comment " there is also the case where the DPI actually >determines the chain + steers the flow through the SFC, >bidirectionally.", there are two separate functions, "determines" and >"steers". The determination function could be inline or offline. The >steer function needs to be inline but this function could be provided for >by the SFC, not necessarily the DPI. > >I agree that we should generalise and include both offline and inline >modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012). > >There are cases where offline mode is beneficial. For example, to >determine a heat map (list of IP addresses) of popular but problematic >video servers, only one DPI in a major region (can combine with sampling >technique to reduce load on this DPI) may be adequate, assumed that as >these videos are wanted by users in other regions as well as they are >popular. Another advantage is when the DPI is offline (for the right use >cases), the risk to customer traffic is significantly reduced. > >Regards, >Chuong >-----Original Message----- >From: Chris Frederick [mailto:cfrederick@sandvine.com] >Sent: Friday, 7 February 2014 2:51 AM >To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chuong, >As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps >not ideal for traffic steering/service chaining; devices that receive >only an offline copy of a flow cannot themselves redirect/steer that >flow. So, I wouldn't necessarily agree that the only case where the DPI >is required to be inline is when it acts as a service function; there is >also the case where the DPI actually determines the chain + steers the >flow through the SFC, bidirectionally. I'd further argue that this is >actually ideal as it obviates some unnecessary signaling overhead. >Of course, it's possible to deploy offline as you note, with the implicit >assumption that the offline DPI would then be signaling back to inline >devices (either directly or circuitously through a PCRF), perhaps with >inherent race conditions, etc. >Thanks, >/c > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Wednesday, February 05, 2014 9:24 PM >To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >Would you please consider my thoughts below in the Draft. > >1-The TDF is an inline function which inspects user payload at >application layer i.e. inspect HTTP headers. With the trend in adoption >of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing >30% etc.), the capability of the TDF to be able to inspect at application >may be diminished. > >2- The use of a DPI function in place of the TDF which may or may have an >interface to the PCRF. This DPI for many traffic cases, do not have to be >deployed in line with customer traffic. It can be deployed in an >out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent >information for traffic steering/service chaining actions. The only use >case where the DPI is required to be in line is when it acts as an >enforcement Service Function however in this mode, it needs to be treated >as a Service Function, not a traffic steering device. > >3- Section 6.2 current has this paragraph: >"...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." > >I agreed with paragraph and therefore we could include something to the >effect of an "actionable intelligence" function which receives inputs >from sources such as the network and the traffic, derive traffic steering >decisions and communicate with the service chaining function. > >Examples:=20 >-Receive from the Mobile network the list of user's ip addresses who are >at the present located in the congested cells so that new video sessions >are steered to a video optimisation platform. >- Inspect network traffic (in out-of-path mode) and derive a heat map of >problematic TCP flows which may be benefited from TCP Optimiser and steer >traffic to this device. >- Inspect network traffic and derive a heat map of popular content >remotely located and steer traffic to a local Web Cache so that content >is made available locally for the current and future users. > >Regards, >Chuong > >=20 > >-----Original Message----- >From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] >Sent: Thursday, 6 February 2014 12:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph >in -01. Possibly we will consider 2 sections: most simple case (with >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of the >Traffic Detection Function (TDF), also described in the cited 3GPP TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood that >the P-GW is not the only location from which a policy-based service chain >could be initiated; the standard TDF function can also initiate service >chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and the >(S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of the >draft, ADC rules can cause decisions based on application type (not just >based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it wasn't >posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >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 cfrederick@sandvine.com Fri Feb 7 10:07:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FBA1ACCDE for ; Fri, 7 Feb 2014 10:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 q28qMLEbuvpC for ; Fri, 7 Feb 2014 10:07:01 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id F0C381A0176 for ; Fri, 7 Feb 2014 10:07:00 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Fri, 7 Feb 2014 13:07:00 -0500 From: Chris Frederick To: "'jguichar@cisco.com'" , "'Ron_Parker@affirmednetworks.com'" , "'Chuong.D.Pham@team.telstra.com'" , "'walter.haeffner@vodafone.com'" , Dave Dolson , "'mls.ietf@gmail.com'" , "'draft-haeffner-sfc-use-case-mobility@tools.ietf.org'" , "'sfc@ietf.org'" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQgAJzAwCAABGWAIAAip1QgADRuACAACu6AIAAo4cQgABkLwD//7YxwQ== Date: Fri, 7 Feb 2014 18:06:59 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A18883E3F@wtl-exchp-2.sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'jenapper@cisco.com'" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:07:05 -0000 Jim, I'm not sure I understand. Are the "several ways" to share metadata + correlate between chains in this= way elucidated somewhere?=20 I'm thinking of v simple, v common, real-world deployments (like say, a com= mercial network video streaming case w/ autonomous service funtions for vid= eo optimization/compression + caching) wherein those service functions woul= d have reclassification abilities. Thx, Chris Frederick Director, Technology Partnerships Sandvine Incorporated www.sandvine.com Mobile: +1.519.500.5016=20 ----- Original Message ----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Friday, February 07, 2014 12:31 PM=0A= To: Chris Frederick; Ron Parker ; Pham, Ch= uong D ; Haeffner, Walter, Vodafone DE ; Dave Dolson; Martin Stiemerling ; draft-haeffner-sfc-use-case-mobility@tools.ietf.org ; sfc@ietf.org Cc: Jeffrey Napper (jenapper) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Chris, If you take the stance that a reclassification of a flow along an original chain (that forces said flow away from the original chain) forwards the flow into a *new* chain, then in the reverse direction of the *new* chain there may or may not be a need for symmetry (for either the *new* or *original* chain). In the case where symmetry is required for the *original* chain then presumably it is true that a correlation between the *original* and the *new* chains is necessary and there are several ways in which that could be achieved. On 2/7/14, 11:55 AM, "Chris Frederick" wrote: >I agree that PCRF signaling on a per-flow basis in this context seems >impractical; also that consolidating the flow recognition + >decision-making entity in a single node reduces the complexity (that's >how we do our SFC implementation). >Fwiw, I have a supplemental comment on the idea of service function >reclassification, in general. >I know the working group has been contemplating this for some time. >"Per-Service Reclassification" is one of the items in the Problem >Statement, but the problem seems to be framed more in terms of the >resource overhead incurred by the classification + sharing of metadata >between service functions in this context (which are valid concerns). >However, imo, there is also an inherent assumption of 'flow stickiness' >that is important; therefore, service function reclassification should be >the exception rather than the rule, I would think. >It's conceivable that permitting service functions to play a role in >reclassification might be desirable, in certain cases, but once a service >chain is selected, it should generally not be changed, because >modification of the flow path by a service function within the chain >could result in a 'breaking' of the chain or flow. >If there is not bidirectional symmetry in the flow and service function >elements in the chain can make routing decisions, this is a recipe for >problems.=20 >Each service function in the chain should be agnostic about its upstream >and downstream nodes. Allowing service functions within a chain to >second-guess the ordering can break bidirectional flows. >I would think that any service function re-classification must >necessarily be limited in scope viz the output chains it can select; it >shouldn't be possible for a downstream service function to be bypassed. >Therefore, any re-classification would need to be constrained to >sub-chains that return to the original chain, I would think. Thx, >/c > > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Thursday, February 06, 2014 8:47 PM >To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave >Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >The use case of the offline (mirrored feed) DPI interacting with the SFC >is an interesting one. Wrt the inline DPI case, since we've said that >any service function can reclassify, at first glance it isn't any >different than any other service function. > >Putting the 2 cases together, do we want to portray the flow recognition >entity separately from the per-flow decision making entity? This is >somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, >there are severe scaling constraints to actually engage the PCRF on a >per-flow basis. Of course, choosing to portray these as separate >entities means that a protocol needs to be defined between them. By >assuming that the flow recognition entity is also the decision making >entity (i.e., the policy decision point in some of the drafts), the >complexity of the problem is reduced. > >Thoughts? > > Ron > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Thursday, February 06, 2014 6:11 PM >To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chris, > >It depends on how you look at the issue. > >In this comment " there is also the case where the DPI actually >determines the chain + steers the flow through the SFC, >bidirectionally.", there are two separate functions, "determines" and >"steers". The determination function could be inline or offline. The >steer function needs to be inline but this function could be provided for >by the SFC, not necessarily the DPI. > >I agree that we should generalise and include both offline and inline >modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012). > >There are cases where offline mode is beneficial. For example, to >determine a heat map (list of IP addresses) of popular but problematic >video servers, only one DPI in a major region (can combine with sampling >technique to reduce load on this DPI) may be adequate, assumed that as >these videos are wanted by users in other regions as well as they are >popular. Another advantage is when the DPI is offline (for the right use >cases), the risk to customer traffic is significantly reduced. > >Regards, >Chuong >-----Original Message----- >From: Chris Frederick [mailto:cfrederick@sandvine.com] >Sent: Friday, 7 February 2014 2:51 AM >To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chuong, >As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps >not ideal for traffic steering/service chaining; devices that receive >only an offline copy of a flow cannot themselves redirect/steer that >flow. So, I wouldn't necessarily agree that the only case where the DPI >is required to be inline is when it acts as a service function; there is >also the case where the DPI actually determines the chain + steers the >flow through the SFC, bidirectionally. I'd further argue that this is >actually ideal as it obviates some unnecessary signaling overhead. >Of course, it's possible to deploy offline as you note, with the implicit >assumption that the offline DPI would then be signaling back to inline >devices (either directly or circuitously through a PCRF), perhaps with >inherent race conditions, etc. >Thanks, >/c > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Wednesday, February 05, 2014 9:24 PM >To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >Would you please consider my thoughts below in the Draft. > >1-The TDF is an inline function which inspects user payload at >application layer i.e. inspect HTTP headers. With the trend in adoption >of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing >30% etc.), the capability of the TDF to be able to inspect at application >may be diminished. > >2- The use of a DPI function in place of the TDF which may or may have an >interface to the PCRF. This DPI for many traffic cases, do not have to be >deployed in line with customer traffic. It can be deployed in an >out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent >information for traffic steering/service chaining actions. The only use >case where the DPI is required to be in line is when it acts as an >enforcement Service Function however in this mode, it needs to be treated >as a Service Function, not a traffic steering device. > >3- Section 6.2 current has this paragraph: >"...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." > >I agreed with paragraph and therefore we could include something to the >effect of an "actionable intelligence" function which receives inputs >from sources such as the network and the traffic, derive traffic steering >decisions and communicate with the service chaining function. > >Examples:=20 >-Receive from the Mobile network the list of user's ip addresses who are >at the present located in the congested cells so that new video sessions >are steered to a video optimisation platform. >- Inspect network traffic (in out-of-path mode) and derive a heat map of >problematic TCP flows which may be benefited from TCP Optimiser and steer >traffic to this device. >- Inspect network traffic and derive a heat map of popular content >remotely located and steer traffic to a local Web Cache so that content >is made available locally for the current and future users. > >Regards, >Chuong > >=20 > >-----Original Message----- >From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] >Sent: Thursday, 6 February 2014 12:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph >in -01. Possibly we will consider 2 sections: most simple case (with >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of the >Traffic Detection Function (TDF), also described in the cited 3GPP TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood that >the P-GW is not the only location from which a policy-based service chain >could be initiated; the standard TDF function can also initiate service >chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and the >(S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of the >draft, ADC rules can cause decisions based on application type (not just >based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it wasn't >posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >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 jguichar@cisco.com Fri Feb 7 11:34:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCB51ACCFF for ; Fri, 7 Feb 2014 11:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUmMy5lvqPhF for ; Fri, 7 Feb 2014 11:34:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA811ACCF2 for ; Fri, 7 Feb 2014 11:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17593; q=dns/txt; s=iport; t=1391801674; x=1393011274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K4COZR9eru7gaJLwaxI75+0f+02/eesVqElnrIuTpRA=; b=ixalCOzWQ2QMa1lMRJ0nOvzHJsmOOqy+RGpXSjzjNwuVXR8xI838CZkR IKxwqmVHkARCn1iah9PeWgtlG6NUQOW0O00zDAgkYnLJ94cPIIzDHsA5x o2Qy9GNtPwcC4wWuJUddrNm12dsTNtqs6puhEWzqqZ65i37KvBSMM+pgp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPkz9VKtJV2Y/2dsb2JhbABWA4MMOL9CgQ4WdIIlAQEBAwEBAQFGHgcDCAUHBAIBCA4DAQIBAQEBJwchBgsUAwYIAgQOBQmHaAMJCA3DTQ0QiDQXjGaBKhUlCAoRCwUCBQIEC4MTgRQEiRGNLoFsgTKLLAOFQIMtgWg X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="18819126" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 07 Feb 2014 19:34:33 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s17JYXX3024608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 19:34:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 13:34:32 -0600 From: "Jim Guichard (jguichar)" To: Chris Frederick Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDONoNCsKACHkWaTZiaKJL0qZql53uAgAH2hQCAABGVAIAA4XwAgAB62gCAACu5AIAA/cIA//+2HgCAAF3ZgP//s+Fr Date: Fri, 7 Feb 2014 19:34:32 +0000 Message-ID: References: , <802F0FD88084CC4D82A0663874219D1A18883E3F@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18883E3F@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "mls.ietf@gmail.com" , "walter.haeffner@vodafone.com" , "Ron_Parker@affirmednetworks.com" , "Jeffrey Napper \(jenapper\)" , "Chuong.D.Pham@team.telstra.com" , Dave Dolson Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:34:39 -0000 Hi Chris, Metadata is one option (using whatever service encapsulation we as a WG def= ine) but it is also possible through direct control plane interactions (as = yet to be determined). Sent from my iPhone > On Feb 7, 2014, at 1:07 PM, "Chris Frederick" w= rote: >=20 > Jim, > I'm not sure I understand. > Are the "several ways" to share metadata + correlate between chains in th= is way elucidated somewhere?=20 > I'm thinking of v simple, v common, real-world deployments (like say, a c= ommercial network video streaming case w/ autonomous service funtions for v= ideo optimization/compression + caching) wherein those service functions wo= uld have reclassification abilities. Thx, >=20 >=20 > Chris Frederick > Director, Technology Partnerships > Sandvine Incorporated > www.sandvine.com > Mobile: +1.519.500.5016=20 >=20 >=20 > ----- Original Message ----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Friday, February 07, 2014 12:31 PM > To: Chris Frederick; Ron Parker ; Pham, = Chuong D ; Haeffner, Walter, Vodafone DE ; Dave Dolson; Martin Stiemerling ; draft-haeffner-sfc-use-case-mobility@tools.ietf.org ; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Chris, >=20 > If you take the stance that a reclassification of a flow along an origina= l > chain (that forces said flow away from the original chain) forwards the > flow into a *new* chain, then in the reverse direction of the *new* chain > there may or may not be a need for symmetry (for either the *new* or > *original* chain). In the case where symmetry is required for the > *original* chain then presumably it is true that a correlation between th= e > *original* and the *new* chains is necessary and there are several ways i= n > which that could be achieved. >=20 >> On 2/7/14, 11:55 AM, "Chris Frederick" wrote: >>=20 >> I agree that PCRF signaling on a per-flow basis in this context seems >> impractical; also that consolidating the flow recognition + >> decision-making entity in a single node reduces the complexity (that's >> how we do our SFC implementation). >> Fwiw, I have a supplemental comment on the idea of service function >> reclassification, in general. >> I know the working group has been contemplating this for some time. >> "Per-Service Reclassification" is one of the items in the Problem >> Statement, but the problem seems to be framed more in terms of the >> resource overhead incurred by the classification + sharing of metadata >> between service functions in this context (which are valid concerns). >> However, imo, there is also an inherent assumption of 'flow stickiness' >> that is important; therefore, service function reclassification should b= e >> the exception rather than the rule, I would think. >> It's conceivable that permitting service functions to play a role in >> reclassification might be desirable, in certain cases, but once a servic= e >> chain is selected, it should generally not be changed, because >> modification of the flow path by a service function within the chain >> could result in a 'breaking' of the chain or flow. >> If there is not bidirectional symmetry in the flow and service function >> elements in the chain can make routing decisions, this is a recipe for >> problems.=20 >> Each service function in the chain should be agnostic about its upstream >> and downstream nodes. Allowing service functions within a chain to >> second-guess the ordering can break bidirectional flows. >> I would think that any service function re-classification must >> necessarily be limited in scope viz the output chains it can select; it >> shouldn't be possible for a downstream service function to be bypassed. >> Therefore, any re-classification would need to be constrained to >> sub-chains that return to the original chain, I would think. Thx, >> /c >>=20 >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Thursday, February 06, 2014 8:47 PM >> To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave >> Dolson; Martin Stiemerling; >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> The use case of the offline (mirrored feed) DPI interacting with the SFC >> is an interesting one. Wrt the inline DPI case, since we've said that >> any service function can reclassify, at first glance it isn't any >> different than any other service function. >>=20 >> Putting the 2 cases together, do we want to portray the flow recognition >> entity separately from the per-flow decision making entity? This is >> somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, >> there are severe scaling constraints to actually engage the PCRF on a >> per-flow basis. Of course, choosing to portray these as separate >> entities means that a protocol needs to be defined between them. By >> assuming that the flow recognition entity is also the decision making >> entity (i.e., the policy decision point in some of the drafts), the >> complexity of the problem is reduced. >>=20 >> Thoughts? >>=20 >> Ron >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >> Sent: Thursday, February 06, 2014 6:11 PM >> To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >> Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >> sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi Chris, >>=20 >> It depends on how you look at the issue. >>=20 >> In this comment " there is also the case where the DPI actually >> determines the chain + steers the flow through the SFC, >> bidirectionally.", there are two separate functions, "determines" and >> "steers". The determination function could be inline or offline. The >> steer function needs to be inline but this function could be provided fo= r >> by the SFC, not necessarily the DPI. >>=20 >> I agree that we should generalise and include both offline and inline >> modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012). >>=20 >> There are cases where offline mode is beneficial. For example, to >> determine a heat map (list of IP addresses) of popular but problematic >> video servers, only one DPI in a major region (can combine with sampling >> technique to reduce load on this DPI) may be adequate, assumed that as >> these videos are wanted by users in other regions as well as they are >> popular. Another advantage is when the DPI is offline (for the right use >> cases), the risk to customer traffic is significantly reduced. >>=20 >> Regards, >> Chuong >> -----Original Message----- >> From: Chris Frederick [mailto:cfrederick@sandvine.com] >> Sent: Friday, 7 February 2014 2:51 AM >> To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >> Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >> sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi Chuong, >> As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps >> not ideal for traffic steering/service chaining; devices that receive >> only an offline copy of a flow cannot themselves redirect/steer that >> flow. So, I wouldn't necessarily agree that the only case where the DPI >> is required to be inline is when it acts as a service function; there is >> also the case where the DPI actually determines the chain + steers the >> flow through the SFC, bidirectionally. I'd further argue that this is >> actually ideal as it obviates some unnecessary signaling overhead. >> Of course, it's possible to deploy offline as you note, with the implici= t >> assumption that the offline DPI would then be signaling back to inline >> devices (either directly or circuitously through a PCRF), perhaps with >> inherent race conditions, etc. >> Thanks, >> /c >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >> Sent: Wednesday, February 05, 2014 9:24 PM >> To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi all, >>=20 >> Would you please consider my thoughts below in the Draft. >>=20 >> 1-The TDF is an inline function which inspects user payload at >> application layer i.e. inspect HTTP headers. With the trend in adoption >> of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seein= g >> 30% etc.), the capability of the TDF to be able to inspect at applicatio= n >> may be diminished. >>=20 >> 2- The use of a DPI function in place of the TDF which may or may have a= n >> interface to the PCRF. This DPI for many traffic cases, do not have to b= e >> deployed in line with customer traffic. It can be deployed in an >> out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent >> information for traffic steering/service chaining actions. The only use >> case where the DPI is required to be in line is when it acts as an >> enforcement Service Function however in this mode, it needs to be treate= d >> as a Service Function, not a traffic steering device. >>=20 >> 3- Section 6.2 current has this paragraph: >> "...Service chain behavior and output should additionally depend on >> actual network conditions. For example, the selection of a video >> compression format could dependent on the actual load of the mobile >> network segment a mobile user is attached to..." >>=20 >> I agreed with paragraph and therefore we could include something to the >> effect of an "actionable intelligence" function which receives inputs >> from sources such as the network and the traffic, derive traffic steerin= g >> decisions and communicate with the service chaining function. >>=20 >> Examples:=20 >> -Receive from the Mobile network the list of user's ip addresses who are >> at the present located in the congested cells so that new video sessions >> are steered to a video optimisation platform. >> - Inspect network traffic (in out-of-path mode) and derive a heat map of >> problematic TCP flows which may be benefited from TCP Optimiser and stee= r >> traffic to this device. >> - Inspect network traffic and derive a heat map of popular content >> remotely located and steer traffic to a local Web Cache so that content >> is made available locally for the current and future users. >>=20 >> Regards, >> Chuong >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com= ] >> Sent: Thursday, 6 February 2014 12:21 PM >> To: Dave Dolson; Martin Stiemerling; >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi Dave, >> Thanks for your comment. We are going to include a Rel.11 TDF paragraph >> in -01. Possibly we will consider 2 sections: most simple case (with >> APN), actual most advanced case (with TDF). >> Regards, >> Walter >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >> Gesendet: Dienstag, 4. Februar 2014 20:23 >> An: Martin Stiemerling; >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Betreff: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Although draft-haeffner-sfc-use-case-mobility-00 describes one >> arrangement of mobility architecture, it neglects to show the role of th= e >> Traffic Detection Function (TDF), also described in the cited 3GPP TS >> 23.203 (Version 12). >>=20 >> I don't want to argue with the use cases, just the implied network >> architecture. >>=20 >> In all of the network diagrams and examples, it should be understood tha= t >> the P-GW is not the only location from which a policy-based service chai= n >> could be initiated; the standard TDF function can also initiate service >> chains selected by policy and traffic type. >>=20 >> Section 2.1 should show an optional TDF element between the P-GW and the >> (S)Gi-LAN. >>=20 >> A TDF communicates with a PCRF using the Sd interface, from which it >> receives Application Detection and Control (ADC) rules, similar to the >> rules deployed to the P-GW via the Gx interface. >>=20 >> Aside from the APN classification scheme mentioned in section 2.3 of the >> draft, ADC rules can cause decisions based on application type (not just >> based on APN or UDP/TCP port classification). >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >> Sent: Wednesday, January 29, 2014 9:46 AM >> To: sfc@ietf.org >> Subject: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi all, >>=20 >> I wanted to raise your attention to the below quoted draft, as it wasn't >> posted to the SFC list. >>=20 >> The draft outlines very well the use cases in mobile networks. >>=20 >> Thanks, >>=20 >> Martin >>=20 >>=20 >> -------- Original Message -------- >> Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >> Date: Tue, 28 Jan 2014 14:26:15 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Service Function Chaining Use Cases in Mobile >> Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >> Pages : 17 >> Date : 2014-01-28 >>=20 >> 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 and framework statements >> of the working group. >>=20 >> 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 ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery, take care of security and privacy or >> support application and business support platforms. 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >> _______________________________________________ >> 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 >>=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 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 From narten@us.ibm.com Fri Feb 7 11:52:59 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0C61ACC87 for ; Fri, 7 Feb 2014 11:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 M8sXrKhYKN6v for ; Fri, 7 Feb 2014 11:52:55 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 310651AC863 for ; Fri, 7 Feb 2014 11:52:55 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 7 Feb 2014 14:52:54 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 7 Feb 2014 14:52:52 -0500 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D2C8438C8045 for ; Fri, 7 Feb 2014 14:52:50 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s17JqoI09568694 for ; Fri, 7 Feb 2014 19:52:50 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s17JqnkV011109 for ; Fri, 7 Feb 2014 14:52:50 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-117-53.mts.ibm.com [9.65.117.53]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s17Jqm2H011005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Feb 2014 14:52:49 -0500 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s17JqkJ1014035; Fri, 7 Feb 2014 14:52:46 -0500 Date: Fri, 07 Feb 2014 14:52:46 -0500 Message-ID: From: Thomas Narten To: Ron Parker In-Reply-To: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14020719-0320-0000-0000-00000268F9D8 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" , Dave Dolson Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:53:00 -0000 One thing that might help is if someone would produce a concrete example where they think reclassification is needed. And does it happen a lot for a flow? (I assume not.) Once at the very beginning? Anytime while packets are flowing? A couple of concrete example might help. We've had this discussion a number of times, but its mostly been in the abstract, which makes it hard to understand how open-ended the requirements for reclassification are. Thomas From linda.dunbar@huawei.com Fri Feb 7 13:49:48 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025A51A04CA for ; Fri, 7 Feb 2014 13:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 VAA6Ie3IDyUK for ; Fri, 7 Feb 2014 13:49:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE9041A04B2 for ; Fri, 7 Feb 2014 13:49:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDJ08943; Fri, 07 Feb 2014 21:49:40 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 21:48:54 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 21:49:39 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 13:49:36 -0800 From: Linda Dunbar To: Ron Parker , Chris Frederick , "Pham, Chuong D" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIAA/cIAgAAHLgD//8NZIA== Date: Fri, 7 Feb 2014 21:49:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:49:48 -0000 -----Original Message----- I feel the group should give much attention to the important topic of how t= o achieve (but not require) directionally correlated chains. Ron [Linda] For flows that need Firewall on both directions, the outgoing direc= tion traffic might go through Firewall Instance #1, and the reverse directi= on traffic go through Firewall Instance #3. If the Firewall instance #1 and= #3 are attached to different Service Function Forwarder nodes, is it consi= dered bi-directional service chain? There are way too many permutations.=20 Maybe SFC WG should let external entity (controller or scheduler) to correl= ate the chains at different directions.=20 My two cents.=20 Linda -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, February 07, 2014 11:56 AM To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson;= Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; s= fc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt I agree that PCRF signaling on a per-flow basis in this context seems impra= ctical; also that consolidating the flow recognition + decision-making enti= ty in a single node reduces the complexity (that's how we do our SFC implem= entation). Fwiw, I have a supplemental comment on the idea of service function reclass= ification, in general. I know the working group has been contemplating this for some time. "Per-Se= rvice Reclassification" is one of the items in the Problem Statement, but t= he problem seems to be framed more in terms of the resource overhead incurr= ed by the classification + sharing of metadata between service functions in= this context (which are valid concerns).=20 However, imo, there is also an inherent assumption of 'flow stickiness' tha= t is important; therefore, service function reclassification should be the = exception rather than the rule, I would think.=20 It's conceivable that permitting service functions to play a role in reclas= sification might be desirable, in certain cases, but once a service chain i= s selected, it should generally not be changed, because modification of the= flow path by a service function within the chain could result in a 'breaki= ng' of the chain or flow.=20 If there is not bidirectional symmetry in the flow and service function ele= ments in the chain can make routing decisions, this is a recipe for problem= s.=20 Each service function in the chain should be agnostic about its upstream an= d downstream nodes. Allowing service functions within a chain to second-gue= ss the ordering can break bidirectional flows.=20 I would think that any service function re-classification must necessarily = be limited in scope viz the output chains it can select; it shouldn't be po= ssible for a downstream service function to be bypassed. Therefore, any re-= classification would need to be constrained to sub-chains that return to th= e original chain, I would think. Thx, /c -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 06, 2014 8:47 PM To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com] Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 linda.dunbar@huawei.com Fri Feb 7 14:14:48 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8E1A021E for ; Fri, 7 Feb 2014 14:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 IKiVbRhiy7O9 for ; Fri, 7 Feb 2014 14:14:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE71A015B for ; Fri, 7 Feb 2014 14:14:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDJ09902; Fri, 07 Feb 2014 22:14:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 22:13:41 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 22:14:42 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 14:14:33 -0800 From: Linda Dunbar To: "Haeffner, Walter, Vodafone DE" , "Dave Dolson" , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAAmPrAA== Date: Fri, 7 Feb 2014 22:14:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:14:48 -0000 Walter, et al,=20 While it is interesting to show all the components of 3GPP for GiLAN, but I= don't think it is necessary to have all of them in the SFC use case draft.= =20 For example, on your Section 2.3 ("The Most common classification scheme"),= it is very confusing to have the Table 1 & Table 2 listing "User name & Pa= ssword". Does it mean that the "User Name & Password" have to associated wi= th data packets? Or to be detected by the Classification nodes?=20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter, Voda= fone DE Sent: Wednesday, February 05, 2014 7:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Fri Feb 7 14:15:24 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C251AD627 for ; Fri, 7 Feb 2014 14:15:24 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x70rOOGg8XuP for ; Fri, 7 Feb 2014 14:15:20 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 553641A015B for ; Fri, 7 Feb 2014 14:15:20 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 14:15:21 -0800 From: Ron Parker To: Linda Dunbar Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDNx7z7hVsl0kmLmsfjrb5gPZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62gD//6MqwIABhlEA//9/W5CAANLNgP//gRYQ Date: Fri, 7 Feb 2014 22:15:19 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" , Dave Dolson Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:15:24 -0000 Linda, For firewall, due to stateful processing, it would be required that both di= rections of the flow be processed by the same instance. In practice, all f= lows to or from the same subscriber would typically need to be handled at t= he same instance. An acceptable requirement to achieve this might be tha= t both directions of the flow are processed by the same SFC classifier.=20 Ron > On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wrot= e: >=20 >=20 >=20 > -----Original Message----- >=20 > I feel the group should give much attention to the important topic of how= to achieve (but not require) directionally correlated chains. >=20 > Ron >=20 > [Linda] For flows that need Firewall on both directions, the outgoing dir= ection traffic might go through Firewall Instance #1, and the reverse direc= tion traffic go through Firewall Instance #3. If the Firewall instance #1 a= nd #3 are attached to different Service Function Forwarder nodes, is it con= sidered bi-directional service chain? There are way too many permutations.= =20 > Maybe SFC WG should let external entity (controller or scheduler) to corr= elate the chains at different directions.=20 >=20 > My two cents.=20 >=20 > Linda >=20 >=20 > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 > Sent: Friday, February 07, 2014 11:56 AM > To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolso= n; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org;= sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > I agree that PCRF signaling on a per-flow basis in this context seems imp= ractical; also that consolidating the flow recognition + decision-making en= tity in a single node reduces the complexity (that's how we do our SFC impl= ementation). > Fwiw, I have a supplemental comment on the idea of service function recla= ssification, in general. > I know the working group has been contemplating this for some time. "Per-= Service Reclassification" is one of the items in the Problem Statement, but= the problem seems to be framed more in terms of the resource overhead incu= rred by the classification + sharing of metadata between service functions = in this context (which are valid concerns).=20 > However, imo, there is also an inherent assumption of 'flow stickiness' t= hat is important; therefore, service function reclassification should be th= e exception rather than the rule, I would think.=20 > It's conceivable that permitting service functions to play a role in recl= assification might be desirable, in certain cases, but once a service chain= is selected, it should generally not be changed, because modification of t= he flow path by a service function within the chain could result in a 'brea= king' of the chain or flow.=20 > If there is not bidirectional symmetry in the flow and service function e= lements in the chain can make routing decisions, this is a recipe for probl= ems.=20 > Each service function in the chain should be agnostic about its upstream = and downstream nodes. Allowing service functions within a chain to second-g= uess the ordering can break bidirectional flows.=20 > I would think that any service function re-classification must necessaril= y be limited in scope viz the output chains it can select; it shouldn't be = possible for a downstream service function to be bypassed. Therefore, any r= e-classification would need to be constrained to sub-chains that return to = the original chain, I would think. Thx, /c >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, February 06, 2014 8:47 PM > To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > The use case of the offline (mirrored feed) DPI interacting with the SFC = is an interesting one. Wrt the inline DPI case, since we've said that an= y service function can reclassify, at first glance it isn't any different t= han any other service function. >=20 > Putting the 2 cases together, do we want to portray the flow recognition = entity separately from the per-flow decision making entity? This is som= ewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there ar= e severe scaling constraints to actually engage the PCRF on a per-flow basi= s. Of course, choosing to portray these as separate entities means that a= protocol needs to be defined between them. By assuming that the flow rec= ognition entity is also the decision making entity (i.e., the policy decisi= on point in some of the drafts), the complexity of the problem is reduced. >=20 > Thoughts? >=20 > Ron >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Thursday, February 06, 2014 6:11 PM > To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chris, >=20 > It depends on how you look at the issue. >=20 > In this comment " there is also the case where the DPI actually determine= s the chain + steers the flow through the SFC, bidirectionally.", there are= two separate functions, "determines" and "steers". The determination funct= ion could be inline or offline. The steer function needs to be inline but t= his function could be provided for by the SFC, not necessarily the DPI.=20 >=20 > I agree that we should generalise and include both offline and inline mod= es as equally valid (as in ITU-T Rec. Y.2770 (11/2012). >=20 > There are cases where offline mode is beneficial. For example, to determi= ne a heat map (list of IP addresses) of popular but problematic video serve= rs, only one DPI in a major region (can combine with sampling technique to = reduce load on this DPI) may be adequate, assumed that as these videos are = wanted by users in other regions as well as they are popular. Another advan= tage is when the DPI is offline (for the right use cases), the risk to cust= omer traffic is significantly reduced. >=20 > Regards, > Chuong > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Friday, 7 February 2014 2:51 AM > To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin St= iemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chuong, > As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps = not ideal for traffic steering/service chaining; devices that receive only = an offline copy of a flow cannot themselves redirect/steer that flow. So, I= wouldn't necessarily agree that the only case where the DPI is required to= be inline is when it acts as a service function; there is also the case wh= ere the DPI actually determines the chain + steers the flow through the SFC= , bidirectionally. I'd further argue that this is actually ideal as it obvi= ates some unnecessary signaling overhead. > Of course, it's possible to deploy offline as you note, with the implicit= assumption that the offline DPI would then be signaling back to inline dev= ices (either directly or circuitously through a PCRF), perhaps with inheren= t race conditions, etc.=20 > Thanks, > /c >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 05, 2014 9:24 PM > To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft= -haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi all, >=20 > Would you please consider my thoughts below in the Draft. >=20 > 1-The TDF is an inline function which inspects user payload at applicatio= n layer i.e. inspect HTTP headers. With the trend in adoption of encryption= (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the= capability of the TDF to be able to inspect at application may be diminish= ed. >=20 > 2- The use of a DPI function in place of the TDF which may or may have an= interface to the PCRF. This DPI for many traffic cases, do not have to be = deployed in line with customer traffic. It can be deployed in an out-of-pat= h fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information fo= r traffic steering/service chaining actions. The only use case where the DP= I is required to be in line is when it acts as an enforcement Service Funct= ion however in this mode, it needs to be treated as a Service Function, not= a traffic steering device. >=20 > 3- Section 6.2 current has this paragraph: > "...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." >=20 > I agreed with paragraph and therefore we could include something to the e= ffect of an "actionable intelligence" function which receives inputs from s= ources such as the network and the traffic, derive traffic steering decisio= ns and communicate with the service chaining function. >=20 > Examples:=20 > -Receive from the Mobile network the list of user's ip addresses who are = at the present located in the congested cells so that new video sessions ar= e steered to a video optimisation platform. > - Inspect network traffic (in out-of-path mode) and derive a heat map of = problematic TCP flows which may be benefited from TCP Optimiser and steer t= raffic to this device. > - Inspect network traffic and derive a heat map of popular content remote= ly located and steer traffic to a local Web Cache so that content is made a= vailable locally for the current and future users. >=20 > Regards, > Chuong >=20 >=20 >=20 > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Thursday, 6 February 2014 12:21 PM > To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility= @tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Dave, > Thanks for your comment. We are going to include a Rel.11 TDF paragraph = in -01. Possibly we will consider 2 sections: most simple case (with APN), = actual most advanced case (with TDF).=20 > Regards, > Walter >=20 > -----Urspr=FCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson > Gesendet: Dienstag, 4. Februar 2014 20:23 > An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org > Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangemen= t of mobility architecture, it neglects to show the role of the Traffic Det= ection Function (TDF), also described in the cited 3GPP TS 23.203 (Version = 12). >=20 > I don't want to argue with the use cases, just the implied network archit= ecture. >=20 > In all of the network diagrams and examples, it should be understood that= the P-GW is not the only location from which a policy-based service chain = could be initiated; the standard TDF function can also initiate service cha= ins selected by policy and traffic type. >=20 > Section 2.1 should show an optional TDF element between the P-GW and the = (S)Gi-LAN. >=20 > A TDF communicates with a PCRF using the Sd interface, from which it rece= ives Application Detection and Control (ADC) rules, similar to the rules de= ployed to the P-GW via the Gx interface. >=20 > Aside from the APN classification scheme mentioned in section 2.3 of the = draft, ADC rules can cause decisions based on application type (not just ba= sed on APN or UDP/TCP port classification). >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, January 29, 2014 9:46 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.t= xt >=20 > Hi all, >=20 > I wanted to raise your attention to the below quoted draft, as it wasn't = posted to the SFC list. >=20 > The draft outlines very well the use cases in mobile networks. >=20 > Thanks, >=20 > Martin >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt > Date: Tue, 28 Jan 2014 14:26:15 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Service Function Chaining Use Cases in Mobile=20 > Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 >=20 > 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 and framework statements > of the working group. >=20 > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > 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 >=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 > _______________________________________________ > 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 ddolson@sandvine.com Fri Feb 7 15:02:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1062E1AD68A for ; Fri, 7 Feb 2014 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 DND0c_rhKfhF for ; Fri, 7 Feb 2014 15:02:02 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1C11AD67C for ; Fri, 7 Feb 2014 15:02:02 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Fri, 7 Feb 2014 18:02:01 -0500 From: Dave Dolson To: Ron Parker , Linda Dunbar Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQgAJzAwCAABGWAIAAip1QgADRuACAACu6AIAAo4cQgABhaQCAAEr6gIAABzCA//+3f1A= Date: Fri, 7 Feb 2014 23:02:00 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:02:06 -0000 It also seems to me that there are many use cases in which both ends of a s= ervice chain (one instance) must be terminated by the same Classifier. Consistent selection of chains is one reason. E.g., picking the same firewa= ll in the example below. In fact, picking a chain that is the exact inverse= with respect to all Service Functions within it. In other cases, the Classifier has some function it needs to do after traff= ic exits the chain. E.g., accounting. And in other cases, the Classifier needs to return the traffic to the conte= xt it was extracted from. E.g., return the traffic to the correct VLAN or V= PN. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Friday, February 07, 2014 5:15 PM To: Linda Dunbar Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Linda, For firewall, due to stateful processing, it would be required that both di= rections of the flow be processed by the same instance. In practice, all f= lows to or from the same subscriber would typically need to be handled at t= he same instance. An acceptable requirement to achieve this might be tha= t both directions of the flow are processed by the same SFC classifier.=20 Ron > On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wrot= e: >=20 >=20 >=20 > -----Original Message----- >=20 > I feel the group should give much attention to the important topic of how= to achieve (but not require) directionally correlated chains. >=20 > Ron >=20 > [Linda] For flows that need Firewall on both directions, the outgoing dir= ection traffic might go through Firewall Instance #1, and the reverse direc= tion traffic go through Firewall Instance #3. If the Firewall instance #1 a= nd #3 are attached to different Service Function Forwarder nodes, is it con= sidered bi-directional service chain? There are way too many permutations.= =20 > Maybe SFC WG should let external entity (controller or scheduler) to corr= elate the chains at different directions.=20 >=20 > My two cents.=20 >=20 > Linda >=20 >=20 > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 > Sent: Friday, February 07, 2014 11:56 AM > To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolso= n; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org;= sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > I agree that PCRF signaling on a per-flow basis in this context seems imp= ractical; also that consolidating the flow recognition + decision-making en= tity in a single node reduces the complexity (that's how we do our SFC impl= ementation). > Fwiw, I have a supplemental comment on the idea of service function recla= ssification, in general. > I know the working group has been contemplating this for some time. "Per-= Service Reclassification" is one of the items in the Problem Statement, but= the problem seems to be framed more in terms of the resource overhead incu= rred by the classification + sharing of metadata between service functions = in this context (which are valid concerns).=20 > However, imo, there is also an inherent assumption of 'flow stickiness' t= hat is important; therefore, service function reclassification should be th= e exception rather than the rule, I would think.=20 > It's conceivable that permitting service functions to play a role in recl= assification might be desirable, in certain cases, but once a service chain= is selected, it should generally not be changed, because modification of t= he flow path by a service function within the chain could result in a 'brea= king' of the chain or flow.=20 > If there is not bidirectional symmetry in the flow and service function e= lements in the chain can make routing decisions, this is a recipe for probl= ems.=20 > Each service function in the chain should be agnostic about its upstream = and downstream nodes. Allowing service functions within a chain to second-g= uess the ordering can break bidirectional flows.=20 > I would think that any service function re-classification must necessaril= y be limited in scope viz the output chains it can select; it shouldn't be = possible for a downstream service function to be bypassed. Therefore, any r= e-classification would need to be constrained to sub-chains that return to = the original chain, I would think. Thx, /c >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, February 06, 2014 8:47 PM > To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > The use case of the offline (mirrored feed) DPI interacting with the SFC = is an interesting one. Wrt the inline DPI case, since we've said that an= y service function can reclassify, at first glance it isn't any different t= han any other service function. >=20 > Putting the 2 cases together, do we want to portray the flow recognition = entity separately from the per-flow decision making entity? This is som= ewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there ar= e severe scaling constraints to actually engage the PCRF on a per-flow basi= s. Of course, choosing to portray these as separate entities means that a= protocol needs to be defined between them. By assuming that the flow rec= ognition entity is also the decision making entity (i.e., the policy decisi= on point in some of the drafts), the complexity of the problem is reduced. >=20 > Thoughts? >=20 > Ron >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Thursday, February 06, 2014 6:11 PM > To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chris, >=20 > It depends on how you look at the issue. >=20 > In this comment " there is also the case where the DPI actually determine= s the chain + steers the flow through the SFC, bidirectionally.", there are= two separate functions, "determines" and "steers". The determination funct= ion could be inline or offline. The steer function needs to be inline but t= his function could be provided for by the SFC, not necessarily the DPI.=20 >=20 > I agree that we should generalise and include both offline and inline mod= es as equally valid (as in ITU-T Rec. Y.2770 (11/2012). >=20 > There are cases where offline mode is beneficial. For example, to determi= ne a heat map (list of IP addresses) of popular but problematic video serve= rs, only one DPI in a major region (can combine with sampling technique to = reduce load on this DPI) may be adequate, assumed that as these videos are = wanted by users in other regions as well as they are popular. Another advan= tage is when the DPI is offline (for the right use cases), the risk to cust= omer traffic is significantly reduced. >=20 > Regards, > Chuong > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Friday, 7 February 2014 2:51 AM > To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin St= iemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chuong, > As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps = not ideal for traffic steering/service chaining; devices that receive only = an offline copy of a flow cannot themselves redirect/steer that flow. So, I= wouldn't necessarily agree that the only case where the DPI is required to= be inline is when it acts as a service function; there is also the case wh= ere the DPI actually determines the chain + steers the flow through the SFC= , bidirectionally. I'd further argue that this is actually ideal as it obvi= ates some unnecessary signaling overhead. > Of course, it's possible to deploy offline as you note, with the implicit= assumption that the offline DPI would then be signaling back to inline dev= ices (either directly or circuitously through a PCRF), perhaps with inheren= t race conditions, etc.=20 > Thanks, > /c >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 05, 2014 9:24 PM > To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft= -haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi all, >=20 > Would you please consider my thoughts below in the Draft. >=20 > 1-The TDF is an inline function which inspects user payload at applicatio= n layer i.e. inspect HTTP headers. With the trend in adoption of encryption= (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the= capability of the TDF to be able to inspect at application may be diminish= ed. >=20 > 2- The use of a DPI function in place of the TDF which may or may have an= interface to the PCRF. This DPI for many traffic cases, do not have to be = deployed in line with customer traffic. It can be deployed in an out-of-pat= h fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information fo= r traffic steering/service chaining actions. The only use case where the DP= I is required to be in line is when it acts as an enforcement Service Funct= ion however in this mode, it needs to be treated as a Service Function, not= a traffic steering device. >=20 > 3- Section 6.2 current has this paragraph: > "...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." >=20 > I agreed with paragraph and therefore we could include something to the e= ffect of an "actionable intelligence" function which receives inputs from s= ources such as the network and the traffic, derive traffic steering decisio= ns and communicate with the service chaining function. >=20 > Examples:=20 > -Receive from the Mobile network the list of user's ip addresses who are = at the present located in the congested cells so that new video sessions ar= e steered to a video optimisation platform. > - Inspect network traffic (in out-of-path mode) and derive a heat map of = problematic TCP flows which may be benefited from TCP Optimiser and steer t= raffic to this device. > - Inspect network traffic and derive a heat map of popular content remote= ly located and steer traffic to a local Web Cache so that content is made a= vailable locally for the current and future users. >=20 > Regards, > Chuong >=20 >=20 >=20 > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Thursday, 6 February 2014 12:21 PM > To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility= @tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Dave, > Thanks for your comment. We are going to include a Rel.11 TDF paragraph = in -01. Possibly we will consider 2 sections: most simple case (with APN), = actual most advanced case (with TDF).=20 > Regards, > Walter >=20 > -----Urspr=FCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson > Gesendet: Dienstag, 4. Februar 2014 20:23 > An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org > Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangemen= t of mobility architecture, it neglects to show the role of the Traffic Det= ection Function (TDF), also described in the cited 3GPP TS 23.203 (Version = 12). >=20 > I don't want to argue with the use cases, just the implied network archit= ecture. >=20 > In all of the network diagrams and examples, it should be understood that= the P-GW is not the only location from which a policy-based service chain = could be initiated; the standard TDF function can also initiate service cha= ins selected by policy and traffic type. >=20 > Section 2.1 should show an optional TDF element between the P-GW and the = (S)Gi-LAN. >=20 > A TDF communicates with a PCRF using the Sd interface, from which it rece= ives Application Detection and Control (ADC) rules, similar to the rules de= ployed to the P-GW via the Gx interface. >=20 > Aside from the APN classification scheme mentioned in section 2.3 of the = draft, ADC rules can cause decisions based on application type (not just ba= sed on APN or UDP/TCP port classification). >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, January 29, 2014 9:46 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.t= xt >=20 > Hi all, >=20 > I wanted to raise your attention to the below quoted draft, as it wasn't = posted to the SFC list. >=20 > The draft outlines very well the use cases in mobile networks. >=20 > Thanks, >=20 > Martin >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt > Date: Tue, 28 Jan 2014 14:26:15 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Service Function Chaining Use Cases in Mobile=20 > Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 >=20 > 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 and framework statements > of the working group. >=20 > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > 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 >=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 > _______________________________________________ > 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 linda.dunbar@huawei.com Fri Feb 7 15:20:14 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB291A0508 for ; Fri, 7 Feb 2014 15:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 oS-OCj7S455w for ; Fri, 7 Feb 2014 15:20:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A27471A0526 for ; Fri, 7 Feb 2014 15:20:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDJ12315; Fri, 07 Feb 2014 23:19:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 23:19:12 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Feb 2014 23:19:57 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 15:19:45 -0800 From: Linda Dunbar To: Dave Dolson , Ron Parker Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIAA/cIAgAAHLgD//8NZIIAAjtKAgAANCwD//3pRIA== Date: Fri, 7 Feb 2014 23:19:45 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.70] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:20:14 -0000 That are all valid cases. In addition, there are stateless firewalls (many = cases if not the majority). IMHO, the directional correlation of service chain should be out of the sco= pe of SFC WG. Let an external controller/scheduler/etc determine the chains= in each direction and the policies for the chain.=20 Linda -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Friday, February 07, 2014 5:02 PM To: Ron Parker; Linda Dunbar Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Martin = Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.= org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt It also seems to me that there are many use cases in which both ends of a s= ervice chain (one instance) must be terminated by the same Classifier. Consistent selection of chains is one reason. E.g., picking the same firewa= ll in the example below. In fact, picking a chain that is the exact inverse= with respect to all Service Functions within it. In other cases, the Classifier has some function it needs to do after traff= ic exits the chain. E.g., accounting. And in other cases, the Classifier needs to return the traffic to the conte= xt it was extracted from. E.g., return the traffic to the correct VLAN or V= PN. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Friday, February 07, 2014 5:15 PM To: Linda Dunbar Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Linda, For firewall, due to stateful processing, it would be required that both di= rections of the flow be processed by the same instance. In practice, all f= lows to or from the same subscriber would typically need to be handled at t= he same instance. An acceptable requirement to achieve this might be tha= t both directions of the flow are processed by the same SFC classifier.=20 Ron > On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wrot= e: >=20 >=20 >=20 > -----Original Message----- >=20 > I feel the group should give much attention to the important topic of how= to achieve (but not require) directionally correlated chains. >=20 > Ron >=20 > [Linda] For flows that need Firewall on both directions, the outgoing dir= ection traffic might go through Firewall Instance #1, and the reverse direc= tion traffic go through Firewall Instance #3. If the Firewall instance #1 a= nd #3 are attached to different Service Function Forwarder nodes, is it con= sidered bi-directional service chain? There are way too many permutations.= =20 > Maybe SFC WG should let external entity (controller or scheduler) to corr= elate the chains at different directions.=20 >=20 > My two cents.=20 >=20 > Linda >=20 >=20 > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 > Sent: Friday, February 07, 2014 11:56 AM > To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolso= n; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org;= sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > I agree that PCRF signaling on a per-flow basis in this context seems imp= ractical; also that consolidating the flow recognition + decision-making en= tity in a single node reduces the complexity (that's how we do our SFC impl= ementation). > Fwiw, I have a supplemental comment on the idea of service function recla= ssification, in general. > I know the working group has been contemplating this for some time. "Per-= Service Reclassification" is one of the items in the Problem Statement, but= the problem seems to be framed more in terms of the resource overhead incu= rred by the classification + sharing of metadata between service functions = in this context (which are valid concerns).=20 > However, imo, there is also an inherent assumption of 'flow stickiness' t= hat is important; therefore, service function reclassification should be th= e exception rather than the rule, I would think.=20 > It's conceivable that permitting service functions to play a role in recl= assification might be desirable, in certain cases, but once a service chain= is selected, it should generally not be changed, because modification of t= he flow path by a service function within the chain could result in a 'brea= king' of the chain or flow.=20 > If there is not bidirectional symmetry in the flow and service function e= lements in the chain can make routing decisions, this is a recipe for probl= ems.=20 > Each service function in the chain should be agnostic about its upstream = and downstream nodes. Allowing service functions within a chain to second-g= uess the ordering can break bidirectional flows.=20 > I would think that any service function re-classification must necessaril= y be limited in scope viz the output chains it can select; it shouldn't be = possible for a downstream service function to be bypassed. Therefore, any r= e-classification would need to be constrained to sub-chains that return to = the original chain, I would think. Thx, /c >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, February 06, 2014 8:47 PM > To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > The use case of the offline (mirrored feed) DPI interacting with the SFC = is an interesting one. Wrt the inline DPI case, since we've said that an= y service function can reclassify, at first glance it isn't any different t= han any other service function. >=20 > Putting the 2 cases together, do we want to portray the flow recognition = entity separately from the per-flow decision making entity? This is som= ewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there ar= e severe scaling constraints to actually engage the PCRF on a per-flow basi= s. Of course, choosing to portray these as separate entities means that a= protocol needs to be defined between them. By assuming that the flow rec= ognition entity is also the decision making entity (i.e., the policy decisi= on point in some of the drafts), the complexity of the problem is reduced. >=20 > Thoughts? >=20 > Ron >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Thursday, February 06, 2014 6:11 PM > To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chris, >=20 > It depends on how you look at the issue. >=20 > In this comment " there is also the case where the DPI actually determine= s the chain + steers the flow through the SFC, bidirectionally.", there are= two separate functions, "determines" and "steers". The determination funct= ion could be inline or offline. The steer function needs to be inline but t= his function could be provided for by the SFC, not necessarily the DPI.=20 >=20 > I agree that we should generalise and include both offline and inline mod= es as equally valid (as in ITU-T Rec. Y.2770 (11/2012). >=20 > There are cases where offline mode is beneficial. For example, to determi= ne a heat map (list of IP addresses) of popular but problematic video serve= rs, only one DPI in a major region (can combine with sampling technique to = reduce load on this DPI) may be adequate, assumed that as these videos are = wanted by users in other regions as well as they are popular. Another advan= tage is when the DPI is offline (for the right use cases), the risk to cust= omer traffic is significantly reduced. >=20 > Regards, > Chuong > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Friday, 7 February 2014 2:51 AM > To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin St= iemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Chuong, > As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps = not ideal for traffic steering/service chaining; devices that receive only = an offline copy of a flow cannot themselves redirect/steer that flow. So, I= wouldn't necessarily agree that the only case where the DPI is required to= be inline is when it acts as a service function; there is also the case wh= ere the DPI actually determines the chain + steers the flow through the SFC= , bidirectionally. I'd further argue that this is actually ideal as it obvi= ates some unnecessary signaling overhead. > Of course, it's possible to deploy offline as you note, with the implicit= assumption that the offline DPI would then be signaling back to inline dev= ices (either directly or circuitously through a PCRF), perhaps with inheren= t race conditions, etc.=20 > Thanks, > /c >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 05, 2014 9:24 PM > To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft= -haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi all, >=20 > Would you please consider my thoughts below in the Draft. >=20 > 1-The TDF is an inline function which inspects user payload at applicatio= n layer i.e. inspect HTTP headers. With the trend in adoption of encryption= (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the= capability of the TDF to be able to inspect at application may be diminish= ed. >=20 > 2- The use of a DPI function in place of the TDF which may or may have an= interface to the PCRF. This DPI for many traffic cases, do not have to be = deployed in line with customer traffic. It can be deployed in an out-of-pat= h fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information fo= r traffic steering/service chaining actions. The only use case where the DP= I is required to be in line is when it acts as an enforcement Service Funct= ion however in this mode, it needs to be treated as a Service Function, not= a traffic steering device. >=20 > 3- Section 6.2 current has this paragraph: > "...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." >=20 > I agreed with paragraph and therefore we could include something to the e= ffect of an "actionable intelligence" function which receives inputs from s= ources such as the network and the traffic, derive traffic steering decisio= ns and communicate with the service chaining function. >=20 > Examples:=20 > -Receive from the Mobile network the list of user's ip addresses who are = at the present located in the congested cells so that new video sessions ar= e steered to a video optimisation platform. > - Inspect network traffic (in out-of-path mode) and derive a heat map of = problematic TCP flows which may be benefited from TCP Optimiser and steer t= raffic to this device. > - Inspect network traffic and derive a heat map of popular content remote= ly located and steer traffic to a local Web Cache so that content is made a= vailable locally for the current and future users. >=20 > Regards, > Chuong >=20 >=20 >=20 > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Thursday, 6 February 2014 12:21 PM > To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility= @tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Hi Dave, > Thanks for your comment. We are going to include a Rel.11 TDF paragraph = in -01. Possibly we will consider 2 sections: most simple case (with APN), = actual most advanced case (with TDF).=20 > Regards, > Walter >=20 > -----Urspr=FCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson > Gesendet: Dienstag, 4. Februar 2014 20:23 > An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org > Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangemen= t of mobility architecture, it neglects to show the role of the Traffic Det= ection Function (TDF), also described in the cited 3GPP TS 23.203 (Version = 12). >=20 > I don't want to argue with the use cases, just the implied network archit= ecture. >=20 > In all of the network diagrams and examples, it should be understood that= the P-GW is not the only location from which a policy-based service chain = could be initiated; the standard TDF function can also initiate service cha= ins selected by policy and traffic type. >=20 > Section 2.1 should show an optional TDF element between the P-GW and the = (S)Gi-LAN. >=20 > A TDF communicates with a PCRF using the Sd interface, from which it rece= ives Application Detection and Control (ADC) rules, similar to the rules de= ployed to the P-GW via the Gx interface. >=20 > Aside from the APN classification scheme mentioned in section 2.3 of the = draft, ADC rules can cause decisions based on application type (not just ba= sed on APN or UDP/TCP port classification). >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, January 29, 2014 9:46 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.t= xt >=20 > Hi all, >=20 > I wanted to raise your attention to the below quoted draft, as it wasn't = posted to the SFC list. >=20 > The draft outlines very well the use cases in mobile networks. >=20 > Thanks, >=20 > Martin >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt > Date: Tue, 28 Jan 2014 14:26:15 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Service Function Chaining Use Cases in Mobile=20 > Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 >=20 > 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 and framework statements > of the working group. >=20 > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > 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 >=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 > _______________________________________________ > 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 Ron_Parker@affirmednetworks.com Fri Feb 7 15:51:58 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8BA1AD79D for ; Fri, 7 Feb 2014 15:51:58 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBWHt2O1710u for ; Fri, 7 Feb 2014 15:51:55 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F51AD739 for ; Fri, 7 Feb 2014 15:51:55 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 15:51:55 -0800 From: Ron Parker To: Linda Dunbar Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDNx7z7hVsl0kmLmsfjrb5gPZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62gD//6MqwIABhlEA//9/W5CAANLNgP//gRYQABJkzwAAAJ6ygP//gt/e Date: Fri, 7 Feb 2014 23:51:54 +0000 Message-ID: <30E120B7-F13E-4150-B209-44977E588E14@affirmednetworks.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" , Dave Dolson Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:51:59 -0000 Linda, to the extent that some classifier implementations could be based on= locally provisioned policy, it is very much within scope how chains can be= correlated. This may impact the yang management model, too.=20 Ron > On Feb 7, 2014, at 6:20 PM, "Linda Dunbar" wrot= e: >=20 > That are all valid cases. In addition, there are stateless firewalls (man= y cases if not the majority). >=20 > IMHO, the directional correlation of service chain should be out of the s= cope of SFC WG. Let an external controller/scheduler/etc determine the chai= ns in each direction and the policies for the chain.=20 >=20 > Linda >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com]=20 > Sent: Friday, February 07, 2014 5:02 PM > To: Ron Parker; Linda Dunbar > Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Marti= n Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@iet= f.org; Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > It also seems to me that there are many use cases in which both ends of a= service chain (one instance) must be terminated by the same Classifier. >=20 > Consistent selection of chains is one reason. E.g., picking the same fire= wall in the example below. In fact, picking a chain that is the exact inver= se with respect to all Service Functions within it. >=20 > In other cases, the Classifier has some function it needs to do after tra= ffic exits the chain. E.g., accounting. >=20 > And in other cases, the Classifier needs to return the traffic to the con= text it was extracted from. E.g., return the traffic to the correct VLAN or= VPN. >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 > Sent: Friday, February 07, 2014 5:15 PM > To: Linda Dunbar > Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org; Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt >=20 > Linda, >=20 > For firewall, due to stateful processing, it would be required that both = directions of the flow be processed by the same instance. In practice, all= flows to or from the same subscriber would typically need to be handled at= the same instance. An acceptable requirement to achieve this might be t= hat both directions of the flow are processed by the same SFC classifier.=20 >=20 > Ron >=20 >=20 >> On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wro= te: >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> I feel the group should give much attention to the important topic of ho= w to achieve (but not require) directionally correlated chains. >>=20 >> Ron >>=20 >> [Linda] For flows that need Firewall on both directions, the outgoing di= rection traffic might go through Firewall Instance #1, and the reverse dire= ction traffic go through Firewall Instance #3. If the Firewall instance #1 = and #3 are attached to different Service Function Forwarder nodes, is it co= nsidered bi-directional service chain? There are way too many permutations.= =20 >> Maybe SFC WG should let external entity (controller or scheduler) to cor= relate the chains at different directions.=20 >>=20 >> My two cents.=20 >>=20 >> Linda >>=20 >>=20 >> -----Original Message----- >> From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 >> Sent: Friday, February 07, 2014 11:56 AM >> To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dols= on; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> I agree that PCRF signaling on a per-flow basis in this context seems im= practical; also that consolidating the flow recognition + decision-making e= ntity in a single node reduces the complexity (that's how we do our SFC imp= lementation). >> Fwiw, I have a supplemental comment on the idea of service function recl= assification, in general. >> I know the working group has been contemplating this for some time. "Per= -Service Reclassification" is one of the items in the Problem Statement, bu= t the problem seems to be framed more in terms of the resource overhead inc= urred by the classification + sharing of metadata between service functions= in this context (which are valid concerns).=20 >> However, imo, there is also an inherent assumption of 'flow stickiness' = that is important; therefore, service function reclassification should be t= he exception rather than the rule, I would think.=20 >> It's conceivable that permitting service functions to play a role in rec= lassification might be desirable, in certain cases, but once a service chai= n is selected, it should generally not be changed, because modification of = the flow path by a service function within the chain could result in a 'bre= aking' of the chain or flow.=20 >> If there is not bidirectional symmetry in the flow and service function = elements in the chain can make routing decisions, this is a recipe for prob= lems.=20 >> Each service function in the chain should be agnostic about its upstream= and downstream nodes. Allowing service functions within a chain to second-= guess the ordering can break bidirectional flows.=20 >> I would think that any service function re-classification must necessari= ly be limited in scope viz the output chains it can select; it shouldn't be= possible for a downstream service function to be bypassed. Therefore, any = re-classification would need to be constrained to sub-chains that return to= the original chain, I would think. Thx, /c >>=20 >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Thursday, February 06, 2014 8:47 PM >> To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave= Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.iet= f.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> The use case of the offline (mirrored feed) DPI interacting with the SFC= is an interesting one. Wrt the inline DPI case, since we've said that a= ny service function can reclassify, at first glance it isn't any different = than any other service function. >>=20 >> Putting the 2 cases together, do we want to portray the flow recognition= entity separately from the per-flow decision making entity? This is so= mewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there a= re severe scaling constraints to actually engage the PCRF on a per-flow bas= is. Of course, choosing to portray these as separate entities means that = a protocol needs to be defined between them. By assuming that the flow re= cognition entity is also the decision making entity (i.e., the policy decis= ion point in some of the drafts), the complexity of the problem is reduced. >>=20 >> Thoughts? >>=20 >> Ron >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >> Sent: Thursday, February 06, 2014 6:11 PM >> To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin = Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.= org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> Hi Chris, >>=20 >> It depends on how you look at the issue. >>=20 >> In this comment " there is also the case where the DPI actually determin= es the chain + steers the flow through the SFC, bidirectionally.", there ar= e two separate functions, "determines" and "steers". The determination func= tion could be inline or offline. The steer function needs to be inline but = this function could be provided for by the SFC, not necessarily the DPI.=20 >>=20 >> I agree that we should generalise and include both offline and inline mo= des as equally valid (as in ITU-T Rec. Y.2770 (11/2012). >>=20 >> There are cases where offline mode is beneficial. For example, to determ= ine a heat map (list of IP addresses) of popular but problematic video serv= ers, only one DPI in a major region (can combine with sampling technique to= reduce load on this DPI) may be adequate, assumed that as these videos are= wanted by users in other regions as well as they are popular. Another adva= ntage is when the DPI is offline (for the right use cases), the risk to cus= tomer traffic is significantly reduced. >>=20 >> Regards, >> Chuong >> -----Original Message----- >> From: Chris Frederick [mailto:cfrederick@sandvine.com] >> Sent: Friday, 7 February 2014 2:51 AM >> To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> Hi Chuong, >> As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps= not ideal for traffic steering/service chaining; devices that receive only= an offline copy of a flow cannot themselves redirect/steer that flow. So, = I wouldn't necessarily agree that the only case where the DPI is required t= o be inline is when it acts as a service function; there is also the case w= here the DPI actually determines the chain + steers the flow through the SF= C, bidirectionally. I'd further argue that this is actually ideal as it obv= iates some unnecessary signaling overhead. >> Of course, it's possible to deploy offline as you note, with the implici= t assumption that the offline DPI would then be signaling back to inline de= vices (either directly or circuitously through a PCRF), perhaps with inhere= nt race conditions, etc.=20 >> Thanks, >> /c >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >> Sent: Wednesday, February 05, 2014 9:24 PM >> To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> Hi all, >>=20 >> Would you please consider my thoughts below in the Draft. >>=20 >> 1-The TDF is an inline function which inspects user payload at applicati= on layer i.e. inspect HTTP headers. With the trend in adoption of encryptio= n (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), th= e capability of the TDF to be able to inspect at application may be diminis= hed. >>=20 >> 2- The use of a DPI function in place of the TDF which may or may have a= n interface to the PCRF. This DPI for many traffic cases, do not have to be= deployed in line with customer traffic. It can be deployed in an out-of-pa= th fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information f= or traffic steering/service chaining actions. The only use case where the D= PI is required to be in line is when it acts as an enforcement Service Func= tion however in this mode, it needs to be treated as a Service Function, no= t a traffic steering device. >>=20 >> 3- Section 6.2 current has this paragraph: >> "...Service chain behavior and output should additionally depend on >> actual network conditions. For example, the selection of a video >> compression format could dependent on the actual load of the mobile >> network segment a mobile user is attached to..." >>=20 >> I agreed with paragraph and therefore we could include something to the = effect of an "actionable intelligence" function which receives inputs from = sources such as the network and the traffic, derive traffic steering decisi= ons and communicate with the service chaining function. >>=20 >> Examples:=20 >> -Receive from the Mobile network the list of user's ip addresses who are= at the present located in the congested cells so that new video sessions a= re steered to a video optimisation platform. >> - Inspect network traffic (in out-of-path mode) and derive a heat map of= problematic TCP flows which may be benefited from TCP Optimiser and steer = traffic to this device. >> - Inspect network traffic and derive a heat map of popular content remot= ely located and steer traffic to a local Web Cache so that content is made = available locally for the current and future users. >>=20 >> Regards, >> Chuong >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com= ] >> Sent: Thursday, 6 February 2014 12:21 PM >> To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobilit= y@tools.ietf.org; sfc@ietf.org >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> Hi Dave, >> Thanks for your comment. We are going to include a Rel.11 TDF paragraph= in -01. Possibly we will consider 2 sections: most simple case (with APN),= actual most advanced case (with TDF).=20 >> Regards, >> Walter >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >> Gesendet: Dienstag, 4. Februar 2014 20:23 >> An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.= org; sfc@ietf.org >> Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt >>=20 >> Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangeme= nt of mobility architecture, it neglects to show the role of the Traffic De= tection Function (TDF), also described in the cited 3GPP TS 23.203 (Version= 12). >>=20 >> I don't want to argue with the use cases, just the implied network archi= tecture. >>=20 >> In all of the network diagrams and examples, it should be understood tha= t the P-GW is not the only location from which a policy-based service chain= could be initiated; the standard TDF function can also initiate service ch= ains selected by policy and traffic type. >>=20 >> Section 2.1 should show an optional TDF element between the P-GW and the= (S)Gi-LAN. >>=20 >> A TDF communicates with a PCRF using the Sd interface, from which it rec= eives Application Detection and Control (ADC) rules, similar to the rules d= eployed to the P-GW via the Gx interface. >>=20 >> Aside from the APN classification scheme mentioned in section 2.3 of the= draft, ADC rules can cause decisions based on application type (not just b= ased on APN or UDP/TCP port classification). >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >> Sent: Wednesday, January 29, 2014 9:46 AM >> To: sfc@ietf.org >> Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.= txt >>=20 >> Hi all, >>=20 >> I wanted to raise your attention to the below quoted draft, as it wasn't= posted to the SFC list. >>=20 >> The draft outlines very well the use cases in mobile networks. >>=20 >> Thanks, >>=20 >> Martin >>=20 >>=20 >> -------- Original Message -------- >> Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >> Date: Tue, 28 Jan 2014 14:26:15 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : Service Function Chaining Use Cases in Mobile=20 >> Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >> Pages : 17 >> Date : 2014-01-28 >>=20 >> 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 and framework statements >> of the working group. >>=20 >> 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 ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery, take care of security and privacy or >> support application and business support platforms. 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp= .ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >> _______________________________________________ >> 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 >>=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 >> _______________________________________________ >> 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 Chuong.D.Pham@team.telstra.com Fri Feb 7 17:54:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D21AD791 for ; Fri, 7 Feb 2014 17:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FiFKlrj7hOE for ; Fri, 7 Feb 2014 17:54:35 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0951ACCEB for ; Fri, 7 Feb 2014 17:54:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,804,1384261200"; d="scan'208";a="171799041" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Feb 2014 12:54:34 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7342"; a="147267776" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Feb 2014 12:54:34 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Sat, 8 Feb 2014 12:54:33 +1100 From: "Pham, Chuong D" To: Linda Dunbar , Dave Dolson , Ron Parker Date: Sat, 8 Feb 2014 12:54:32 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIAA/cIAgAAHLgD//8NZIIAAjtKAgAANCwD//3pRIIAAK74A Message-ID: <5602569641FB314FB4D9AD5659D41B9C29839B3E8C@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 01:54:40 -0000 I think direction correlation aka traffic symmetry is important. I have not= seen many stateless firewall. Both directions of the flows need to travers= e the same firewall. Even with the most basic firewall, TCP flows and UDP p= seudo flows states are maintained in the firewall. The so called stateless = firewall is a special configuration to turn off the need to enforce correct= states, which in a way, defeats the purpose of the firewall. The NAT funct= ion is another service function which needs to see traffic symmetry. There = are service functions such as Parental Control which may not mandate return= ed traffic to go through it but there are also types of PC which require tr= affic symmetry when inspection of the returned traffic is required. I personally think symmetry should be the default case with a configurable = option to turn it off. This will require state replication between multiple= classifiers in a "cluster" of classifiers. Regards, Chuong From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Saturday, 8 February 2014 10:20 AM To: Dave Dolson; Ron Parker Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Martin = Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.= org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt That are all valid cases. In addition, there are stateless firewalls (many = cases if not the majority). IMHO, the directional correlation of service chain should be out of the sco= pe of SFC WG. Let an external controller/scheduler/etc determine the chains= in each direction and the policies for the chain. Linda -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Friday, February 07, 2014 5:02 PM To: Ron Parker; Linda Dunbar Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Martin = Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.= org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt It also seems to me that there are many use cases in which both ends of a s= ervice chain (one instance) must be terminated by the same Classifier. Consistent selection of chains is one reason. E.g., picking the same firewa= ll in the example below. In fact, picking a chain that is the exact inverse= with respect to all Service Functions within it. In other cases, the Classifier has some function it needs to do after traff= ic exits the chain. E.g., accounting. And in other cases, the Classifier needs to return the traffic to the conte= xt it was extracted from. E.g., return the traffic to the correct VLAN or V= PN. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Friday, February 07, 2014 5:15 PM To: Linda Dunbar Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org; Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Linda, For firewall, due to stateful processing, it would be required that both di= rections of the flow be processed by the same instance. In practice, all f= lows to or from the same subscriber would typically need to be handled at t= he same instance. An acceptable requirement to achieve this might be tha= t both directions of the flow are processed by the same SFC classifier. Ron > On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wrot= e: > > > > -----Original Message----- > > I feel the group should give much attention to the important topic of how= to achieve (but not require) directionally correlated chains. > > Ron > > [Linda] For flows that need Firewall on both directions, the outgoing dir= ection traffic might go through Firewall Instance #1, and the reverse direc= tion traffic go through Firewall Instance #3. If the Firewall instance #1 a= nd #3 are attached to different Service Function Forwarder nodes, is it con= sidered bi-directional service chain? There are way too many permutations. > Maybe SFC WG should let external entity (controller or scheduler) to corr= elate the chains at different directions. > > My two cents. > > Linda > > > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Friday, February 07, 2014 11:56 AM > To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolso= n; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org;= sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > I agree that PCRF signaling on a per-flow basis in this context seems imp= ractical; also that consolidating the flow recognition + decision-making en= tity in a single node reduces the complexity (that's how we do our SFC impl= ementation). > Fwiw, I have a supplemental comment on the idea of service function recla= ssification, in general. > I know the working group has been contemplating this for some time. "Per-= Service Reclassification" is one of the items in the Problem Statement, but= the problem seems to be framed more in terms of the resource overhead incu= rred by the classification + sharing of metadata between service functions = in this context (which are valid concerns). > However, imo, there is also an inherent assumption of 'flow stickiness' t= hat is important; therefore, service function reclassification should be th= e exception rather than the rule, I would think. > It's conceivable that permitting service functions to play a role in recl= assification might be desirable, in certain cases, but once a service chain= is selected, it should generally not be changed, because modification of t= he flow path by a service function within the chain could result in a 'brea= king' of the chain or flow. > If there is not bidirectional symmetry in the flow and service function e= lements in the chain can make routing decisions, this is a recipe for probl= ems. > Each service function in the chain should be agnostic about its upstream = and downstream nodes. Allowing service functions within a chain to second-g= uess the ordering can break bidirectional flows. > I would think that any service function re-classification must necessaril= y be limited in scope viz the output chains it can select; it shouldn't be = possible for a downstream service function to be bypassed. Therefore, any r= e-classification would need to be constrained to sub-chains that return to = the original chain, I would think. Thx, /c > > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, February 06, 2014 8:47 PM > To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > The use case of the offline (mirrored feed) DPI interacting with the SFC = is an interesting one. Wrt the inline DPI case, since we've said that an= y service function can reclassify, at first glance it isn't any different t= han any other service function. > > Putting the 2 cases together, do we want to portray the flow recognition = entity separately from the per-flow decision making entity? This is som= ewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there ar= e severe scaling constraints to actually engage the PCRF on a per-flow basi= s. Of course, choosing to portray these as separate entities means that a= protocol needs to be defined between them. By assuming that the flow rec= ognition entity is also the decision making entity (i.e., the policy decisi= on point in some of the drafts), the complexity of the problem is reduced. > > Thoughts? > > Ron > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Thursday, February 06, 2014 6:11 PM > To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > Hi Chris, > > It depends on how you look at the issue. > > In this comment " there is also the case where the DPI actually determine= s the chain + steers the flow through the SFC, bidirectionally.", there are= two separate functions, "determines" and "steers". The determination funct= ion could be inline or offline. The steer function needs to be inline but t= his function could be provided for by the SFC, not necessarily the DPI. > > I agree that we should generalise and include both offline and inline mod= es as equally valid (as in ITU-T Rec. Y.2770 (11/2012). > > There are cases where offline mode is beneficial. For example, to determi= ne a heat map (list of IP addresses) of popular but problematic video serve= rs, only one DPI in a major region (can combine with sampling technique to = reduce load on this DPI) may be adequate, assumed that as these videos are = wanted by users in other regions as well as they are popular. Another advan= tage is when the DPI is offline (for the right use cases), the risk to cust= omer traffic is significantly reduced. > > Regards, > Chuong > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Friday, 7 February 2014 2:51 AM > To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin St= iemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > Hi Chuong, > As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps = not ideal for traffic steering/service chaining; devices that receive only = an offline copy of a flow cannot themselves redirect/steer that flow. So, I= wouldn't necessarily agree that the only case where the DPI is required to= be inline is when it acts as a service function; there is also the case wh= ere the DPI actually determines the chain + steers the flow through the SFC= , bidirectionally. I'd further argue that this is actually ideal as it obvi= ates some unnecessary signaling overhead. > Of course, it's possible to deploy offline as you note, with the implicit= assumption that the offline DPI would then be signaling back to inline dev= ices (either directly or circuitously through a PCRF), perhaps with inheren= t race conditions, etc. > Thanks, > /c > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 05, 2014 9:24 PM > To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft= -haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > Hi all, > > Would you please consider my thoughts below in the Draft. > > 1-The TDF is an inline function which inspects user payload at applicatio= n layer i.e. inspect HTTP headers. With the trend in adoption of encryption= (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the= capability of the TDF to be able to inspect at application may be diminish= ed. > > 2- The use of a DPI function in place of the TDF which may or may have an= interface to the PCRF. This DPI for many traffic cases, do not have to be = deployed in line with customer traffic. It can be deployed in an out-of-pat= h fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information fo= r traffic steering/service chaining actions. The only use case where the DP= I is required to be in line is when it acts as an enforcement Service Funct= ion however in this mode, it needs to be treated as a Service Function, not= a traffic steering device. > > 3- Section 6.2 current has this paragraph: > "...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." > > I agreed with paragraph and therefore we could include something to the e= ffect of an "actionable intelligence" function which receives inputs from s= ources such as the network and the traffic, derive traffic steering decisio= ns and communicate with the service chaining function. > > Examples: > -Receive from the Mobile network the list of user's ip addresses who are = at the present located in the congested cells so that new video sessions ar= e steered to a video optimisation platform. > - Inspect network traffic (in out-of-path mode) and derive a heat map of = problematic TCP flows which may be benefited from TCP Optimiser and steer t= raffic to this device. > - Inspect network traffic and derive a heat map of popular content remote= ly located and steer traffic to a local Web Cache so that content is made a= vailable locally for the current and future users. > > Regards, > Chuong > > > > -----Original Message----- > From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] > Sent: Thursday, 6 February 2014 12:21 PM > To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility= @tools.ietf.org; sfc@ietf.org > Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > Hi Dave, > Thanks for your comment. We are going to include a Rel.11 TDF paragraph = in -01. Possibly we will consider 2 sections: most simple case (with APN), = actual most advanced case (with TDF). > Regards, > Walter > > -----Urspr=FCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson > Gesendet: Dienstag, 4. Februar 2014 20:23 > An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org > Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt > > Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangemen= t of mobility architecture, it neglects to show the role of the Traffic Det= ection Function (TDF), also described in the cited 3GPP TS 23.203 (Version = 12). > > I don't want to argue with the use cases, just the implied network archit= ecture. > > In all of the network diagrams and examples, it should be understood that= the P-GW is not the only location from which a policy-based service chain = could be initiated; the standard TDF function can also initiate service cha= ins selected by policy and traffic type. > > Section 2.1 should show an optional TDF element between the P-GW and the = (S)Gi-LAN. > > A TDF communicates with a PCRF using the Sd interface, from which it rece= ives Application Detection and Control (ADC) rules, similar to the rules de= ployed to the P-GW via the Gx interface. > > Aside from the APN classification scheme mentioned in section 2.3 of the = draft, ADC rules can cause decisions based on application type (not just ba= sed on APN or UDP/TCP port classification). > > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, January 29, 2014 9:46 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.t= xt > > Hi all, > > I wanted to raise your attention to the below quoted draft, as it wasn't = posted to the SFC list. > > The draft outlines very well the use cases in mobile networks. > > Thanks, > > Martin > > > -------- Original Message -------- > Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt > Date: Tue, 28 Jan 2014 14:26:15 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Service Function Chaining Use Cases in Mobile > Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > > 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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > 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 S.Majee@f5.com Fri Feb 7 17:51:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6841AD8D8 for ; Fri, 7 Feb 2014 17:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.536 X-Spam-Level: X-Spam-Status: No, score=-7.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 YJQO9OgE__rp for ; Fri, 7 Feb 2014 17:51:51 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9381AD603 for ; Fri, 7 Feb 2014 17:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1391824312; x=1423360312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BBoJvJ41X0yn28wcuR5OGJX/504zc8o6XON9sXp4eq4=; b=LvtgoxVQDZSb8zZANJKftqgrU5F2ykRnqU1wVVkp0i7yXmyP23msRO1m GvAOrNl7Hk2FtuhiA9tI8AHMLmIDXx3Bd9yTIaE/c90QG5Efl2DcYgcrs MS2m3da/7m7SPejq+DzFRqO5UqT6QKsLVBkES0Y5zcrLU738WzrNzu9B2 o=; X-IronPort-AV: E=Sophos;i="4.95,804,1384300800"; d="scan'208";a="99804410" X-IPAS-Result: AqMEAEeN9VLAqArr/2dsb2JhbABZg0RXvnSBIHSCJQEBAQECAQEBAWICBwsFBwQCAQgNBAECAQEBAQodBycLFAMGCAIEAQ0FCAGHdBXMSxeOEBUnLAUHBoMegRQEiRGQTIU+hXGIbYFoQg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 08 Feb 2014 01:51:48 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 17:51:47 -0800 From: Sumandra Majee To: Ron Parker , Linda Dunbar Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDb17RMqROTSky5SpNRfFzsdZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIAA/cIAgAAHLgCAAEr6gIAABzGAgAANCwCAAAT1gIAACPwA//+bUBg= Date: Sat, 8 Feb 2014 01:51:46 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098849F9967@SEAEMBX01.olympus.F5Net.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A0BE@dfweml701-chm.china.huawei.com> , <4A95BA014132FF49AE685FAB4B9F17F645C7A1B0@dfweml701-chm.china.huawei.com>, <30E120B7-F13E-4150-B209-44977E588E14@affirmednetworks.com> In-Reply-To: <30E120B7-F13E-4150-B209-44977E588E14@affirmednetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 07 Feb 2014 17:59:46 -0800 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Chris Frederick , Martin Stiemerling , "Haeffner, Walter, Vodafone DE" , "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" , "Pham, Chuong D" , Dave Dolson Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 01:51:55 -0000 Most current implementation of load balancer, firewall or steering devices= do require both directions of a given flow be processed at the same instan= ce. However this is forced at network level, making sure that default route= points back to the same device or by nating. =0A= =0A= However it has performance penalty and modern data center has been designed= to bypass processing device on the return path. =0A= =0A= I think this WG has to consider both scenarios but it should not be mandati= ng one or other. =0A= =0A= Sideband channel e.g. ICAP is another consideration. Interestingly ICAP doe= s allow a steering device to pick a portion of a flow (think http transacti= on) and select service endpoint for that portion. In this case the the flow= path is a mix of both.=0A= =0A= Sumandra=0A= ________________________________________=0A= From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]=0A= Sent: Friday, February 07, 2014 3:51 PM=0A= To: Linda Dunbar=0A= Cc: sfc@ietf.org; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; Chri= s Frederick; Martin Stiemerling; Haeffner, Walter, Vodafone DE; Jeffrey Nap= per (jenapper) (jenapper@cisco.com); Pham, Chuong D; Dave Dolson=0A= Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt=0A= =0A= Linda, to the extent that some classifier implementations could be based on= locally provisioned policy, it is very much within scope how chains can be= correlated. This may impact the yang management model, too.=0A= =0A= Ron=0A= =0A= > On Feb 7, 2014, at 6:20 PM, "Linda Dunbar" wrot= e:=0A= >=0A= > That are all valid cases. In addition, there are stateless firewalls (man= y cases if not the majority).=0A= >=0A= > IMHO, the directional correlation of service chain should be out of the s= cope of SFC WG. Let an external controller/scheduler/etc determine the chai= ns in each direction and the policies for the chain.=0A= >=0A= > Linda=0A= >=0A= > -----Original Message-----=0A= > From: Dave Dolson [mailto:ddolson@sandvine.com]=0A= > Sent: Friday, February 07, 2014 5:02 PM=0A= > To: Ron Parker; Linda Dunbar=0A= > Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Marti= n Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@iet= f.org; Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= > Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt=0A= >=0A= > It also seems to me that there are many use cases in which both ends of a= service chain (one instance) must be terminated by the same Classifier.=0A= >=0A= > Consistent selection of chains is one reason. E.g., picking the same fire= wall in the example below. In fact, picking a chain that is the exact inver= se with respect to all Service Functions within it.=0A= >=0A= > In other cases, the Classifier has some function it needs to do after tra= ffic exits the chain. E.g., accounting.=0A= >=0A= > And in other cases, the Classifier needs to return the traffic to the con= text it was extracted from. E.g., return the traffic to the correct VLAN or= VPN.=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= > Sent: Friday, February 07, 2014 5:15 PM=0A= > To: Linda Dunbar=0A= > Cc: Chris Frederick; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave = Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf= .org; sfc@ietf.org; Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= > Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt=0A= >=0A= > Linda,=0A= >=0A= > For firewall, due to stateful processing, it would be required that both = directions of the flow be processed by the same instance. In practice, all= flows to or from the same subscriber would typically need to be handled at= the same instance. An acceptable requirement to achieve this might be t= hat both directions of the flow are processed by the same SFC classifier.= =0A= >=0A= > Ron=0A= >=0A= >=0A= >> On Feb 7, 2014, at 4:49 PM, "Linda Dunbar" wro= te:=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >>=0A= >> I feel the group should give much attention to the important topic of ho= w to achieve (but not require) directionally correlated chains.=0A= >>=0A= >> Ron=0A= >>=0A= >> [Linda] For flows that need Firewall on both directions, the outgoing di= rection traffic might go through Firewall Instance #1, and the reverse dire= ction traffic go through Firewall Instance #3. If the Firewall instance #1 = and #3 are attached to different Service Function Forwarder nodes, is it co= nsidered bi-directional service chain? There are way too many permutations.= =0A= >> Maybe SFC WG should let external entity (controller or scheduler) to cor= relate the chains at different directions.=0A= >>=0A= >> My two cents.=0A= >>=0A= >> Linda=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Chris Frederick [mailto:cfrederick@sandvine.com]=0A= >> Sent: Friday, February 07, 2014 11:56 AM=0A= >> To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dols= on; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> I agree that PCRF signaling on a per-flow basis in this context seems im= practical; also that consolidating the flow recognition + decision-making e= ntity in a single node reduces the complexity (that's how we do our SFC imp= lementation).=0A= >> Fwiw, I have a supplemental comment on the idea of service function recl= assification, in general.=0A= >> I know the working group has been contemplating this for some time. "Per= -Service Reclassification" is one of the items in the Problem Statement, bu= t the problem seems to be framed more in terms of the resource overhead inc= urred by the classification + sharing of metadata between service functions= in this context (which are valid concerns).=0A= >> However, imo, there is also an inherent assumption of 'flow stickiness' = that is important; therefore, service function reclassification should be t= he exception rather than the rule, I would think.=0A= >> It's conceivable that permitting service functions to play a role in rec= lassification might be desirable, in certain cases, but once a service chai= n is selected, it should generally not be changed, because modification of = the flow path by a service function within the chain could result in a 'bre= aking' of the chain or flow.=0A= >> If there is not bidirectional symmetry in the flow and service function = elements in the chain can make routing decisions, this is a recipe for prob= lems.=0A= >> Each service function in the chain should be agnostic about its upstream= and downstream nodes. Allowing service functions within a chain to second-= guess the ordering can break bidirectional flows.=0A= >> I would think that any service function re-classification must necessari= ly be limited in scope viz the output chains it can select; it shouldn't be= possible for a downstream service function to be bypassed. Therefore, any = re-classification would need to be constrained to sub-chains that return to= the original chain, I would think. Thx, /c=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= >> Sent: Thursday, February 06, 2014 8:47 PM=0A= >> To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave= Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.iet= f.org; sfc@ietf.org=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> The use case of the offline (mirrored feed) DPI interacting with the SFC= is an interesting one. Wrt the inline DPI case, since we've said that a= ny service function can reclassify, at first glance it isn't any different = than any other service function.=0A= >>=0A= >> Putting the 2 cases together, do we want to portray the flow recognition= entity separately from the per-flow decision making entity? This is so= mewhat analogous to the 3gpp PCEF/PCRF split, although in practice, there a= re severe scaling constraints to actually engage the PCRF on a per-flow bas= is. Of course, choosing to portray these as separate entities means that = a protocol needs to be defined between them. By assuming that the flow re= cognition entity is also the decision making entity (i.e., the policy decis= ion point in some of the drafts), the complexity of the problem is reduced.= =0A= >>=0A= >> Thoughts?=0A= >>=0A= >> Ron=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D=0A= >> Sent: Thursday, February 06, 2014 6:11 PM=0A= >> To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin = Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.= org=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> Hi Chris,=0A= >>=0A= >> It depends on how you look at the issue.=0A= >>=0A= >> In this comment " there is also the case where the DPI actually determin= es the chain + steers the flow through the SFC, bidirectionally.", there ar= e two separate functions, "determines" and "steers". The determination func= tion could be inline or offline. The steer function needs to be inline but = this function could be provided for by the SFC, not necessarily the DPI.=0A= >>=0A= >> I agree that we should generalise and include both offline and inline mo= des as equally valid (as in ITU-T Rec. Y.2770 (11/2012).=0A= >>=0A= >> There are cases where offline mode is beneficial. For example, to determ= ine a heat map (list of IP addresses) of popular but problematic video serv= ers, only one DPI in a major region (can combine with sampling technique to= reduce load on this DPI) may be adequate, assumed that as these videos are= wanted by users in other regions as well as they are popular. Another adva= ntage is when the DPI is offline (for the right use cases), the risk to cus= tomer traffic is significantly reduced.=0A= >>=0A= >> Regards,=0A= >> Chuong=0A= >> -----Original Message-----=0A= >> From: Chris Frederick [mailto:cfrederick@sandvine.com]=0A= >> Sent: Friday, 7 February 2014 2:51 AM=0A= >> To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin S= tiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.o= rg=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> Hi Chuong,=0A= >> As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps= not ideal for traffic steering/service chaining; devices that receive only= an offline copy of a flow cannot themselves redirect/steer that flow. So, = I wouldn't necessarily agree that the only case where the DPI is required t= o be inline is when it acts as a service function; there is also the case w= here the DPI actually determines the chain + steers the flow through the SF= C, bidirectionally. I'd further argue that this is actually ideal as it obv= iates some unnecessary signaling overhead.=0A= >> Of course, it's possible to deploy offline as you note, with the implici= t assumption that the offline DPI would then be signaling back to inline de= vices (either directly or circuitously through a PCRF), perhaps with inhere= nt race conditions, etc.=0A= >> Thanks,=0A= >> /c=0A= >>=0A= >> -----Original Message-----=0A= >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D=0A= >> Sent: Wednesday, February 05, 2014 9:24 PM=0A= >> To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> Hi all,=0A= >>=0A= >> Would you please consider my thoughts below in the Draft.=0A= >>=0A= >> 1-The TDF is an inline function which inspects user payload at applicati= on layer i.e. inspect HTTP headers. With the trend in adoption of encryptio= n (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), th= e capability of the TDF to be able to inspect at application may be diminis= hed.=0A= >>=0A= >> 2- The use of a DPI function in place of the TDF which may or may have a= n interface to the PCRF. This DPI for many traffic cases, do not have to be= deployed in line with customer traffic. It can be deployed in an out-of-pa= th fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information f= or traffic steering/service chaining actions. The only use case where the D= PI is required to be in line is when it acts as an enforcement Service Func= tion however in this mode, it needs to be treated as a Service Function, no= t a traffic steering device.=0A= >>=0A= >> 3- Section 6.2 current has this paragraph:=0A= >> "...Service chain behavior and output should additionally depend on=0A= >> actual network conditions. For example, the selection of a video=0A= >> compression format could dependent on the actual load of the mobile=0A= >> network segment a mobile user is attached to..."=0A= >>=0A= >> I agreed with paragraph and therefore we could include something to the = effect of an "actionable intelligence" function which receives inputs from = sources such as the network and the traffic, derive traffic steering decisi= ons and communicate with the service chaining function.=0A= >>=0A= >> Examples:=0A= >> -Receive from the Mobile network the list of user's ip addresses who are= at the present located in the congested cells so that new video sessions a= re steered to a video optimisation platform.=0A= >> - Inspect network traffic (in out-of-path mode) and derive a heat map of= problematic TCP flows which may be benefited from TCP Optimiser and steer = traffic to this device.=0A= >> - Inspect network traffic and derive a heat map of popular content remot= ely located and steer traffic to a local Web Cache so that content is made = available locally for the current and future users.=0A= >>=0A= >> Regards,=0A= >> Chuong=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com= ]=0A= >> Sent: Thursday, 6 February 2014 12:21 PM=0A= >> To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobilit= y@tools.ietf.org; sfc@ietf.org=0A= >> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com)=0A= >> Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> Hi Dave,=0A= >> Thanks for your comment. We are going to include a Rel.11 TDF paragraph= in -01. Possibly we will consider 2 sections: most simple case (with APN),= actual most advanced case (with TDF).=0A= >> Regards,=0A= >> Walter=0A= >>=0A= >> -----Urspr=FCngliche Nachricht-----=0A= >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson=0A= >> Gesendet: Dienstag, 4. Februar 2014 20:23=0A= >> An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.= org; sfc@ietf.org=0A= >> Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility= -00.txt=0A= >>=0A= >> Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangeme= nt of mobility architecture, it neglects to show the role of the Traffic De= tection Function (TDF), also described in the cited 3GPP TS 23.203 (Version= 12).=0A= >>=0A= >> I don't want to argue with the use cases, just the implied network archi= tecture.=0A= >>=0A= >> In all of the network diagrams and examples, it should be understood tha= t the P-GW is not the only location from which a policy-based service chain= could be initiated; the standard TDF function can also initiate service ch= ains selected by policy and traffic type.=0A= >>=0A= >> Section 2.1 should show an optional TDF element between the P-GW and the= (S)Gi-LAN.=0A= >>=0A= >> A TDF communicates with a PCRF using the Sd interface, from which it rec= eives Application Detection and Control (ADC) rules, similar to the rules d= eployed to the P-GW via the Gx interface.=0A= >>=0A= >> Aside from the APN classification scheme mentioned in section 2.3 of the= draft, ADC rules can cause decisions based on application type (not just b= ased on APN or UDP/TCP port classification).=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling= =0A= >> Sent: Wednesday, January 29, 2014 9:46 AM=0A= >> To: sfc@ietf.org=0A= >> Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.= txt=0A= >>=0A= >> Hi all,=0A= >>=0A= >> I wanted to raise your attention to the below quoted draft, as it wasn't= posted to the SFC list.=0A= >>=0A= >> The draft outlines very well the use cases in mobile networks.=0A= >>=0A= >> Thanks,=0A= >>=0A= >> Martin=0A= >>=0A= >>=0A= >> -------- Original Message --------=0A= >> Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt=0A= >> Date: Tue, 28 Jan 2014 14:26:15 -0800=0A= >> From: internet-drafts@ietf.org=0A= >> Reply-To: internet-drafts@ietf.org=0A= >> To: i-d-announce@ietf.org=0A= >>=0A= >>=0A= >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories.=0A= >>=0A= >>=0A= >> Title : Service Function Chaining Use Cases in Mobile= =0A= >> Networks=0A= >> Authors : Walter Haeffner=0A= >> Jeffrey Napper=0A= >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt=0A= >> Pages : 17=0A= >> Date : 2014-01-28=0A= >>=0A= >> Abstract:=0A= >> This document provides some exemplary use cases for service function= =0A= >> chaining in mobile service provider networks. The objective of this= =0A= >> draft is not to cover all conceivable service chains in detail.=0A= >> Rather, the intention is to localize and explain the application=0A= >> domain of service chaining within mobile networks as far as it is=0A= >> required to complement the problem statement and framework statements= =0A= >> of the working group.=0A= >>=0A= >> Service function chains typically reside in a LAN segment which links= =0A= >> the mobile access network to the actual application platforms located= =0A= >> in the carrier's datacenters or somewhere else in the Internet.=0A= >> Service function chains ensure a fair distribution of network=0A= >> resources according to agreed service policies, enhance the=0A= >> performance of service delivery, take care of security and privacy or= =0A= >> support application and business support platforms. General=0A= >> considerations and specific use cases are presented in this document= =0A= >> to demonstrate the different technical requirements of these goals=0A= >> for service function chaining in mobile service provider networks.=0A= >>=0A= >>=0A= >> The IETF datatracker status page for this draft is:=0A= >> https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/= =0A= >>=0A= >> There's also a htmlized version available at:=0A= >> http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00=0A= >>=0A= >>=0A= >> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org.= =0A= >>=0A= >> Internet-Drafts are also available by anonymous FTP at:=0A= >> ftp://ftp.ietf.org/internet-drafts/=0A= >>=0A= >> _______________________________________________=0A= >> I-D-Announce mailing list=0A= >> I-D-Announce@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/i-d-announce=0A= >> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp= .ietf.org/ietf/1shadow-sites.txt=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= From Chuong.D.Pham@team.telstra.com Fri Feb 7 18:06:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1861AD935 for ; Fri, 7 Feb 2014 18:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eInAbdL4ZtSp for ; Fri, 7 Feb 2014 18:06:50 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFD1ACCEB for ; Fri, 7 Feb 2014 18:06:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,804,1384261200"; d="scan'208";a="171799880" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Feb 2014 13:06:49 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7342"; a="147269425" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Feb 2014 13:06:49 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sat, 8 Feb 2014 13:06:48 +1100 From: "Pham, Chuong D" To: Chris Frederick , Ron Parker , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Date: Sat, 8 Feb 2014 13:06:47 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDN1aUaggCMCUS7T9nUlmVBtJqlWjnQgAJzAwCAABGWAIAAip1QgADRuACAACu6AIAAo4cQgACddvA= Message-ID: <5602569641FB314FB4D9AD5659D41B9C29839B3E8D@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18883D95@wtl-exchp-2.sandvine.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 02:06:53 -0000 The option to have separation of flow recognition i.e. an out-of-path/inlin= e DPI/TDF etc. from flow decision i.e. an OpenFlow controller and flow stee= ring i.e. an OpenFlow switch or a normal switch with API or a DPI, allows f= or flexibility i.e. combining multiple flow recognition mechanisms to input= into a common flow controller. I think the DPI is not a typical example of= what a SFC should look like. It is more of a stand-alone service function = which capability to steer traffic. With encryption, a lot of traffic cannot= be inspected at the application layer and this would severely affect how t= he DPI works which in turn, will affect how the "black box" perform the fun= ction of a all-in-one-box SFC. If the two functions are separate then we co= uld use different methods for flow recognition while retaining the flow ste= ering mechanism intact, or via versa. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com] Sent: Saturday, 8 February 2014 3:56 AM To: Ron Parker; Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson;= Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; s= fc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt I agree that PCRF signaling on a per-flow basis in this context seems impra= ctical; also that consolidating the flow recognition + decision-making enti= ty in a single node reduces the complexity (that's how we do our SFC implem= entation). Fwiw, I have a supplemental comment on the idea of service function reclass= ification, in general. I know the working group has been contemplating this for some time. "Per-Se= rvice Reclassification" is one of the items in the Problem Statement, but t= he problem seems to be framed more in terms of the resource overhead incurr= ed by the classification + sharing of metadata between service functions in= this context (which are valid concerns). However, imo, there is also an inherent assumption of 'flow stickiness' tha= t is important; therefore, service function reclassification should be the = exception rather than the rule, I would think. It's conceivable that permitting service functions to play a role in reclas= sification might be desirable, in certain cases, but once a service chain i= s selected, it should generally not be changed, because modification of the= flow path by a service function within the chain could result in a 'breaki= ng' of the chain or flow. If there is not bidirectional symmetry in the flow and service function ele= ments in the chain can make routing decisions, this is a recipe for problem= s. Each service function in the chain should be agnostic about its upstream an= d downstream nodes. Allowing service functions within a chain to second-gue= ss the ordering can break bidirectional flows. I would think that any service function re-classification must necessarily = be limited in scope viz the output chains it can select; it shouldn't be po= ssible for a downstream service function to be bypassed. Therefore, any re-= classification would need to be constrained to sub-chains that return to th= e original chain, I would think. Thx, /c -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 06, 2014 8:47 PM To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI. I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com] Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc. Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples: -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF). Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 Chuong.D.Pham@team.telstra.com Fri Feb 7 18:59:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8A1ADBCC for ; Fri, 7 Feb 2014 18:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntDL33XS1Tbk for ; Fri, 7 Feb 2014 18:59:26 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6702E1AD945 for ; Fri, 7 Feb 2014 18:59:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,804,1384261200"; d="scan'208";a="171802751" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Feb 2014 13:59:22 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7342"; a="204330589" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 08 Feb 2014 13:59:23 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sat, 8 Feb 2014 13:59:22 +1100 From: "Pham, Chuong D" To: Ron Parker , Chris Frederick , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Date: Sat, 8 Feb 2014 13:59:21 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDNx7z7hVsl0kmLmsfjrb5gPZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62gD//6MqwIABpmxA Message-ID: <5602569641FB314FB4D9AD5659D41B9C29839B3E9B@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 02:59:28 -0000 Hi Ron,=20 In my comment I just wanted to point out that there is an option to deploy = an actionable intelligence box in an off-line mode (it is a DPI in this dis= cussion), in respond to Chris's suggestion about an TDF function to be plac= ed in-line to recognise application flows (the TDF is simply a DPI with Sd = interface with the PCRF). My point was that to "recognise traffic to be ste= ered", an offline DPI is a valid source of inputs into the steering decisio= n.=20 I am not sure a protocol is needed to be developed. In our current work, we= use SOAP interface between the offline actionable intelligence box and the= steering decision device. My comment is more in the context of steering traffic at layer 1/2/3 level = i.e. using OpenFlow rather than steering at layer 4-7 level. Steering at la= yer 4-7 can be provided for as a service function and already available tod= ay in devices such as LB, ADC and DPI. Traffic is steered to the service fu= nctions at layer1/2/3. Regards, Chuong=20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Friday, 7 February 2014 12:47 PM To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Do= lson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt The use case of the offline (mirrored feed) DPI interacting with the SFC is= an interesting one. Wrt the inline DPI case, since we've said that any = service function can reclassify, at first glance it isn't any different tha= n any other service function. Putting the 2 cases together, do we want to portray the flow recognition en= tity separately from the per-flow decision making entity? This is somew= hat analogous to the 3gpp PCEF/PCRF split, although in practice, there are = severe scaling constraints to actually engage the PCRF on a per-flow basis.= Of course, choosing to portray these as separate entities means that a p= rotocol needs to be defined between them. By assuming that the flow recog= nition entity is also the decision making entity (i.e., the policy decision= point in some of the drafts), the complexity of the problem is reduced. Thoughts? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Thursday, February 06, 2014 6:11 PM To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Sti= emerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chris, It depends on how you look at the issue. In this comment " there is also the case where the DPI actually determines = the chain + steers the flow through the SFC, bidirectionally.", there are t= wo separate functions, "determines" and "steers". The determination functio= n could be inline or offline. The steer function needs to be inline but thi= s function could be provided for by the SFC, not necessarily the DPI.=20 I agree that we should generalise and include both offline and inline modes= as equally valid (as in ITU-T Rec. Y.2770 (11/2012). There are cases where offline mode is beneficial. For example, to determine= a heat map (list of IP addresses) of popular but problematic video servers= , only one DPI in a major region (can combine with sampling technique to re= duce load on this DPI) may be adequate, assumed that as these videos are wa= nted by users in other regions as well as they are popular. Another advanta= ge is when the DPI is offline (for the right use cases), the risk to custom= er traffic is significantly reduced. Regards, Chuong -----Original Message----- From: Chris Frederick [mailto:cfrederick@sandvine.com]=20 Sent: Friday, 7 February 2014 2:51 AM To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Chuong, As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps no= t ideal for traffic steering/service chaining; devices that receive only an= offline copy of a flow cannot themselves redirect/steer that flow. So, I w= ouldn't necessarily agree that the only case where the DPI is required to b= e inline is when it acts as a service function; there is also the case wher= e the DPI actually determines the chain + steers the flow through the SFC, = bidirectionally. I'd further argue that this is actually ideal as it obviat= es some unnecessary signaling overhead. Of course, it's possible to deploy offline as you note, with the implicit a= ssumption that the offline DPI would then be signaling back to inline devic= es (either directly or circuitously through a PCRF), perhaps with inherent = race conditions, etc.=20 Thanks, /c -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 05, 2014 9:24 PM To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-h= aeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi all, Would you please consider my thoughts below in the Draft. 1-The TDF is an inline function which inspects user payload at application = layer i.e. inspect HTTP headers. With the trend in adoption of encryption (= SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing 30% etc.), the c= apability of the TDF to be able to inspect at application may be diminished= . 2- The use of a DPI function in place of the TDF which may or may have an i= nterface to the PCRF. This DPI for many traffic cases, do not have to be de= ployed in line with customer traffic. It can be deployed in an out-of-path = fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent information for = traffic steering/service chaining actions. The only use case where the DPI = is required to be in line is when it acts as an enforcement Service Functio= n however in this mode, it needs to be treated as a Service Function, not a= traffic steering device. 3- Section 6.2 current has this paragraph: "...Service chain behavior and output should additionally depend on actual network conditions. For example, the selection of a video compression format could dependent on the actual load of the mobile network segment a mobile user is attached to..." I agreed with paragraph and therefore we could include something to the eff= ect of an "actionable intelligence" function which receives inputs from sou= rces such as the network and the traffic, derive traffic steering decisions= and communicate with the service chaining function. Examples:=20 -Receive from the Mobile network the list of user's ip addresses who are at= the present located in the congested cells so that new video sessions are = steered to a video optimisation platform. - Inspect network traffic (in out-of-path mode) and derive a heat map of pr= oblematic TCP flows which may be benefited from TCP Optimiser and steer tra= ffic to this device. - Inspect network traffic and derive a heat map of popular content remotely= located and steer traffic to a local Web Cache so that content is made ava= ilable locally for the current and future users. Regards, Chuong =20 -----Original Message----- From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]=20 Sent: Thursday, 6 February 2014 12:21 PM To: Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Dave, Thanks for your comment. We are going to include a Rel.11 TDF paragraph in= -01. Possibly we will consider 2 sections: most simple case (with APN), ac= tual most advanced case (with TDF).=20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson Gesendet: Dienstag, 4. Februar 2014 20:23 An: Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Betreff: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Although draft-haeffner-sfc-use-case-mobility-00 describes one arrangement = of mobility architecture, it neglects to show the role of the Traffic Detec= tion Function (TDF), also described in the cited 3GPP TS 23.203 (Version 12= ). I don't want to argue with the use cases, just the implied network architec= ture. In all of the network diagrams and examples, it should be understood that t= he P-GW is not the only location from which a policy-based service chain co= uld be initiated; the standard TDF function can also initiate service chain= s selected by policy and traffic type. Section 2.1 should show an optional TDF element between the P-GW and the (S= )Gi-LAN. A TDF communicates with a PCRF using the Sd interface, from which it receiv= es Application Detection and Control (ADC) rules, similar to the rules depl= oyed to the P-GW via the Gx interface. Aside from the APN classification scheme mentioned in section 2.3 of the dr= aft, ADC rules can cause decisions based on application type (not just base= d on APN or UDP/TCP port classification). -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling Sent: Wednesday, January 29, 2014 9:46 AM To: sfc@ietf.org Subject: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Hi all, I wanted to raise your attention to the below quoted draft, as it wasn't po= sted to the SFC list. The draft outlines very well the use cases in mobile networks. Thanks, Martin -------- Original Message -------- Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Date: Tue, 28 Jan 2014 14:26:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining Use Cases in Mobile=20 Networks Authors : Walter Haeffner Jeffrey Napper Filename : draft-haeffner-sfc-use-case-mobility-00.txt Pages : 17 Date : 2014-01-28 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 and framework statements 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 ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery, take care of security and privacy or support application and business support platforms. 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 S.Majee@f5.com Fri Feb 7 19:45:33 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC341A0342 for ; Fri, 7 Feb 2014 19:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.536 X-Spam-Level: X-Spam-Status: No, score=-7.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 WEZSfYxSSep7 for ; Fri, 7 Feb 2014 19:45:31 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0D1ADBD2 for ; Fri, 7 Feb 2014 19:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1391831131; x=1423367131; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eeYCGceUuqOXjwjYDO2jZ5yb3EWgkJVIqF47rlah758=; b=qmywWxohOk8p4J3EduOSrJvvyqFuwoEXTKP4J25Z6p9jKWrYQSCNTcZG wHbrOBnGLmuNPFOq3yEXw7cX8wWkL9YLEoFfHC6X/TvkdeXNS2EzWUCop 0gKrIVY31SVLSCk/ZBSRv981rUVSmDYCvoHmfv94VjIOJJVJoV3FOw+CE U=; X-IronPort-AV: E=Sophos;i="4.95,804,1384300800"; d="scan'208";a="99807837" X-IPAS-Result: AqIEAB+n9VLAqArr/2dsb2JhbABZg0RXvz6BIXSCJQEBAQECAQEBAWQHCwwEAgEIDQQBAgEBASgHJwsUAwYIAgQBDQUJh2gDCRXDbx2INheOEEImBQcCBIQyBIkRkEyFPoVxiG2CKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 08 Feb 2014 03:45:27 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 19:45:26 -0800 From: Sumandra Majee To: "Pham, Chuong D" , Ron Parker , Chris Frederick , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDb17RMqROTSky5SpNRfFzsdZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIABpnaA//+GwgA= Date: Sat, 8 Feb 2014 03:45:26 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C29839B3E9B@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C29839B3E9B@WSMSG3154V.srv.dir.telstra.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.16.250] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 03:45:34 -0000 >> My point was that to "recognise traffic to be steered", an offline DPI >>is a valid source of inputs into the steering decision. It would be too late to steer at that point. A typical DPI needs multiple pkt before classification so the options are a) buffer the stream or b) use http redirect (only in http context). Redirect would add more latency to the overall user experience. On 2/7/14, 6:59 PM, "Pham, Chuong D" wrote: >Hi Ron,=20 > >In my comment I just wanted to point out that there is an option to >deploy an actionable intelligence box in an off-line mode (it is a DPI in >this discussion), in respond to Chris's suggestion about an TDF function >to be placed in-line to recognise application flows (the TDF is simply a >DPI with Sd interface with the PCRF). My point was that to "recognise >traffic to be steered", an offline DPI is a valid source of inputs into >the steering decision. > >I am not sure a protocol is needed to be developed. In our current work, >we use SOAP interface between the offline actionable intelligence box and >the steering decision device. > >My comment is more in the context of steering traffic at layer 1/2/3 >level i.e. using OpenFlow rather than steering at layer 4-7 level. >Steering at layer 4-7 can be provided for as a service function and >already available today in devices such as LB, ADC and DPI. Traffic is >steered to the service functions at layer1/2/3. > >Regards, >Chuong=20 > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Friday, 7 February 2014 12:47 PM >To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; Dave >Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >The use case of the offline (mirrored feed) DPI interacting with the SFC >is an interesting one. Wrt the inline DPI case, since we've said that >any service function can reclassify, at first glance it isn't any >different than any other service function. > >Putting the 2 cases together, do we want to portray the flow recognition >entity separately from the per-flow decision making entity? This is >somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, >there are severe scaling constraints to actually engage the PCRF on a >per-flow basis. Of course, choosing to portray these as separate >entities means that a protocol needs to be defined between them. By >assuming that the flow recognition entity is also the decision making >entity (i.e., the policy decision point in some of the drafts), the >complexity of the problem is reduced. > >Thoughts? > > Ron > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Thursday, February 06, 2014 6:11 PM >To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chris, > >It depends on how you look at the issue. > >In this comment " there is also the case where the DPI actually >determines the chain + steers the flow through the SFC, >bidirectionally.", there are two separate functions, "determines" and >"steers". The determination function could be inline or offline. The >steer function needs to be inline but this function could be provided for >by the SFC, not necessarily the DPI. > >I agree that we should generalise and include both offline and inline >modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012). > >There are cases where offline mode is beneficial. For example, to >determine a heat map (list of IP addresses) of popular but problematic >video servers, only one DPI in a major region (can combine with sampling >technique to reduce load on this DPI) may be adequate, assumed that as >these videos are wanted by users in other regions as well as they are >popular. Another advantage is when the DPI is offline (for the right use >cases), the risk to customer traffic is significantly reduced. > >Regards, >Chuong >-----Original Message----- >From: Chris Frederick [mailto:cfrederick@sandvine.com] >Sent: Friday, 7 February 2014 2:51 AM >To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chuong, >As a comment on item 2) below, I'd offer that out-of-path DPI is perhaps >not ideal for traffic steering/service chaining; devices that receive >only an offline copy of a flow cannot themselves redirect/steer that >flow. So, I wouldn't necessarily agree that the only case where the DPI >is required to be inline is when it acts as a service function; there is >also the case where the DPI actually determines the chain + steers the >flow through the SFC, bidirectionally. I'd further argue that this is >actually ideal as it obviates some unnecessary signaling overhead. >Of course, it's possible to deploy offline as you note, with the implicit >assumption that the offline DPI would then be signaling back to inline >devices (either directly or circuitously through a PCRF), perhaps with >inherent race conditions, etc. >Thanks, >/c > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Wednesday, February 05, 2014 9:24 PM >To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >Would you please consider my thoughts below in the Draft. > >1-The TDF is an inline function which inspects user payload at >application layer i.e. inspect HTTP headers. With the trend in adoption >of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are seeing >30% etc.), the capability of the TDF to be able to inspect at application >may be diminished. > >2- The use of a DPI function in place of the TDF which may or may have an >interface to the PCRF. This DPI for many traffic cases, do not have to be >deployed in line with customer traffic. It can be deployed in an >out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent >information for traffic steering/service chaining actions. The only use >case where the DPI is required to be in line is when it acts as an >enforcement Service Function however in this mode, it needs to be treated >as a Service Function, not a traffic steering device. > >3- Section 6.2 current has this paragraph: >"...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." > >I agreed with paragraph and therefore we could include something to the >effect of an "actionable intelligence" function which receives inputs >from sources such as the network and the traffic, derive traffic steering >decisions and communicate with the service chaining function. > >Examples:=20 >-Receive from the Mobile network the list of user's ip addresses who are >at the present located in the congested cells so that new video sessions >are steered to a video optimisation platform. >- Inspect network traffic (in out-of-path mode) and derive a heat map of >problematic TCP flows which may be benefited from TCP Optimiser and steer >traffic to this device. >- Inspect network traffic and derive a heat map of popular content >remotely located and steer traffic to a local Web Cache so that content >is made available locally for the current and future users. > >Regards, >Chuong > >=20 > >-----Original Message----- >From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com] >Sent: Thursday, 6 February 2014 12:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph >in -01. Possibly we will consider 2 sections: most simple case (with >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of the >Traffic Detection Function (TDF), also described in the cited 3GPP TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood that >the P-GW is not the only location from which a policy-based service chain >could be initiated; the standard TDF function can also initiate service >chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and the >(S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of the >draft, ADC rules can cause decisions based on application type (not just >based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it wasn't >posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >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 Chuong.D.Pham@team.telstra.com Fri Feb 7 19:56:46 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2154E1A0354 for ; Fri, 7 Feb 2014 19:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7iVKG6SMTaG for ; Fri, 7 Feb 2014 19:56:43 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 179C11A0349 for ; Fri, 7 Feb 2014 19:56:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,804,1384261200"; d="scan'208";a="184186547" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 08 Feb 2014 14:56:41 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7342"; a="147275845" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Feb 2014 14:56:41 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Sat, 8 Feb 2014 14:56:40 +1100 From: "Pham, Chuong D" To: Sumandra Majee , Ron Parker , Chris Frederick , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "sfc@ietf.org" Date: Sat, 8 Feb 2014 14:56:38 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDb17RMqROTSky5SpNRfFzsdZqmCQKAgAH2hQCAABGVAIAA4XwAgAB62QCAACu6AIABpnaA//+GwgCAAAELEA== Message-ID: <5602569641FB314FB4D9AD5659D41B9C29839B3EAB@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <5602569641FB314FB4D9AD5659D41B9C29838FFFCC@WSMSG3154V.srv.dir.telstra.com> <802F0FD88084CC4D82A0663874219D1A188837EC@wtl-exchp-2.sandvine.com> <5602569641FB314FB4D9AD5659D41B9C29839B325E@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C29839B3E9B@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jeffrey Napper \(jenapper\) \(jenapper@cisco.com\)" Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 03:56:46 -0000 Hi, I've mentioned before, the idea is to compute a heat map of interesting IP = destinations and continue doing so on a continual basis. Yes, I agree it wo= uld be too late to steer if you only are thinking about traditional flow re= cognition mechanism, which as I said, is seen as on the declination with en= cryption trend and also the "price to pay" in the sense that the customer t= raffic is "held back" for the DPI to make a decision. That would affect QoE= and impose capacity constraint on the DPI. Even steering with HTTP redirect is better than holding back TCP and HTTP w= aiting to make a decision like the way DPI is doing today. That case is onl= y ok for the traditional throttling traffic management use case. One example of how a heat map may be computed is gather traffic and work ou= t TCP flows with high RTT. Those flows will be benefited from TCP Optimisat= ion. Once the heat map has been stable enough in given time window, supply = the map to the flow steering control device which will instruct the switch = to start steering the new flows to those destinations to the TCP Optimiser. There are many other examples similar like the ones above. Regards, Chuong -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com] Sent: Saturday, 8 February 2014 2:45 PM To: Pham, Chuong D; Ron Parker; Chris Frederick; Haeffner, Walter, Vodafone= DE; Dave Dolson; Martin Stiemerling; sfc@ietf.org Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt >> My point was that to "recognise traffic to be steered", an offline >>DPI is a valid source of inputs into the steering decision. It would be too late to steer at that point. A typical DPI needs multiple = pkt before classification so the options are a) buffer the stream or b) use= http redirect (only in http context). Redirect would add more latency to t= he overall user experience. On 2/7/14, 6:59 PM, "Pham, Chuong D" wrote: >Hi Ron, > >In my comment I just wanted to point out that there is an option to >deploy an actionable intelligence box in an off-line mode (it is a DPI >in this discussion), in respond to Chris's suggestion about an TDF >function to be placed in-line to recognise application flows (the TDF >is simply a DPI with Sd interface with the PCRF). My point was that to >"recognise traffic to be steered", an offline DPI is a valid source of >inputs into the steering decision. > >I am not sure a protocol is needed to be developed. In our current >work, we use SOAP interface between the offline actionable intelligence >box and the steering decision device. > >My comment is more in the context of steering traffic at layer 1/2/3 >level i.e. using OpenFlow rather than steering at layer 4-7 level. >Steering at layer 4-7 can be provided for as a service function and >already available today in devices such as LB, ADC and DPI. Traffic is >steered to the service functions at layer1/2/3. > >Regards, >Chuong > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Friday, 7 February 2014 12:47 PM >To: Pham, Chuong D; Chris Frederick; Haeffner, Walter, Vodafone DE; >Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >The use case of the offline (mirrored feed) DPI interacting with the SFC >is an interesting one. Wrt the inline DPI case, since we've said that >any service function can reclassify, at first glance it isn't any >different than any other service function. > >Putting the 2 cases together, do we want to portray the flow recognition >entity separately from the per-flow decision making entity? This is >somewhat analogous to the 3gpp PCEF/PCRF split, although in practice, >there are severe scaling constraints to actually engage the PCRF on a >per-flow basis. Of course, choosing to portray these as separate >entities means that a protocol needs to be defined between them. By >assuming that the flow recognition entity is also the decision making >entity (i.e., the policy decision point in some of the drafts), the >complexity of the problem is reduced. > >Thoughts? > > Ron > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Thursday, February 06, 2014 6:11 PM >To: Chris Frederick; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chris, > >It depends on how you look at the issue. > >In this comment " there is also the case where the DPI actually >determines the chain + steers the flow through the SFC, >bidirectionally.", there are two separate functions, "determines" and >"steers". The determination function could be inline or offline. The >steer function needs to be inline but this function could be provided >for by the SFC, not necessarily the DPI. > >I agree that we should generalise and include both offline and inline >modes as equally valid (as in ITU-T Rec. Y.2770 (11/2012). > >There are cases where offline mode is beneficial. For example, to >determine a heat map (list of IP addresses) of popular but problematic >video servers, only one DPI in a major region (can combine with >sampling technique to reduce load on this DPI) may be adequate, assumed >that as these videos are wanted by users in other regions as well as >they are popular. Another advantage is when the DPI is offline (for the >right use cases), the risk to customer traffic is significantly reduced. > >Regards, >Chuong >-----Original Message----- >From: Chris Frederick [mailto:cfrederick@sandvine.com] >Sent: Friday, 7 February 2014 2:51 AM >To: Pham, Chuong D; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Chuong, >As a comment on item 2) below, I'd offer that out-of-path DPI is >perhaps not ideal for traffic steering/service chaining; devices that >receive only an offline copy of a flow cannot themselves redirect/steer >that flow. So, I wouldn't necessarily agree that the only case where >the DPI is required to be inline is when it acts as a service function; >there is also the case where the DPI actually determines the chain + >steers the flow through the SFC, bidirectionally. I'd further argue >that this is actually ideal as it obviates some unnecessary signaling over= head. >Of course, it's possible to deploy offline as you note, with the >implicit assumption that the offline DPI would then be signaling back >to inline devices (either directly or circuitously through a PCRF), >perhaps with inherent race conditions, etc. >Thanks, >/c > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Wednesday, February 05, 2014 9:24 PM >To: Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >Would you please consider my thoughts below in the Draft. > >1-The TDF is an inline function which inspects user payload at >application layer i.e. inspect HTTP headers. With the trend in adoption >of encryption (SPDY, HTTP2.0, Akamai estimates 40% by 2016, we are >seeing 30% etc.), the capability of the TDF to be able to inspect at >application may be diminished. > >2- The use of a DPI function in place of the TDF which may or may have >an interface to the PCRF. This DPI for many traffic cases, do not have >to be deployed in line with customer traffic. It can be deployed in an >out-of-path fashion (ITU-T Rec. Y.2770 (11/2012) to derive intelligent >information for traffic steering/service chaining actions. The only use >case where the DPI is required to be in line is when it acts as an >enforcement Service Function however in this mode, it needs to be >treated as a Service Function, not a traffic steering device. > >3- Section 6.2 current has this paragraph: >"...Service chain behavior and output should additionally depend on > actual network conditions. For example, the selection of a video > compression format could dependent on the actual load of the mobile > network segment a mobile user is attached to..." > >I agreed with paragraph and therefore we could include something to the >effect of an "actionable intelligence" function which receives inputs >from sources such as the network and the traffic, derive traffic >steering decisions and communicate with the service chaining function. > >Examples: >-Receive from the Mobile network the list of user's ip addresses who >are at the present located in the congested cells so that new video >sessions are steered to a video optimisation platform. >- Inspect network traffic (in out-of-path mode) and derive a heat map >of problematic TCP flows which may be benefited from TCP Optimiser and >steer traffic to this device. >- Inspect network traffic and derive a heat map of popular content >remotely located and steer traffic to a local Web Cache so that content >is made available locally for the current and future users. > >Regards, >Chuong > > > >-----Original Message----- >From: Haeffner, Walter, Vodafone DE >[mailto:walter.haeffner@vodafone.com] >Sent: Thursday, 6 February 2014 12:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF >paragraph in -01. Possibly we will consider 2 sections: most simple >case (with APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of >the Traffic Detection Function (TDF), also described in the cited 3GPP >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood >that the P-GW is not the only location from which a policy-based >service chain could be initiated; the standard TDF function can also >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of >the draft, ADC rules can cause decisions based on application type (not >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >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 linda.dunbar@huawei.com Sat Feb 8 07:48:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10B1A033A for ; Sat, 8 Feb 2014 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 anx_8amObyde for ; Sat, 8 Feb 2014 07:48:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 479411A0339 for ; Sat, 8 Feb 2014 07:48:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDJ53671; Sat, 08 Feb 2014 15:48:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 8 Feb 2014 15:47:23 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 8 Feb 2014 15:48:26 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Sat, 8 Feb 2014 07:48:12 -0800 From: Linda Dunbar To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt Thread-Index: AQHPJOJWuIDUqtgnlkaZEJ6rdtz9jJqrfb3Q Date: Sat, 8 Feb 2014 15:48:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7A7AC@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-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: Sat, 08 Feb 2014 15:48:32 -0000 VGhpcyBkcmFmdCBhbmFseXplcyB0aGUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyBl eGlzdGluZyBMYXllciA0LTcgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9m IHNlcnZpY2UgZW5jYXBzdWxhdGlvbiBsYXllcnMuIFRoaXMgZHJhZnQgYWxzbyBleGFtaW5lcyB0 aGUgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9yIGNoYWluaW5nIGV4aXN0aW5nIEw0LUw3IHNlcnZp Y2UgZnVuY3Rpb25zLiBUaGUgZ29hbCBvZiB0aGUgZHJhZnQgaXM6DQoNCg0KLSBUbyBtYWtlIFNG QyBXRyBhZG9wdCB0aGUgZmFjdCB0aGF0IHRoZXJlIGFyZSBtYW55IHNlcnZpY2UgZnVuY3Rpb25z IGRlcGxveWVkIHRoYXQgZG9u4oCZdCB0ZXJtaW5hdGUgdGhlIG5ld2x5IHByb3Bvc2VkIFNGQyBI ZWFkZXI7IE1hbnkgb2YgdGhlbSBkb27igJl0IGhhdmUgTDIvTDMgc3dpdGNoaW5nL3JvdXRpbmcg Y2FwYWJpbGl0eQ0KDQotIFRvIG1ha2UgU0ZDIFdHIGFkb3B0IHRoYXQgU2VydmljZSBGdW5jdGlv biBGb3J3YXJkZXIgKHRoYXQgaXMgZGVmaW5lZCBieSBkcmFmdC1xdWlubi1uc2MtYXJjaC0wNCkg Y2FuIGJlIGEgc2VwYXJhdGUgZW50aXR5IGZyb20gc2VydmljZSBmdW5jdGlvbnMuIA0KDQotIFRv IG1ha2UgU0ZDIFdHIGFkb3B0IHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSBmb3IgZXZlcnkgcGFj a2V0IHRvIGNhcnJ5IHRoZSBjb21wbGV0ZSBzZXJ2aWNlIGNoYWluIGZvcndhcmRpbmcgaW5mb3Jt YXRpb24gaW4gaXRzIFNGQyBoZWFkZXIuIMKgSXQgc2hvdWxkIGJlIGFjY2VwdGFibGUgdG8gaGF2 ZSB2YXJpYWJsZSBsZW5ndGggU0ZDIEhlYWRlci4gRm9yIGV4YW1wbGUsIGZvciBwYWNrZXRzIHRv IGJlIGVuY29kZWQgd2l0aCBhIENoYWluIElEIHBsdXMgb3B0aW9uYWwgYXR0cmlidXRlcyBhbmQg aGF2ZSBzZXBhcmF0ZSBtZXNzYWdlcyAoZWl0aGVyIGluLWJhbmQgb3Igb3V0LW9mLWJhbmQpIHRv IGluZm9ybSB0aGUgZGV0YWlsZWQgZm9yd2FyZGluZyBwb2xpY2llcyBmb3IgdGhlIENoYWluIElE IGFuZCB0aGUgQ2hhaW4gYXR0cmlidXRlcyBpbiB0aGUgcGFja2V0cyDCoHRvIHRoZSBTZXJ2aWNl IEZ1bmN0aW9uIEZvcndhcmRpbmcgbm9kZXMuIA0KDQotIFJlY29nbml6ZSB0aGF0IGZyb20gdXNl cuKAmXMgcGVyc3BlY3RpdmUsIHRoZSBvcmRlciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucywgZS5nLiBD aGFpbiMxIHtzMSwgczQsIHM2fSwgQ2hhaW4jMntzNCwgczd9LCBpcyBpbXBvcnRhbnQsIGJ1dCB2 ZXJ5IG9mdGVuIHdoaWNoIGluc3RhbmNlIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIOKAnHMx4oCd IGlzIHNlbGVjdGVkIGZvciB0aGUgQ2hhaW4gIzEgaXMgbm90LiAgDQoJQW1vbmcgbXVsdGlwbGUg aW5zdGFuY2VzIG9mIG9uZSBzZXJ2aWNlIGZ1bmN0aW9uLCBzb21lIGNvdWxkIGJlIGluIGNsb3Nl IHByb3hpbWl0eSB3aGlsZSBvdGhlcnMgYXJlIGZhciBhcGFydCBiZWluZyBjb25uZWN0ZWQgYnkg ZGlmZmVyZW50IG5ldHdvcmsgbm9kZXMuDQoJSXQgc2hvdWxkIGJlIGFjY2VwdGFibGUgZm9yIFNl cnZpY2UgQ2hhaW4gY2xhc3NpZmllciBvbmx5IGlkZW50aWZ5IHRoZSBjaGFpbmluZyBhdCBmdW5j dGlvbiBsZXZlbCBhbmQgaGF2ZSBhbm90aGVyIGVudGl0eSBtYW5hZ2luZyB0aGUgZGV0YWlsZWQg c2VydmljZSBpbnN0YW5jZSBwYXRoLg0KDQoNCllvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z IGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiANCg0KVGhhbmtzLCBMaW5kYQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwOCwg MjAxNCA5OjI4IEFNDQpUbzogTGluZGEgRHVuYmFyOyBSb24gUGFya2VyOyBOaW5nIFNvOyBSb24g UGFya2VyOyBTbyBOaW5nOyBEb25hbGQgRWFzdGxha2U7IExpbmRhIER1bmJhcjsgRG9uYWxkIEUu IEVhc3RsYWtlIDNyZA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDIudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWlu LWFyY2hpdGVjdHVyZS0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg TGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZQ0KUmV2aXNp b246CTAyDQpUaXRsZToJCUFyY2hpdGVjdHVyZSBmb3IgQ2hhaW5pbmcgTGVnYWN5IExheWVyIDQt NyBTZXJ2aWNlIEZ1bmN0aW9ucw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMi0wNw0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1s Ny1jaGFpbi1hcmNoaXRlY3R1cmUtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4t YXJjaGl0ZWN0dXJlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMg0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWR1bmJh ci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZHJhZnQgYW5hbHl6ZXMgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggY2hhaW5pbmcg ZXhpc3RpbmcNCiAgIExheWVyIDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSBub3QgYXdh cmUgb2Ygc2VydmljZQ0KICAgZW5jYXBzdWxhdGlvbiBsYXllcnMuIFRoaXMgZHJhZnQgYWxzbyBl eGFtaW5lcyB0aGUgbmV0d29yaw0KICAgYXJjaGl0ZWN0dXJlIGZvciBjaGFpbmluZyBleGlzdGlu ZyBMNC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucy4gVGhlDQogICBpbnRlbnQgaXMgdG8gaWRlbnRpZnkg b3B0aW1hbCBhcmNoaXRlY3R1cmUgZm9yIGZsZXhpYmx5IGNoYWluaW5nDQogICBleGlzdGluZyBM YXllciA0LTcgZnVuY3Rpb25zIHRvIG1lZXQgdmFyaW91cyBzZXJ2aWNlIG5lZWRzLg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From linda.dunbar@huawei.com Sat Feb 8 07:54:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038D11A03A5 for ; Sat, 8 Feb 2014 07:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 RzgQXryZQN2C for ; Sat, 8 Feb 2014 07:53:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAF61A0339 for ; Sat, 8 Feb 2014 07:53:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAX47589; Sat, 08 Feb 2014 15:53:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 8 Feb 2014 15:52:53 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 8 Feb 2014 15:53:42 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Sat, 8 Feb 2014 07:53:31 -0800 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG Agenda: London Thread-Index: AQHPH3JY7vfIB63+W06bsptZEKAjcZqri8GA Date: Sat, 8 Feb 2014 15:53:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7A7C4@dfweml701-chm.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.4] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C7A7C4dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten Subject: Re: [sfc] SFC WG Agenda: London X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 15:54:03 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C7A7C4dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim and Thomas, We would like a 5-10 minutes slot to show the architecture of chaining exis= ting L4-L7 service functions. By L4-L7, it means that those service functio= ns don't have L2/L3 switching/routing capability. The goal of the draft is: - To make SFC WG adopt the fact that there are many service functions deplo= yed that don't terminate the newly proposed SFC Header; Many of them don't = have L2/L3 switching/routing capability - To make SFC WG adopt that Service Function Forwarder (that is defined by = draft-quinn-nsc-arch-04) can be a separate entity from service functions. - To make SFC WG adopt that it is not necessary for every packet to carry t= he complete service chain forwarding information in its SFC header. It sho= uld be acceptable to have variable length SFC Header. For example, for pack= ets to be encoded with a Chain ID plus optional attributes and have separat= e messages (either in-band or out-of-band) to inform the detailed forwardin= g policies for the Chain ID and the Chain attributes in the packets to the= Service Function Forwarding nodes. - Recognize that from user's perspective, the order of service functions, e= .g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often whi= ch instance of the Service Function "s1" is selected for the Chain #1 is no= t. Among multiple instances of one service function, some could = be in close proximity while others are far apart being connected by differe= nt network nodes. It should be acceptable for Service Chain classifier only ide= ntify the chaining at function level and have another entity managing the d= etailed service instance path. Thanks, Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, February 01, 2014 11:24 AM To: sfc@ietf.org Subject: [sfc] SFC WG Agenda: London Greetings, It's time to start putting together an agenda for the SFC meeting in London= . We've requested one 2.5 hour slot . Because face-to-face time is precious= , we intend to focus on: - WG chartered items for which we have WG-adopted IDs, or IDs that appear h= eaded for WG adoption. - Specific topics where feedback is needed, and mailing list discussions ha= ve not converged. We also do not intend to give agenda time to everyone who has a draft - the= WG sessions do not have time for that, nor is it necessarily an effective = use of time. We also do not intend to give agenda time for drafts for which= little or no mailing list interest has been generated. For the upcoming session, we expect to focus on: 1) Problem satement (hopefully not much time needed -- are there any actual= open issues?). 2) Use cases. 3) Architecture. If you have a draft (or plan to submit one) and would like to present (or m= ore specifically, would like the working group to do something with your dr= aft), please: 1) Let us know now (even if the draft is not published yet), so we can star= t planning; 2) Indicate which WG deliverable the draft relates to; and 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Thanks! Thomas & Jim --_000_4A95BA014132FF49AE685FAB4B9F17F645C7A7C4dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim and Thomas,

 <= /p>

We would like a 5-10 minu= tes slot to show the architecture of chaining existing L4-L7 service functi= ons. By L4-L7, it means that those service functions don’t have L2/L3 switching/routing capability.

 <= /p>

The goal of the draft is:=

 <= /p>

- To make SFC WG adopt th= e fact that there are many service functions deployed that don’t term= inate the newly proposed SFC Header; Many of them don’t have L2/L3 switching/routing capability

 <= /p>

- To make SFC WG adopt th= at Service Function Forwarder (that is defined by draft-quinn-nsc-arch-04) = can be a separate entity from service functions.

 <= /p>

- To make SFC WG adopt th= at it is not necessary for every packet to carry the complete service chain= forwarding information in its SFC header.  It should be acceptable to have variable length SFC Header. For example, for packets to= be encoded with a Chain ID plus optional attributes and have separate mess= ages (either in-band or out-of-band) to inform the detailed forwarding poli= cies for the Chain ID and the Chain attributes in the packets  to the Service Function Forwarding nodes. =

 <= /p>

- Recognize that from use= r’s perspective, the order of service functions, e.g. Chain#1 {s1, s4= , s6}, Chain#2{s4, s7}, is important, but very often which instance of the Service Function “s1” is selected for the Chain #1 is n= ot. 

    &= nbsp;         Among multiple instan= ces of one service function, some could be in close proximity while others = are far apart being connected by different network nodes.

    &= nbsp;         It should be acceptab= le for Service Chain classifier only identify the chaining at function leve= l and have another entity managing the detailed service instance path.

 <= /p>

Thanks, Linda<= /span>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, February 01, 2014 11:24 AM
To: sfc@ietf.org
Subject: [sfc] SFC WG Agenda: London

 

Greetings,

 

It's time to start putting = together an agenda for the SFC meeting in London. We've requested one = 2.5 hour slot . Because face-to-face time is precious, we intend to focus on:

&n= bsp;

- WG ch= artered items for which we have WG-adopted IDs, or IDs that appear headed f= or WG adoption.

&n= bsp;

- Speci= fic topics where feedback is needed, and mailing list discussions have not = converged.

&n= bsp;

We also= do not intend to give agenda time to everyone who has a draft - the WG ses= sions do not have time for that, nor is it necessarily an effective use of = time. We also do not intend to give agenda time for drafts for which little or no mailing list interest has be= en generated.

&n= bsp;

For the= upcoming session, we expect to focus on:

&n= bsp;

1) Prob= lem satement (hopefully not much time needed -- are there any actual open i= ssues?).

&n= bsp;

2) Use = cases.

&n= bsp;

3) Arch= itecture.

&n= bsp;

If you = have a draft (or plan to submit one) and would like to present (or more spe= cifically, would like the working group to do something with your draft), p= lease:

&n= bsp;

1) Let = us know now (even if the draft is not published yet), so we can start plann= ing;

&n= bsp;

2) Indi= cate which WG deliverable the draft relates to; and

&n= bsp;

3) Indi= cate what you want the WG to do with your draft. E.g., do you want this to = become "THE" WG document for a particular deliverable? Or, is the= re content in the document you believe should be added to another document? etc. Please do not just respond "I want= it to become a WG document". It would be better to explain in what co= ntext, and how your draft relates to other drafts that have been submitted.=

&n= bsp;

Thanks!=

&n= bsp;

Thomas = & Jim

--_000_4A95BA014132FF49AE685FAB4B9F17F645C7A7C4dfweml701chmchi_-- From jenapper@cisco.com Sun Feb 9 11:07:21 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EA51A050A for ; Sun, 9 Feb 2014 11:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZxPIMjzxzdZ for ; Sun, 9 Feb 2014 11:07:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACA931A050B for ; Sun, 9 Feb 2014 11:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9105; q=dns/txt; s=iport; t=1391972839; x=1393182439; h=from:to:cc:subject:date:message-id:mime-version; bh=HhAT8QvcZrkpB3Hg65DmH65t693XZBUyUN+C6fzYqeM=; b=AvQj85W+2ECJW2xkyyInaceQrtBxLU3xwgFKze5mGwUAQixy0DOjWtz7 1W8HNzJZEyV83c4WVcRvvL61U7N2zLfRWkbf4FB1E3wHa4xes2ku3zUZ2 IyyPenw2xj0r7GOudCNSGtzBLVnD1jgcka5leDCcVtwoBpETzMMwXrzzb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAJXR91KtJV2d/2dsb2JhbABZgkhEOFe/QYEGFnSCJQECBG4LEgEIEQECAQIoORQDBgoEAQ0FiAUNyBoTBI4pQw0EhD8EmCuSIYMtgio X-IronPort-AV: E=Sophos;i="4.95,813,1384300800"; d="scan'208,217";a="302683819" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 09 Feb 2014 19:07:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s19J7IZT027975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Feb 2014 19:07:18 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.67]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 9 Feb 2014 13:07:18 -0600 From: "Jeffrey Napper (jenapper)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC WG Agenda: London Thread-Index: AQHPJcom7vfIB63+W06bsptZEKAjcQ== Date: Sun, 9 Feb 2014 19:07:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.32] Content-Type: multipart/alternative; boundary="_000_CF1D8ED6EFD2jenapperciscocom_" MIME-Version: 1.0 Cc: "Haeffner, Walter, Vodafone DE" Subject: Re: [sfc] SFC WG Agenda: London 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, 09 Feb 2014 19:07:21 -0000 --_000_CF1D8ED6EFD2jenapperciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jim & Thomas, We recently submitted a draft with use cases specific to mobility. We plan = to submit a revised version for London with input from other authors and an= y feedback from the list (please feel free to provide more!). Could we get = a slot in the session to discuss it? Requested details: 1) https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ 2) The draft relates mostly to the problem statement and uses case delivera= bles. 3) We are certainly interested in the draft providing the use cases specifi= cally for mobility service chaining. Whether our draft (if it is ultimately= supported) becomes a WG deliverable or is included in a single use case de= liverable depends on how the group decides to produce use cases as recents = posts have discussed. My impression is that the list has not quite decided = on the exact list of use case documents yet. Cheers, Jeff & Walter From: "Jim Guichard (jguichar)" > Date: Saturday, February 1, 2014 at 6:23 PM To: "sfc@ietf.org" > Subject: [sfc] SFC WG Agenda: London Greetings, It's time to start putting together an agenda for the SFC meeting in London= . We've requested one 2.5 hour slot . Because face-to-face time is precious= , we intend to focus on: - WG chartered items for which we have WG-adopted IDs, or IDs that appear h= eaded for WG adoption. - Specific topics where feedback is needed, and mailing list discussions ha= ve not converged. We also do not intend to give agenda time to everyone who has a draft - the= WG sessions do not have time for that, nor is it necessarily an effective = use of time. We also do not intend to give agenda time for drafts for which= little or no mailing list interest has been generated. For the upcoming session, we expect to focus on: 1) Problem satement (hopefully not much time needed -- are there any actual= open issues?). 2) Use cases. 3) Architecture. If you have a draft (or plan to submit one) and would like to present (or m= ore specifically, would like the working group to do something with your dr= aft), please: 1) Let us know now (even if the draft is not published yet), so we can star= t planning; 2) Indicate which WG deliverable the draft relates to; and 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Thanks! Thomas & Jim --_000_CF1D8ED6EFD2jenapperciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Jim & Thomas,

We recently submitted a draft with use cases specific to mobility. We = plan to submit a revised version for London with input from other authors a= nd any feedback from the list (please feel free to provide more!). Could we= get a slot in the session to discuss it?

Requested details:


2) The draft relates mostly to the problem statement and uses case del= iverables. 

3) We are certainly interested in the draft providing the use cases sp= ecifically for mobility service chaining. Whether our draft (if it is ultim= ately supported) becomes a WG deliverable or is included in a single u= se case deliverable depends on how the group decides to produce use cases as recents posts have discussed. My imp= ression is that the list has not quite decided on the exact list of use cas= e documents yet.

Cheers,
Jeff & Walter


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Saturday, February 1, 2014 at= 6:23 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] SFC WG Agenda: Londo= n

Greetings,

It's time to start putting together an agenda for the SFC meeting = in London. We've requested o= ne 2.5 hour slot . Because face-to-face time is precious, we intend to f= ocus on:

- WG chartered items for which we have WG= -adopted IDs, or IDs that appear headed for WG adoption.

- Specific topics where feedback is neede= d, and mailing list discussions have not converged.

We also do not intend to give agenda time= to everyone who has a draft - the WG sessions do not have time for that, n= or is it necessarily an effective use of time. We also do not intend to giv= e agenda time for drafts for which little or no mailing list interest has been generated.

For the upcoming session, we expect to fo= cus on:

1) Problem satement (hopefully not much t= ime needed -- are there any actual open issues?).

2) Use cases.

3) Architecture.

If you have a draft (or plan to submit on= e) and would like to present (or more specifically, would like the working = group to do something with your draft), please:

1) Let us know now (even if the draft is = not published yet), so we can start planning;

2) Indicate which WG deliverable the draf= t relates to; and

3) Indicate what you want the WG to do wi= th your draft. E.g., do you want this to become "THE" WG document= for a particular deliverable? Or, is there content in the document you bel= ieve should be added to another document? etc. Please do not just respond "I want it to become a WG document". = It would be better to explain in what context, and how your draft relates t= o other drafts that have been submitted.

Thanks!

Thomas & Jim
 --_000_CF1D8ED6EFD2jenapperciscocom_-- From jenapper@cisco.com Sun Feb 9 11:43:42 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2505D1A06FC for ; Sun, 9 Feb 2014 11:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk-ZAu3GznIZ for ; Sun, 9 Feb 2014 11:43:38 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 85CAB1A06F3 for ; Sun, 9 Feb 2014 11:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7448; q=dns/txt; s=iport; t=1391975019; x=1393184619; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ocPtzxj57p9eMtP5UZ9o50K6pT5tAxSfQQChX8B4odw=; b=OVe8ZFdmj4qP4YdTFJ8FuTj8/YnJdzq/0LgqVo0eZEZaPyaU/nmORvA6 5d1BMemMWP4POcbeNqukBPDVdAgCTujelqQDhXSgh23CsrSRS3SnW0ZoE jN8RILnf14oFkz/kL7g/ARFIFM1asDCarYiO5AJOF8o20gQWLoUzqos8f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAGDZ91KtJXHA/2dsb2JhbABZgww4V79BgQcWdIIlAQEBBAEBAWQHBBMEAgEIEQECAQEBFwIPByEGCxQDBggCBAESCYdoAxENv0INiEYXjGaBZDUFBgwGB4QZBIkRjS6BbIEyiywDhUCDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,813,1384300800"; d="scan'208";a="19098907" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 09 Feb 2014 19:43:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s19Jhckp015183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Feb 2014 19:43:38 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.67]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sun, 9 Feb 2014 13:43:37 -0600 From: "Jeffrey Napper (jenapper)" To: Linda Dunbar , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDOwa56G2NCCEaZAethb78oVpql53uAgAH2hQCAAvCHAIADC0qA Date: Sun, 9 Feb 2014 19:43:36 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.32] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3B47E43B879C044D8698711EA6B091E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 19:43:42 -0000 Hi Linda, First, thanks for the feedback. While it may look like a lot of components, we still have simplified 3GPP quite a lot. For example, in the first draft we left out the TDF that appears in recent standards. We=B9ll b= e adding that in response to other comments. I believe the overview section is still quite short, but we will try to shorten it a bit further if it is too long. If you feel anything in particular is missing or extraneous, please let us know. Yes, it is probably overkill to have two example APNs. The User & Pass are important for example in cases of hot-lining where the user must first be authenticated (for various reasons) before data services are provided/continued. It is just another example of the important relationship between Classification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al,=20 > >While it is interesting to show all the components of 3GPP for GiLAN, but >I don't think it is necessary to have all of them in the SFC use case >draft.=20 > >For example, on your Section 2.3 ("The Most common classification >scheme"), it is very confusing to have the Table 1 & Table 2 listing >"User name & Password". Does it mean that the "User Name & Password" have >to associated with data packets? Or to be detected by the Classification >nodes?=20 > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter, >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph >in -01. Possibly we will consider 2 sections: most simple case (with >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of the >Traffic Detection Function (TDF), also described in the cited 3GPP TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood that >the P-GW is not the only location from which a policy-based service chain >could be initiated; the standard TDF function can also initiate service >chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and the >(S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of the >draft, ADC rules can cause decisions based on application type (not just >based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it wasn't >posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From meng.wei2@zte.com.cn Sun Feb 9 19:15:57 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94331A078E; Sun, 9 Feb 2014 19:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVE2poJMaE-A; Sun, 9 Feb 2014 19:15:52 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAD61A067C; Sun, 9 Feb 2014 19:15:51 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A503F129FC12; Mon, 10 Feb 2014 11:15:43 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id ABB5470868F; Mon, 10 Feb 2014 11:15:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s1A3FYZU042672; Mon, 10 Feb 2014 11:15:34 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: "Reinaldo Penno (repenno)" MIME-Version: 1.0 X-KeepSent: 7710038F:8D1E2840-48257C7B:00101E98; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Mon, 10 Feb 2014 11:15:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-10 11:15:35, Serialize complete at 2014-02-10 11:15:35 Content-Type: multipart/alternative; boundary="=_alternative 001214CA48257C7B_=" X-MAIL: mse02.zte.com.cn s1A3FYZU042672 Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 03:15:58 -0000 This is a multipart message in MIME format. --=_alternative 001214CA48257C7B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIwNCg0KICBGb3IgUmVpbmFsZG8ncyBjb21tZW50cyAyLg0KICBJJ20gbm90IHN1cmUgIlNG IiAmICJTRiBpbnN0YW5jZSIgY29uZnVzZSBtZSBpbiB0aGUgZHJhZnQuDQoNCiAgRm9yIGV4YW1w bGUsIE5BVDQ0IHdpdGggYSBydWxlIGlzIGEgU0YsIE5BVDQ0IHdpdGggYW5vdGhlciBydWxlIGlz IA0KYSBkaWZmZXJlbnQgU0YuICBUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgYmFzZWQgb24gdGhl IGRlc2NyaXB0aW9uIGluDQp0aGUgZHJhZnQuICAgKE9yIGEgc2FtZSBTRiBidXQgZGlmZmVyZW50 IFNGIGluc3RhbmNlcz8pIA0KDQogDQpUaGFua3MsDQpXZWkNCg0KDQoic2ZjIiA8c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc+ICAyMDE0LTAxLTMwIDE0OjI2OjU1Og0KDQo+IEhpIFBhdWwsDQo+IA0KPiBS ZXZpZXdpbmcgdGhpcyBkcmFmdCBhbmQgY29tcGFyaW5nIHdpdGggdGhlIFlhbmcgbW9kZWwgSSBo YXZlIGEgY291cGxlIA0Kb2YNCj4gY29tbWVudHMNCj4gDQo+IDEgLSANCj4gDQo+IEkgbm90aWNl ZCB0aGF0IGEgU0ZJRCBhbmQgU0ZDLWRvbWFpbiBtaWdodCBuZWVkIG1vcmUgd29yZGluZy4NCj4g DQo+ICJTZXJ2aWNlIEZ1bmN0aW9uIElkZW50aXR5IChTRklEKTogIEEgdW5pcXVlIGlkZW50aWZp ZXIgdGhhdA0KPiAgICAgICByZXByZXNlbnRzIGEgc2VydmljZSBmdW5jdGlvbi4gIFNGSURzIGFy ZSB1bmlxdWUgZm9yIGVhY2ggU0YNCj4gICAgICAgd2l0aGluIGFuIFNGQyBkb21haW4uwrINCj4g DQo+ICJTRkMtZG9tYWluIiBpcyB1c2VkIHdpdGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQg dGhlbiB0aGUgZHJhZnQNCj4gc3dpdGNoZXMgdG8gImFkbWluaXN0cmF0aXZlIGRvbWFpbsKyIGV2 ZXJ5d2hlcmUgZWxzZS4NCj4gDQo+IEFsc28sIHRoZSBkZWZpbml0aW9uIG9mIFNlcnZpY2UgRnVu Y3Rpb24gdXNlcyDCs2FkbWluaXN0cmF0aXZlIGRvbWFpbsKyDQo+IGluc3RlYWQgb2Ygb2YgIlNG Qy1kb21haW4iLg0KPiANCj4gDQo+IDIgLSANCj4gDQo+IEl0IHNlZW1zIHdlcmUgYXJlIG1pc3Np bmcgdGhlIGRlZmluaXRpb24gb2YgYSBpbnN0YW50aWF0ZWQgU2VydmljZQ0KPiBGdW5jdGlvbjoN Cj4gDQo+IEEgU2VydmljZSBGdW5jdGlvbiBpcyBzb21ldGhpbmcgbGlrZSBOQVQ0NCwgRmlyZXdh bGwsIGV0Yy4gSXQgZGVub3RlcyBhDQo+IGNsYXNzIG9mIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSB0 aGUgc2FtZSBmdW5jdGlvbi4NCj4gDQo+IEEgU0ZDIGlzIGFuIG9yZGVyZWQgc2V0IG9mIFNGcy4N Cj4gDQo+IEEgU0ZQIGlzIGFuIGluc3RhbnRpYXRpb24gb2YgYSBTRkMuIFNvLCB3aGF0IGRvIHdl IGNhbGwgdGhlIFNGcyB0aGF0IGFyZQ0KPiBpbnN0YW50aWF0ZWQgYW5kIHBhcnQgb2YgdGhlIFNG UD8gV2UgY2FuIG5vdCBjYWxsIHRoZW0gU2VydmljZSBGdW5jdGlvbnMNCj4gYWdhaW4gYmVjYXVz ZSB3ZSBhcmUgbm93IHRhbGtpbmcgYWJvdXQgYW4gc3BlY2lmaWMgc2VydmljZSBhbmQgdGhhdCAN CndvdWxkDQo+IGNhdXNlIGNvbmZ1c2lvbi4gRG8gd2UgY2FsbCB0aGVtICJTZXJ2aWNlIEZ1bmN0 aW9uIEluc3RhbmNlc8KyIGFuZA0KPiB0aGVyZWZvcmUgYSBTRlAgaXMgY29tcG9zZWQgb2YgYW4g b3JkZXJlZCBzZXQgb2YgU2VydmljZSBGdW5jdGlvbg0KPiBJbnN0YW5jZXM/DQo+IA0KPiBUaGFu a3MsDQo+IA0KPiAtUlANCj4gDQo+IE9uIDEvMjkvMTQsIDY6NTggQU0sICJQYXVsIFF1aW5uIChw YXVscSkiIDxwYXVscUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gPkhpIGZvbGtzLA0KPiA+DQo+ ID5UaGUgb25seSBjaGFuZ2UgdG8gdGhpcyB2ZXJzaW9uIGlzIHRoYXQgd2UgbW92ZWQgdG8gdHdv IGVkaXRvcnMsIGFuZA0KPiA+bGlzdGVkIHRoZSBvdGhlciBjby1hdXRob3JzIGluIGEgY29udHJp YnV0b3JzIHNlY3Rpb24uDQo+ID4NCj4gPkFzIGFsd2F5cywgeW91ciBjb21tZW50cyBhbmQgZmVl ZGJhY2sgaXMgYXBwcmVjaWF0ZWQhDQo+ID5QYXVsDQo+ID4NCj4gPg0KPiA+PiANCj4gPj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KPiA+PiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhdWwgUXVpbm4gYW5kIHBvc3RlZCB0byB0 aGUNCj4gPj4gSUVURiByZXBvc2l0b3J5Lg0KPiA+PiANCj4gPj4gTmFtZTogICAgICBkcmFmdC1x dWlubi1zZmMtYXJjaA0KPiA+PiBSZXZpc2lvbjogICAwNA0KPiA+PiBUaXRsZTogICAgICBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEFyY2hpdGVjdHVyZQ0KPiA+PiBEb2N1bWVudCBk YXRlOiAgIDIwMTQtMDEtMjgNCj4gPj4gR3JvdXA6ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4+IFBhZ2VzOiAgICAgIDIxDQo+ID4+IFVSTDogDQo+ID4+aHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQo+ID4+IFN0YXR1 czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFyY2gv DQo+ID4+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1x dWlubi1zZmMtYXJjaC0wNA0KPiA+PiBEaWZmOiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1xdWlubi1zZmMtYXJjaC0wNA0KPiA+PiANCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYXJjaGl0ZWN0dXJlIHVzZWQgZm9yIHRoZSBj cmVhdGlvbiBvZg0KPiA+PiAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIChTRkMpLiAgSXQgaW5j bHVkZXMgYXJjaGl0ZWN0dXJhbCBjb25jZXB0cywNCj4gPj4gICBwcmluY2lwbGVzLCBhbmQgY29t cG9uZW50cyB1c2VkIGluIHRoZSBjb25zdHJ1Y3Rpb24gb2YgY29tcG9zaXRlDQo+ID4+ICAgc2Vy dmljZXMgdGhyb3VnaCBkZXBsb3ltZW50IG9mIFNGQ3MgaW4gYSBuZXR3b3JrLiAgVGhpcyBkb2N1 bWVudCANCmRvZXMNCj4gPj4gICBub3QgcHJvcG9zZSBzb2x1dGlvbnMsIHByb3RvY29scywgb3Ig ZXh0ZW5zaW9ucyB0byBleGlzdGluZw0KPiA+PiAgIHByb3RvY29scy4NCj4gPj4gDQo+ID4+IA0K PiA+PiANCj4gPj4gDQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+c3VibWlzc2lvbg0KPiA+PiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiA+PiANCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4gDQo+ID4NCj4gPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5zZmMgbWFp bGluZyBsaXN0DQo+ID5zZmNAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --=_alternative 001214CA48257C7B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhp77yMPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgRm9yIFJlaW5hbGRvJ3Mg Y29tbWVudHMgMi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyBJJ20gbm90IHN1cmUgJnF1b3Q7U0YmcXVvdDsgJmFtcDsNCiZxdW90O1NGIGluc3RhbmNl JnF1b3Q7IGNvbmZ1c2UgbWUgaW4gdGhlIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEZvciBleGFtcGxlLCBOQVQ0NCB3aXRoIGEg cnVsZQ0KaXMgYSBTRiwgTkFUNDQgd2l0aCBhbm90aGVyIHJ1bGUgaXMgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hIGRpZmZlcmVudCBTRi4gJm5ic3A7VGhpcyBp cyBteSB1bmRlcnN0YW5kaW5nDQpiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaW48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBkcmFmdC4gJm5ic3A7IChPciBh IHNhbWUgU0YgYnV0DQpkaWZmZXJlbnQgU0YgaW5zdGFuY2VzPykgPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5XZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mcXVvdDtzZmMmcXVvdDsgJmx0O3NmYy1ib3VuY2VzQGlldGYub3JnJmd0OyAmbmJz cDsyMDE0LTAxLTMwDQoxNDoyNjo1NTo8YnI+DQo8YnI+DQomZ3Q7IEhpIFBhdWwsPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFJldmlld2luZyB0aGlzIGRyYWZ0IGFuZCBjb21wYXJpbmcgd2l0aCB0aGUg WWFuZyBtb2RlbCBJIGhhdmUgYSBjb3VwbGUNCm9mPGJyPg0KJmd0OyBjb21tZW50czxicj4NCiZn dDsgPGJyPg0KJmd0OyAxIC0gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgbm90aWNlZCB0aGF0IGEg U0ZJRCBhbmQgU0ZDLWRvbWFpbiBtaWdodCBuZWVkIG1vcmUgd29yZGluZy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgJnF1b3Q7U2VydmljZSBGdW5jdGlvbiBJZGVudGl0eSAoU0ZJRCk6ICZuYnNwO0Eg dW5pcXVlIGlkZW50aWZpZXINCnRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJl cHJlc2VudHMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiAmbmJzcDtTRklEcyBhcmUNCnVuaXF1ZSBmb3Ig ZWFjaCBTRjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2l0aGluIGFuIFNGQyBkb21h aW4uwrI8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7U0ZDLWRvbWFpbiZxdW90OyBpcyB1c2Vk IHdpdGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQgdGhlbg0KdGhlIGRyYWZ0PGJyPg0KJmd0 OyBzd2l0Y2hlcyB0byAmcXVvdDthZG1pbmlzdHJhdGl2ZSBkb21haW7CsiBldmVyeXdoZXJlIGVs c2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsc28sIHRoZSBkZWZpbml0aW9uIG9mIFNlcnZpY2Ug RnVuY3Rpb24gdXNlcyDCs2FkbWluaXN0cmF0aXZlIGRvbWFpbsKyPGJyPg0KJmd0OyBpbnN0ZWFk IG9mIG9mICZxdW90O1NGQy1kb21haW4mcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgMiAtIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCBzZWVtcyB3ZXJlIGFyZSBtaXNzaW5n IHRoZSBkZWZpbml0aW9uIG9mIGEgaW5zdGFudGlhdGVkIFNlcnZpY2U8YnI+DQomZ3Q7IEZ1bmN0 aW9uOjxicj4NCiZndDsgPGJyPg0KJmd0OyBBIFNlcnZpY2UgRnVuY3Rpb24gaXMgc29tZXRoaW5n IGxpa2UgTkFUNDQsIEZpcmV3YWxsLCBldGMuIEl0IGRlbm90ZXMNCmE8YnI+DQomZ3Q7IGNsYXNz IG9mIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSB0aGUgc2FtZSBmdW5jdGlvbi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgQSBTRkMgaXMgYW4gb3JkZXJlZCBzZXQgb2YgU0ZzLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBBIFNGUCBpcyBhbiBpbnN0YW50aWF0aW9uIG9mIGEgU0ZDLiBTbywgd2hhdCBkbyB3ZSBj YWxsIHRoZSBTRnMgdGhhdA0KYXJlPGJyPg0KJmd0OyBpbnN0YW50aWF0ZWQgYW5kIHBhcnQgb2Yg dGhlIFNGUD8gV2UgY2FuIG5vdCBjYWxsIHRoZW0gU2VydmljZSBGdW5jdGlvbnM8YnI+DQomZ3Q7 IGFnYWluIGJlY2F1c2Ugd2UgYXJlIG5vdyB0YWxraW5nIGFib3V0IGFuIHNwZWNpZmljIHNlcnZp Y2UgYW5kIHRoYXQNCndvdWxkPGJyPg0KJmd0OyBjYXVzZSBjb25mdXNpb24uIERvIHdlIGNhbGwg dGhlbSAmcXVvdDtTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlc8KyDQphbmQ8YnI+DQomZ3Q7IHRo ZXJlZm9yZSBhIFNGUCBpcyBjb21wb3NlZCBvZiBhbiBvcmRlcmVkIHNldCBvZiBTZXJ2aWNlIEZ1 bmN0aW9uPGJyPg0KJmd0OyBJbnN0YW5jZXM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgLVJQPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEvMjkvMTQs IDY6NTggQU0sICZxdW90O1BhdWwgUXVpbm4gKHBhdWxxKSZxdW90OyAmbHQ7cGF1bHFAY2lzY28u Y29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtIaSBmb2xrcyw8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtUaGUgb25seSBjaGFuZ2UgdG8gdGhpcyB2ZXJzaW9uIGlz IHRoYXQgd2UgbW92ZWQgdG8gdHdvIGVkaXRvcnMsDQphbmQ8YnI+DQomZ3Q7ICZndDtsaXN0ZWQg dGhlIG90aGVyIGNvLWF1dGhvcnMgaW4gYSBjb250cmlidXRvcnMgc2VjdGlvbi48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDtBcyBhbHdheXMsIHlvdXIgY29tbWVudHMgYW5kIGZlZWRiYWNr IGlzIGFwcHJlY2lhdGVkITxicj4NCiZndDsgJmd0O1BhdWw8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dDxicj4NCiZndDsgJmd0OyZn dDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVsIFF1aW5uIGFuZCBwb3N0 ZWQNCnRvIHRoZTxicj4NCiZndDsgJmd0OyZndDsgSUVURiByZXBvc2l0b3J5Ljxicj4NCiZndDsg Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ry YWZ0LXF1aW5uLXNmYy1hcmNoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBSZXZpc2lvbjogJm5ic3A7IDA0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluaW5nIChTRkMpDQpBcmNoaXRlY3R1cmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IERv Y3VtZW50IGRhdGU6ICZuYnNwOyAyMDE0LTAxLTI4PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBHcm91cDog Jm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7ICZndDsm Z3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzIxPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBVUkw6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7 Jmd0O2h0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1h cmNoLTA0LnR4dDxicj4NCiZndDsgJmd0OyZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2Zj LWFyY2gvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQ8YnI+DQom Z3Q7ICZndDsmZ3Q7IERpZmY6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYXJjaGl0ZWN0dXJlIHVz ZWQgZm9yIHRoZQ0KY3JlYXRpb24gb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyBTZXJ2aWNl IEZ1bmN0aW9uIENoYWlucyAoU0ZDKS4gJm5ic3A7SXQgaW5jbHVkZXMgYXJjaGl0ZWN0dXJhbA0K Y29uY2VwdHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgcHJpbmNpcGxlcywgYW5kIGNvbXBv bmVudHMgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uDQpvZiBjb21wb3NpdGU8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZuYnNwOyBzZXJ2aWNlcyB0aHJvdWdoIGRlcGxveW1lbnQgb2YgU0ZDcyBpbiBhIG5l dHdvcmsuDQombmJzcDtUaGlzIGRvY3VtZW50IGRvZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNw OyBub3QgcHJvcG9zZSBzb2x1dGlvbnMsIHByb3RvY29scywgb3IgZXh0ZW5zaW9ucyB0bw0KZXhp c3Rpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyBwcm90b2NvbHMuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZQ0KdGltZSBvZjxicj4NCiZndDsgJmd0OyZndDtz dWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCiZndDsgJmd0OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsgJmd0 OyZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7c2ZjQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNmYyBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 001214CA48257C7B_=-- From kevin.ma@azukisystems.com Sun Feb 9 20:33:42 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFED1A07A8 for ; Sun, 9 Feb 2014 20:33:42 -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 Mkbvmgy441W0 for ; Sun, 9 Feb 2014 20:33:40 -0800 (PST) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfa.amsl.com (Postfix) with ESMTP id 786F91A0237 for ; Sun, 9 Feb 2014 20:33:40 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB012.mail.lan) by p01c11o149.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 0a658f25.0.28114.00-382.74047.p01c11o149.mxlogic.net (envelope-from ); Sun, 09 Feb 2014 21:33:40 -0700 (MST) X-MXL-Hash: 52f856a474508dd6-c3c12b3513252a4359f15355b66ead86c9e5916f Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Sun, 9 Feb 2014 23:33:30 -0500 From: Kevin J Ma To: "sfc@ietf.org" Date: Sun, 9 Feb 2014 23:33:29 -0500 Thread-Topic: New Version Notification for draft-ma-sfc-decomposition-00.txt Thread-Index: Ac8mFolNGhFB4p2cQaqKL8glsWmYxgAAAcIg Message-ID: <291CC3F9E50E7641901A54E85D0977C6D541655C03@MAILR002.mail.lan> References: <20140210041400.31246.83214.idtracker@ietfa.amsl.com> In-Reply-To: <20140210041400.31246.83214.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 04:33:42 -0000 SGkgQWxsLA0KDQogIEkndmUgdXBsb2FkZWQgYSBuZXcgZHJhZnQgZGVhbGluZyB3aXRoIHNlcnZp Y2UgZGVjb21wb3NpdGlvbi4NCiAgSW4gc29tZSByZXNwZWN0cyBpdCBhbHNvIGFkZHJlc3NlcyBz b21lIG9mIHRoZSByZWNlbnQgZGlzY3Vzc2lvbg0KICBhYm91dCBiaWRpcmVjdGlvbmFsIGZsb3cg YXNzb2NpYXRpb24gYW5kIHJlLWNsYXNzaWZpY2F0aW9uLCB1c2luZw0KICBhbiBITFMgdmlkZW8g ZGVsaXZlcnkgb3B0aW1pemF0aW9uIHVzZSBjYXNlLiAgQ29tbWVudHMgd2VsY29tZS4NCg0KSmlt L1Rob21hcywNCiANCiAgSWYgdGhlcmUgaXMgc3BhY2UgaW4gdGhlIGFnZW5kYSwgSSB3b3VsZCBs aWtlIHRvIHJlcXVlc3QgYSBzbG90Lg0KICBUaGUgZHJhZnQgcHJpbWFyaWx5IHJlbGF0ZXMgdG8g dXNlIGNhc2VzLg0KDQp0aGFueC4NCg0KLS0gIEtldmluIEouIE1hDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAwOSwgMjAxNCAx MToxNCBQTQ0KVG86IEtldmluIEogTWE7IEtldmluIEogTWENClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWEtc2ZjLWRlY29tcG9zaXRpb24tMDAudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hLXNmYy1kZWNvbXBvc2l0aW9uLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXZpbiBKLiBNYSBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWEtc2ZjLWRlY29tcG9z aXRpb24NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlTRkMgU2VydmljZSBEZWNvbXBvc2l0aW9uDQpE b2N1bWVudCBkYXRlOgkyMDE0LTAyLTEwDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6CQkxMg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LW1hLXNmYy1kZWNvbXBvc2l0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hLXNmYy1kZWNvbXBvc2l0 aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1h LXNmYy1kZWNvbXBvc2l0aW9uLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRp c2N1c3NlcyB0aGUgcm9sZSBvZiBjb21wb3NpdGUgKG1vbm9saXRoaWMpIHNlcnZpY2UNCiAgIGZ1 bmN0aW9ucyBpbiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLCBhbmQgZGVzY3JpYmVzIGEgbWV0 aG9kIGZvcg0KICAgc3VwcG9ydGluZyBjb21wb3NpdGUgc2VydmljZSBmdW5jdGlvbiBkZWNvbXBv c2l0aW9uLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From repenno@cisco.com Mon Feb 10 06:00:34 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9118C1A0835; Mon, 10 Feb 2014 06:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aaaHP1YvDMX; Mon, 10 Feb 2014 06:00:29 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBB91A083F; Mon, 10 Feb 2014 06:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17557; q=dns/txt; s=iport; t=1392040828; x=1393250428; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=6WJNwNh1OMCBOYd9UL6u8WvyHnCmDlqoAfWABEh31T0=; b=cYCj091q7aLkJPwcSUhOqbUGfTTNZ0DtH0HN6UbNrgICr4GAR297IXA7 OJeCdYpzu6UokrqPeWk4L0rEnNX9H1EmOQas88TRzN+Da2NBgSsds1zKP fbsaWGHO3LE/2d2eFBKV2Rnnkrb+P64y+xzTtj/kw4E4tYfa0SG/+LnPR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGADPb+FKtJV2b/2dsb2JhbABQCYJIRDhRBoMBs2iIVBh4FnSCJQEBAQMBAQEBawkCBQ0BCBEBAgECAScFBCULFAMGCAIEDgUJEodiCAgFjFibdwagWBeOIkAKDQQHCYJggU8EmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208,217";a="19246149" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 10 Feb 2014 14:00:27 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1AE0R43032703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 14:00:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 08:00:27 -0600 From: "Reinaldo Penno (repenno)" To: "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoA== Date: Mon, 10 Feb 2014 14:00:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.70.161] Content-Type: multipart/alternative; boundary="_000_CF1E188C8D03repennociscocom_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:00:34 -0000 --_000_CF1E188C8D03repennociscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBTZXJ2aWNlIEZ1bmN0aW9uIE5BVDQ0IHJlcHJlc2VudHMgdGhlIGZ1bmN0aW9u cyBhIE5BVDQ0IHBlcmZvcm1zLCAgaS5lLiBUcmFuc2xhdGUgc291cmNlIElQdjQgcGFja2V0cywg Y3JlYXRlIG1hcHBpbmdzLCBldGMuIEJ1dCBhIFNlcnZpY2UgRnVuY3Rpb24gZG9lcyBub3QgcHJv Y2VzcyBwYWNrZXRzLCBpdCBpcyBqdXN0IGEgdGVtcGxhdGUgZGVmaW5pdGlvbi4NCg0KQSBzZXJ2 aWNlIGluc3RhbmNlIGFjdHVhbGx5IHByb2Nlc3NlcyBwYWNrZXRzIGFuZCBpcyBwYXJ0IG9mIGEg U2VydmljZSBQYXRoLiAgU28sIHR3byBkaWZmZXJlbnQgTkFUNDQgZGV2aWNlcyB0aGF0IHByb2Nl c3MgcGFja2V0cyBhcmUgY2xhc3NpZmllZCB1bmRlciB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9u IGJ1dCByZXByZXNlbnQgZGlmZmVyZW50IGluc3RhbmNlcy4NCg0KDQpGcm9tOiAibWVuZy53ZWky QHp0ZS5jb20uY248bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPiIgPG1lbmcud2VpMkB6dGUu Y29tLmNuPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj4+DQpEYXRlOiBTdW5kYXksIEZlYnJ1 YXJ5IDksIDIwMTQgYXQgNzoxNSBQTQ0KVG86IENpc2NvIEVtcGxveWVlIDxyZXBlbm5vQGNpc2Nv LmNvbTxtYWlsdG86cmVwZW5ub0BjaXNjby5jb20+Pg0KQ2M6ICJQYXVsIFF1aW5uIChwYXVscSki IDxwYXVscUBjaXNjby5jb208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAic2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ Piwgc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQoNCg0KSGmjrA0KDQogIEZvciBSZWluYWxk bydzIGNvbW1lbnRzIDIuDQogIEknbSBub3Qgc3VyZSAiU0YiICYgIlNGIGluc3RhbmNlIiBjb25m dXNlIG1lIGluIHRoZSBkcmFmdC4NCg0KICBGb3IgZXhhbXBsZSwgTkFUNDQgd2l0aCBhIHJ1bGUg aXMgYSBTRiwgTkFUNDQgd2l0aCBhbm90aGVyIHJ1bGUgaXMNCmEgZGlmZmVyZW50IFNGLiAgVGhp cyBpcyBteSB1bmRlcnN0YW5kaW5nIGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBpbg0KdGhlIGRy YWZ0LiAgIChPciBhIHNhbWUgU0YgYnV0IGRpZmZlcmVudCBTRiBpbnN0YW5jZXM/KQ0KDQoNClRo YW5rcywNCldlaQ0KDQoNCiJzZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc+PiAgMjAxNC0wMS0zMCAxNDoyNjo1NToNCg0KPiBIaSBQYXVsLA0KPg0K PiBSZXZpZXdpbmcgdGhpcyBkcmFmdCBhbmQgY29tcGFyaW5nIHdpdGggdGhlIFlhbmcgbW9kZWwg SSBoYXZlIGEgY291cGxlIG9mDQo+IGNvbW1lbnRzDQo+DQo+IDEgLQ0KPg0KPiBJIG5vdGljZWQg dGhhdCBhIFNGSUQgYW5kIFNGQy1kb21haW4gbWlnaHQgbmVlZCBtb3JlIHdvcmRpbmcuDQo+DQo+ ICJTZXJ2aWNlIEZ1bmN0aW9uIElkZW50aXR5IChTRklEKTogIEEgdW5pcXVlIGlkZW50aWZpZXIg dGhhdA0KPiAgICAgICByZXByZXNlbnRzIGEgc2VydmljZSBmdW5jdGlvbi4gIFNGSURzIGFyZSB1 bmlxdWUgZm9yIGVhY2ggU0YNCj4gICAgICAgd2l0aGluIGFuIFNGQyBkb21haW4uqfcNCj4NCj4g IlNGQy1kb21haW4iIGlzIHVzZWQgd2l0aGluIHRoZSBkZWZpbml0aW9uIGFib3ZlIGJ1dCB0aGVu IHRoZSBkcmFmdA0KPiBzd2l0Y2hlcyB0byAiYWRtaW5pc3RyYXRpdmUgZG9tYWluqfcgZXZlcnl3 aGVyZSBlbHNlLg0KPg0KPiBBbHNvLCB0aGUgZGVmaW5pdGlvbiBvZiBTZXJ2aWNlIEZ1bmN0aW9u IHVzZXMgqfhhZG1pbmlzdHJhdGl2ZSBkb21haW6p9w0KPiBpbnN0ZWFkIG9mIG9mICJTRkMtZG9t YWluIi4NCj4NCj4NCj4gMiAtDQo+DQo+IEl0IHNlZW1zIHdlcmUgYXJlIG1pc3NpbmcgdGhlIGRl ZmluaXRpb24gb2YgYSBpbnN0YW50aWF0ZWQgU2VydmljZQ0KPiBGdW5jdGlvbjoNCj4NCj4gQSBT ZXJ2aWNlIEZ1bmN0aW9uIGlzIHNvbWV0aGluZyBsaWtlIE5BVDQ0LCBGaXJld2FsbCwgZXRjLiBJ dCBkZW5vdGVzIGENCj4gY2xhc3Mgb2Ygc2VydmljZXMgdGhhdCBwcm92aWRlIHRoZSBzYW1lIGZ1 bmN0aW9uLg0KPg0KPiBBIFNGQyBpcyBhbiBvcmRlcmVkIHNldCBvZiBTRnMuDQo+DQo+IEEgU0ZQ IGlzIGFuIGluc3RhbnRpYXRpb24gb2YgYSBTRkMuIFNvLCB3aGF0IGRvIHdlIGNhbGwgdGhlIFNG cyB0aGF0IGFyZQ0KPiBpbnN0YW50aWF0ZWQgYW5kIHBhcnQgb2YgdGhlIFNGUD8gV2UgY2FuIG5v dCBjYWxsIHRoZW0gU2VydmljZSBGdW5jdGlvbnMNCj4gYWdhaW4gYmVjYXVzZSB3ZSBhcmUgbm93 IHRhbGtpbmcgYWJvdXQgYW4gc3BlY2lmaWMgc2VydmljZSBhbmQgdGhhdCB3b3VsZA0KPiBjYXVz ZSBjb25mdXNpb24uIERvIHdlIGNhbGwgdGhlbSAiU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXOp 9yBhbmQNCj4gdGhlcmVmb3JlIGEgU0ZQIGlzIGNvbXBvc2VkIG9mIGFuIG9yZGVyZWQgc2V0IG9m IFNlcnZpY2UgRnVuY3Rpb24NCj4gSW5zdGFuY2VzPw0KPg0KPiBUaGFua3MsDQo+DQo+IC1SUA0K Pg0KPiBPbiAxLzI5LzE0LCA2OjU4IEFNLCAiUGF1bCBRdWlubiAocGF1bHEpIiA8cGF1bHFAY2lz Y28uY29tPG1haWx0bzpwYXVscUBjaXNjby5jb20+PiB3cm90ZToNCj4NCj4gPkhpIGZvbGtzLA0K PiA+DQo+ID5UaGUgb25seSBjaGFuZ2UgdG8gdGhpcyB2ZXJzaW9uIGlzIHRoYXQgd2UgbW92ZWQg dG8gdHdvIGVkaXRvcnMsIGFuZA0KPiA+bGlzdGVkIHRoZSBvdGhlciBjby1hdXRob3JzIGluIGEg Y29udHJpYnV0b3JzIHNlY3Rpb24uDQo+ID4NCj4gPkFzIGFsd2F5cywgeW91ciBjb21tZW50cyBh bmQgZmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQhDQo+ID5QYXVsDQo+ID4NCj4gPg0KPiA+Pg0KPiA+ PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQo+ID4+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGF1bCBRdWlubiBhbmQgcG9zdGVk IHRvIHRoZQ0KPiA+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4+DQo+ID4+IE5hbWU6ICAgICAgZHJh ZnQtcXVpbm4tc2ZjLWFyY2gNCj4gPj4gUmV2aXNpb246ICAgMDQNCj4gPj4gVGl0bGU6ICAgICAg U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUNCj4gPj4gRG9jdW1l bnQgZGF0ZTogICAyMDE0LTAxLTI4DQo+ID4+IEdyb3VwOiAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPiA+PiBQYWdlczogICAgICAyMQ0KPiA+PiBVUkw6DQo+ID4+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQo+ID4+IFN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlu bi1zZmMtYXJjaC8NCj4gPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0DQo+ID4+IERpZmY6DQo+ID4+DQo+ID4+IEFic3Ry YWN0Og0KPiA+PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSB1c2Vk IGZvciB0aGUgY3JlYXRpb24gb2ZodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1xdWlubi1zZmMtYXJjaC0wNA0KPiA+PiAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIChTRkMp LiAgSXQgaW5jbHVkZXMgYXJjaGl0ZWN0dXJhbCBjb25jZXB0cywNCj4gPj4gICBwcmluY2lwbGVz LCBhbmQgY29tcG9uZW50cyB1c2VkIGluIHRoZSBjb25zdHJ1Y3Rpb24gb2YgY29tcG9zaXRlDQo+ ID4+ICAgc2VydmljZXMgdGhyb3VnaCBkZXBsb3ltZW50IG9mIFNGQ3MgaW4gYSBuZXR3b3JrLiAg VGhpcyBkb2N1bWVudCBkb2VzDQo+ID4+ICAgbm90IHByb3Bvc2Ugc29sdXRpb25zLCBwcm90b2Nv bHMsIG9yIGV4dGVuc2lvbnMgdG8gZXhpc3RpbmcNCj4gPj4gICBwcm90b2NvbHMuDQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+c3VibWlzc2lvbg0KPiA+PiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+Pg0KPiA+DQo+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+c2ZjIG1h aWxpbmcgbGlzdA0KPiA+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_CF1E188C8D03repennociscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGksPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgU2VydmljZSBGdW5jdGlvbiBOQVQ0NCByZXBy ZXNlbnRzIHRoZSBmdW5jdGlvbnMgYSBOQVQ0NCBwZXJmb3JtcywgJm5ic3A7aS5lLiBUcmFuc2xh dGUgc291cmNlIElQdjQgcGFja2V0cywgY3JlYXRlIG1hcHBpbmdzLCBldGMuIEJ1dCBhIFNlcnZp Y2UgRnVuY3Rpb24gZG9lcyBub3QgcHJvY2VzcyBwYWNrZXRzLCBpdCBpcyBqdXN0IGEgdGVtcGxh dGUgZGVmaW5pdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgc2VydmljZSBp bnN0YW5jZSBhY3R1YWxseSBwcm9jZXNzZXMgcGFja2V0cyBhbmQgaXMgcGFydCBvZiBhIFNlcnZp Y2UgUGF0aC4gJm5ic3A7U28sIHR3byBkaWZmZXJlbnQgTkFUNDQgZGV2aWNlcyB0aGF0IHByb2Nl c3MgcGFja2V0cyBhcmUgY2xhc3NpZmllZCB1bmRlciB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9u IGJ1dCByZXByZXNlbnQgZGlmZmVyZW50IGluc3RhbmNlcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0 bzptZW5nLndlaTJAenRlLmNvbS5jbiI+bWVuZy53ZWkyQHp0ZS5jb20uY248L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24iPm1lbmcud2VpMkB6dGUuY29t LmNuPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z cGFuPlN1bmRheSwgRmVicnVhcnkgOSwgMjAxNCBhdCA3OjE1IFBNPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Q2lzY28gRW1wbG95ZWUgJmx0OzxhIGhyZWY9 Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+cmVwZW5ub0BjaXNjby5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O1BhdWwgUXVp bm4gKHBhdWxxKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxxQGNpc2NvLmNvbSI+cGF1 bHFAY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4mZ3Q7LCBzZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFJlOiBbc2ZjXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPGZvbnQgc2l6 ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+SGmjrDwvZm9udD4gPGJyPg0KPGJyPg0KPGZvbnQgc2l6 ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEZvciBSZWluYWxkbydzIGNvbW1lbnRzIDIu PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSSdt IG5vdCBzdXJlICZxdW90O1NGJnF1b3Q7ICZhbXA7ICZxdW90O1NGIGluc3RhbmNlJnF1b3Q7IGNv bmZ1c2UgbWUgaW4gdGhlIGRyYWZ0LjwvZm9udD48YnI+DQo8YnI+DQo8Zm9udCBzaXplPSIyIiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgRm9yIGV4YW1wbGUsIE5BVDQ0IHdpdGggYSBydWxlIGlz IGEgU0YsIE5BVDQ0IHdpdGggYW5vdGhlciBydWxlIGlzDQo8L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6 ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+YSBkaWZmZXJlbnQgU0YuICZuYnNwO1RoaXMgaXMgbXkg dW5kZXJzdGFuZGluZyBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaW48L2ZvbnQ+PGJyPg0KPGZv bnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIGRyYWZ0LiAmbmJzcDsgKE9yIGEgc2Ft ZSBTRiBidXQgZGlmZmVyZW50IFNGIGluc3RhbmNlcz8pDQo8L2ZvbnQ+PGJyPg0KPGJyPg0KPGZv bnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD48YnI+DQo8Zm9udCBz aXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250PiA8YnI+DQo8Zm9udCBzaXpl PSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5XZWk8L2ZvbnQ+IDxicj4NCjxicj4NCjxicj4NCjx0dD48 Zm9udCBzaXplPSIyIj4mcXVvdDtzZmMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyAmbmJzcDsyMDE0LTAx LTMwIDE0OjI2OjU1Ojxicj4NCjxicj4NCiZndDsgSGkgUGF1bCw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgUmV2aWV3aW5nIHRoaXMgZHJhZnQgYW5kIGNvbXBhcmluZyB3aXRoIHRoZSBZYW5nIG1vZGVs IEkgaGF2ZSBhIGNvdXBsZSBvZjxicj4NCiZndDsgY29tbWVudHM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgMSAtIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIG5vdGljZWQgdGhhdCBhIFNGSUQgYW5kIFNG Qy1kb21haW4gbWlnaHQgbmVlZCBtb3JlIHdvcmRpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZx dW90O1NlcnZpY2UgRnVuY3Rpb24gSWRlbnRpdHkgKFNGSUQpOiAmbmJzcDtBIHVuaXF1ZSBpZGVu dGlmaWVyIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlcHJlc2VudHMgYSBz ZXJ2aWNlIGZ1bmN0aW9uLiAmbmJzcDtTRklEcyBhcmUgdW5pcXVlIGZvciBlYWNoIFNGPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoaW4gYW4gU0ZDIGRvbWFpbi6p9zxicj4NCiZn dDsgPGJyPg0KJmd0OyAmcXVvdDtTRkMtZG9tYWluJnF1b3Q7IGlzIHVzZWQgd2l0aGluIHRoZSBk ZWZpbml0aW9uIGFib3ZlIGJ1dCB0aGVuIHRoZSBkcmFmdDxicj4NCiZndDsgc3dpdGNoZXMgdG8g JnF1b3Q7YWRtaW5pc3RyYXRpdmUgZG9tYWluqfcgZXZlcnl3aGVyZSBlbHNlLjxicj4NCiZndDsg PGJyPg0KJmd0OyBBbHNvLCB0aGUgZGVmaW5pdGlvbiBvZiBTZXJ2aWNlIEZ1bmN0aW9uIHVzZXMg qfhhZG1pbmlzdHJhdGl2ZSBkb21haW6p9zxicj4NCiZndDsgaW5zdGVhZCBvZiBvZiAmcXVvdDtT RkMtZG9tYWluJnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIgLSA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSXQgc2VlbXMgd2VyZSBhcmUgbWlzc2luZyB0aGUgZGVmaW5pdGlv biBvZiBhIGluc3RhbnRpYXRlZCBTZXJ2aWNlPGJyPg0KJmd0OyBGdW5jdGlvbjo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgQSBTZXJ2aWNlIEZ1bmN0aW9uIGlzIHNvbWV0aGluZyBsaWtlIE5BVDQ0LCBG aXJld2FsbCwgZXRjLiBJdCBkZW5vdGVzIGE8YnI+DQomZ3Q7IGNsYXNzIG9mIHNlcnZpY2VzIHRo YXQgcHJvdmlkZSB0aGUgc2FtZSBmdW5jdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBTRkMg aXMgYW4gb3JkZXJlZCBzZXQgb2YgU0ZzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBIFNGUCBpcyBh biBpbnN0YW50aWF0aW9uIG9mIGEgU0ZDLiBTbywgd2hhdCBkbyB3ZSBjYWxsIHRoZSBTRnMgdGhh dCBhcmU8YnI+DQomZ3Q7IGluc3RhbnRpYXRlZCBhbmQgcGFydCBvZiB0aGUgU0ZQPyBXZSBjYW4g bm90IGNhbGwgdGhlbSBTZXJ2aWNlIEZ1bmN0aW9uczxicj4NCiZndDsgYWdhaW4gYmVjYXVzZSB3 ZSBhcmUgbm93IHRhbGtpbmcgYWJvdXQgYW4gc3BlY2lmaWMgc2VydmljZSBhbmQgdGhhdCB3b3Vs ZDxicj4NCiZndDsgY2F1c2UgY29uZnVzaW9uLiBEbyB3ZSBjYWxsIHRoZW0gJnF1b3Q7U2Vydmlj ZSBGdW5jdGlvbiBJbnN0YW5jZXOp9yBhbmQ8YnI+DQomZ3Q7IHRoZXJlZm9yZSBhIFNGUCBpcyBj b21wb3NlZCBvZiBhbiBvcmRlcmVkIHNldCBvZiBTZXJ2aWNlIEZ1bmN0aW9uPGJyPg0KJmd0OyBJ bnN0YW5jZXM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLVJQPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEvMjkvMTQsIDY6NTggQU0sICZxdW90O1Bh dWwgUXVpbm4gKHBhdWxxKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxxQGNpc2NvLmNv bSI+cGF1bHFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZn dDtIaSBmb2xrcyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtUaGUgb25seSBjaGFuZ2Ug dG8gdGhpcyB2ZXJzaW9uIGlzIHRoYXQgd2UgbW92ZWQgdG8gdHdvIGVkaXRvcnMsIGFuZDxicj4N CiZndDsgJmd0O2xpc3RlZCB0aGUgb3RoZXIgY28tYXV0aG9ycyBpbiBhIGNvbnRyaWJ1dG9ycyBz ZWN0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0FzIGFsd2F5cywgeW91ciBjb21t ZW50cyBhbmQgZmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQhPGJyPg0KJmd0OyAmZ3Q7UGF1bDxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBh dWwgUXVpbm4gYW5kIHBvc3RlZCB0byB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IElFVEYgcmVwb3Np dG9yeS48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgTmFtZTogJm5ic3A7 ICZuYnNwOyAmbmJzcDtkcmFmdC1xdWlubi1zZmMtYXJjaDxicj4NCiZndDsgJmd0OyZndDsgUmV2 aXNpb246ICZuYnNwOyAwNDxicj4NCiZndDsgJmd0OyZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmU8YnI+DQom Z3Q7ICZndDsmZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAyMDE0LTAxLTI4PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248 YnI+DQomZ3Q7ICZndDsmZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzIxPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0PC9hPjxicj4NCiZndDsg Jmd0OyZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFyY2gvIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLzwvYT48 YnI+DQomZ3Q7ICZndDsmZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtYXJjaC0wNCI+DQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlubi1zZmMtYXJjaC0wNDwvYT48YnI+ DQomZ3Q7ICZndDsmZ3Q7IERpZmY6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYXJjaGl0ZWN0dXJl IHVzZWQgZm9yIHRoZSBjcmVhdGlvbiBvZjwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1xdWlubi1zZmMtYXJjaC0wNCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQ8L2E+PGZvbnQgc2l6ZT0i MiI+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgKFNG QykuICZuYnNwO0l0IGluY2x1ZGVzIGFyY2hpdGVjdHVyYWwgY29uY2VwdHMsPGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgcHJpbmNpcGxlcywgYW5kIGNvbXBvbmVudHMgdXNlZCBpbiB0aGUgY29u c3RydWN0aW9uIG9mIGNvbXBvc2l0ZTxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7IHNlcnZpY2Vz IHRocm91Z2ggZGVwbG95bWVudCBvZiBTRkNzIGluIGEgbmV0d29yay4gJm5ic3A7VGhpcyBkb2N1 bWVudCBkb2VzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgbm90IHByb3Bvc2Ugc29sdXRpb25z LCBwcm90b2NvbHMsIG9yIGV4dGVuc2lvbnMgdG8gZXhpc3Rpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZuYnNwOyBwcm90b2NvbHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0O3N1Ym1pc3Npb248YnI+DQomZ3Q7ICZndDsm Z3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRo ZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg c2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPC9hPjxicj4NCjwvZm9udD48L3R0PjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CF1E188C8D03repennociscocom_-- From paulq@cisco.com Mon Feb 10 06:25:26 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6231A0870 for ; Mon, 10 Feb 2014 06:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTboPumS4Prb for ; Mon, 10 Feb 2014 06:25:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52E1A089B for ; Mon, 10 Feb 2014 06:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3597; q=dns/txt; s=iport; t=1392042286; x=1393251886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wR64dQVMOn+u/RKEY295vB+tLtpmJ3VQybVMu1V061k=; b=CVyAmx+coFy2AFqUZt4xRruBcit/xMCWl0BpIpQFqPbu4Zi0/sC3Bhip CQbgov0wIkqQUhZVDpMTV01TY9oQkKe07L69V+9TUDPjkBPyhyycNL2gM GXYHTI9/zSrnzJ2NCnqPr/oi26imw2/rTLYkCEMD8QGYt/p6811QC9ZNn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFAJbg+FKtJV2d/2dsb2JhbABZgww4UQa/PYEQFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEBAwEBHwkHJwsUAwYIAgQOBQkSh2IICAXJPheOSjMHBoMegRQEmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208";a="302973463" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 10 Feb 2014 14:24:46 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AEOjN7011072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 14:24:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 08:24:44 -0600 From: "Paul Quinn (paulq)" To: Linda Dunbar Thread-Topic: [sfc] New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnK82AgAGWpYD//6QNoIAGm7+A Date: Mon, 10 Feb 2014 14:24:44 +0000 Message-ID: <3AEE1119-4D64-42B7-88D7-23BAB6C8C5F2@cisco.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.com> <80DBC0E1-FBF6-432F-9D12-989D9B798705@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C7922A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7922A@dfweml701-chm.china.huawei.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:25:26 -0000 Linda, On Feb 6, 2014, at 10:36 AM, Linda Dunbar wrote: > Paul,=20 >=20 > See my suggestion below: >=20 > -----Original Message----- >=20 >=20 >> The first bullet of 3.2 stated that SF is not longer viewed as a bump in= the wire. Then how do you describe the topology between SFs and their netw= ork locators or Service Function Forwarders? Isn't it either "bump in a wi= re" or "one armed"? >=20 > It's not a matter of topology, rather, instead of the SF being "inserted"= as a bump, it is "consumed", regardless of placement in the network. The = term Overlay Service Topology is used in the doc to describes the service c= haining topology. >=20 > [Linda] Even with Service Functions being "consumed", it is still very im= portant to SFF or/and SNF on "Where to steer traffic to consume the "servic= e function"", correct?=20 Traffic is steered to the "right" function, as opposed to having that funct= ion simply be inline because of topology. More interestingly, a subset of = traffic might go to one SF, whereas other traffic might be steered to anoth= er. =20 >=20 > When the "to be consumed" service functions are placed as "One Armed", th= e SFF is in full control of where the next hop is. If the "to be consumed s= ervice functions" are placed as "bump in the wire", the SF has to be inform= ed of the next hop after the treatment.=20 >=20 >=20 > Linda >=20 >>=20 >> Linda >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn=20 >> (paulq) >> Sent: Wednesday, January 29, 2014 8:58 AM >> To: sfc@ietf.org >> Subject: [sfc] Fwd: New Version Notification for=20 >> draft-quinn-sfc-arch-04.txt >>=20 >> Hi folks, >>=20 >> The only change to this version is that we moved to two editors, and lis= ted the other co-authors in a contributors section. >>=20 >> As always, your comments and feedback is appreciated! >> Paul >>=20 >>=20 >>>=20 >>> A new version of I-D, draft-quinn-sfc-arch-04.txt has been=20 >>> successfully submitted by Paul Quinn and posted to the IETF=20 >>> repository. >>>=20 >>> Name: draft-quinn-sfc-arch >>> Revision: 04 >>> Title: Service Function Chaining (SFC) Architecture >>> Document date: 2014-01-28 >>> Group: Individual Submission >>> Pages: 21 >>> URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arc= h-04.txt >>> Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ >>> Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-04 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch= -04 >>>=20 >>> Abstract: >>> This document describes an architecture used for the creation of =20 >>> Service Function Chains (SFC). It includes architectural concepts, =20 >>> principles, and components used in the construction of composite =20 >>> services through deployment of SFCs in a network. This document does = =20 >>> not propose solutions, protocols, or extensions to existing =20 >>> protocols. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at tools.i= etf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Mon Feb 10 07:03:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659541A0871; Mon, 10 Feb 2014 07:03:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4NF9n8Yw2gj; Mon, 10 Feb 2014 07:03:19 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A01A086C; Mon, 10 Feb 2014 07:03:19 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 07:03:18 -0800 From: Ron Parker To: "Reinaldo Penno (repenno)" , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xg Date: Mon, 10 Feb 2014 15:03:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A2F4BMBX021W3CA2exch_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:03:23 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A2F4BMBX021W3CA2exch_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 TWVuZywNCg0KSSB2aWV3IHRoZSBpbnN0YW5jZXMgaXNzdWUgaW4gMiBkaWZmZXJlbnQgd2F5cy4N Cg0KRmlyc3QsIGEgdHlwZSBvZiBzZXJ2aWNlIGZ1bmN0aW9uIChpLmUuLCBOQVQ0NCkgbWF5IGV4 aXN0IHdpdGggbXVsdGlwbGUgcG9saWN5IHNldHMuICAgIEZvciB0aGlzIHB1cnBvc2UsIHRoZSBk ZXBsb3ltZW50IG9mIGEgc2VydmljZSBmdW5jdGlvbiB3aXRoIGEgcG9saWN5IHNldCBpcyBhbiBp bnN0YW5jZS4gICBGb3IgZXhhbXBsZSwgTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUEgaXMgb25lIGlu c3RhbmNlIHdoaWxlIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1CIGlzIGFub3RoZXIgaW5zdGFuY2Uu ICAgRnJvbSBhIGNoYWluIHBlcnNwZWN0aXZlLCBjaGFpbiAxIG1pZ2h0IGNvbnRhaW4gTkFUNDQt d2l0aC1wb2xpY3ktc2V0LUEgd2hpbGUgY2hhaW4gMiBtaWdodCBjb250YWluIE5BVDQ0LXdpdGgt cG9saWN5LXNldC1CLiAgICBUaGUgYWN0dWFsIGxvY2F0aW9uIG9mIHRoZSB0aG9zZSAyIGluc3Rh bmNlcyBpcyBhcmJpdHJhcnkgLSBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZXkgYXJlIGxvY2F0ZWQg dG8gdGhlIHNhbWUgcGh5c2ljYWwgYW5kL29yIHZpcnR1YWwgY29tcHV0ZSBub2RlIG9yIGRpZmZl cmVudC4gICBJdCBpcyBldmVuIHBvc3NpYmxlIHRoYXQgdGhlIDIgbG9naWNhbCBpbnN0YW5jZXMg YXJlIHJlYWxpemVkIGJ5IHRoZSBleGFjdCBzYW1lIHNldCBvZiBwcm9jZXNzZXMgZXhlY3V0aW5n IG9uIHRoZSBleGFjdCBzYW1lIGNvbXB1dGUgbm9kZSwgb3IgYXQgdGhlIG90aGVyIGV4dHJlbWUs IHRoZXkgY291bGQgYmUgbG9jYXRlZCBpbiBkaWZmZXJlbnQgY291bnRyaWVzLg0KDQpTZWNvbmQs IGEgcGFydGljdWxhciBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIChpLmUuLCBOQVQ0NC13aXRo LXBvbGljeS1zZXQtQSkgbWF5LCBpdHNlbGYsIGJlIG11bHRpcGx5IGluc3RhbnRpYXRlZCBmb3Ig bG9hZCBiYWxhbmNpbmcgb3IgcmVzaWxpZW5jeSBwdXJwb3Nlcy4gICBJIGNvbnNpZGVyIHRoaXMg YXNwZWN0IHdpdGhpbiB0aGUgcmVhbG0gb2YgobBjaGFpbiB0byBwYXRoIHJlZHVjdGlvbqGxLiAg IFRoYXQsIGlzIHRoZSBoaWdoIGxldmVsIGNoYWluIHNwZWNpZmllZCB0aGUgbmVlZCBmb3IgTkFU NDQtd2l0aC1wb2xpY3ktc2V0LUEsIGJ1dCB0aGUgYWN0dWFsIGNoYWluIGludm9rZWQgZm9yIGEg cGFydGljdWxhciBmbG93IG11c3QgZW5kIHVwIHN0ZWVyaW5nIHRoZSB0cmFmZmljIHRvIHNvbWUg cGFydGljdWxhciBpbnN0YW5jZSBvZiB0aGF0IGxvZ2ljYWwgc2VydmljZSBmdW5jdGlvbi4NCg0K ICAgUm9uDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEw LCAyMDE0IDk6MDAgQU0NClRvOiBtZW5nLndlaTJAenRlLmNvbS5jbg0KQ2M6IFBhdWwgUXVpbm4g KHBhdWxxKTsgc2ZjOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQoNCkhp LA0KDQpUaGUgU2VydmljZSBGdW5jdGlvbiBOQVQ0NCByZXByZXNlbnRzIHRoZSBmdW5jdGlvbnMg YSBOQVQ0NCBwZXJmb3JtcywgIGkuZS4gVHJhbnNsYXRlIHNvdXJjZSBJUHY0IHBhY2tldHMsIGNy ZWF0ZSBtYXBwaW5ncywgZXRjLiBCdXQgYSBTZXJ2aWNlIEZ1bmN0aW9uIGRvZXMgbm90IHByb2Nl c3MgcGFja2V0cywgaXQgaXMganVzdCBhIHRlbXBsYXRlIGRlZmluaXRpb24uDQoNCkEgc2Vydmlj ZSBpbnN0YW5jZSBhY3R1YWxseSBwcm9jZXNzZXMgcGFja2V0cyBhbmQgaXMgcGFydCBvZiBhIFNl cnZpY2UgUGF0aC4gIFNvLCB0d28gZGlmZmVyZW50IE5BVDQ0IGRldmljZXMgdGhhdCBwcm9jZXNz IHBhY2tldHMgYXJlIGNsYXNzaWZpZWQgdW5kZXIgdGhlIHNhbWUgc2VydmljZSBmdW5jdGlvbiBi dXQgcmVwcmVzZW50IGRpZmZlcmVudCBpbnN0YW5jZXMuDQoNCg0KRnJvbTogIm1lbmcud2VpMkB6 dGUuY29tLmNuPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj4iIDxtZW5nLndlaTJAenRlLmNv bS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+Pg0KRGF0ZTogU3VuZGF5LCBGZWJydWFy eSA5LCAyMDE0IGF0IDc6MTUgUE0NClRvOiBDaXNjbyBFbXBsb3llZSA8cmVwZW5ub0BjaXNjby5j b208bWFpbHRvOnJlcGVubm9AY2lzY28uY29tPj4NCkNjOiAiUGF1bCBRdWlubiAocGF1bHEpIiA8 cGF1bHFAY2lzY28uY29tPG1haWx0bzpwYXVscUBjaXNjby5jb20+PiwgInNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4s IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBSZTogW3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KDQoNCkhpo6wNCg0KICBGb3IgUmVpbmFsZG8n cyBjb21tZW50cyAyLg0KICBJJ20gbm90IHN1cmUgIlNGIiAmICJTRiBpbnN0YW5jZSIgY29uZnVz ZSBtZSBpbiB0aGUgZHJhZnQuDQoNCiAgRm9yIGV4YW1wbGUsIE5BVDQ0IHdpdGggYSBydWxlIGlz IGEgU0YsIE5BVDQ0IHdpdGggYW5vdGhlciBydWxlIGlzDQphIGRpZmZlcmVudCBTRi4gIFRoaXMg aXMgbXkgdW5kZXJzdGFuZGluZyBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaW4NCnRoZSBkcmFm dC4gICAoT3IgYSBzYW1lIFNGIGJ1dCBkaWZmZXJlbnQgU0YgaW5zdGFuY2VzPykNCg0KDQpUaGFu a3MsDQpXZWkNCg0KDQoic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPj4gIDIwMTQtMDEtMzAgMTQ6MjY6NTU6DQoNCj4gSGkgUGF1bCwNCj4NCj4g UmV2aWV3aW5nIHRoaXMgZHJhZnQgYW5kIGNvbXBhcmluZyB3aXRoIHRoZSBZYW5nIG1vZGVsIEkg aGF2ZSBhIGNvdXBsZSBvZg0KPiBjb21tZW50cw0KPg0KPiAxIC0NCj4NCj4gSSBub3RpY2VkIHRo YXQgYSBTRklEIGFuZCBTRkMtZG9tYWluIG1pZ2h0IG5lZWQgbW9yZSB3b3JkaW5nLg0KPg0KPiAi U2VydmljZSBGdW5jdGlvbiBJZGVudGl0eSAoU0ZJRCk6ICBBIHVuaXF1ZSBpZGVudGlmaWVyIHRo YXQNCj4gICAgICAgcmVwcmVzZW50cyBhIHNlcnZpY2UgZnVuY3Rpb24uICBTRklEcyBhcmUgdW5p cXVlIGZvciBlYWNoIFNGDQo+ICAgICAgIHdpdGhpbiBhbiBTRkMgZG9tYWluLqn3DQo+DQo+ICJT RkMtZG9tYWluIiBpcyB1c2VkIHdpdGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQgdGhlbiB0 aGUgZHJhZnQNCj4gc3dpdGNoZXMgdG8gImFkbWluaXN0cmF0aXZlIGRvbWFpbqn3IGV2ZXJ5d2hl cmUgZWxzZS4NCj4NCj4gQWxzbywgdGhlIGRlZmluaXRpb24gb2YgU2VydmljZSBGdW5jdGlvbiB1 c2VzIKn4YWRtaW5pc3RyYXRpdmUgZG9tYWluqfcNCj4gaW5zdGVhZCBvZiBvZiAiU0ZDLWRvbWFp biIuDQo+DQo+DQo+IDIgLQ0KPg0KPiBJdCBzZWVtcyB3ZXJlIGFyZSBtaXNzaW5nIHRoZSBkZWZp bml0aW9uIG9mIGEgaW5zdGFudGlhdGVkIFNlcnZpY2UNCj4gRnVuY3Rpb246DQo+DQo+IEEgU2Vy dmljZSBGdW5jdGlvbiBpcyBzb21ldGhpbmcgbGlrZSBOQVQ0NCwgRmlyZXdhbGwsIGV0Yy4gSXQg ZGVub3RlcyBhDQo+IGNsYXNzIG9mIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSB0aGUgc2FtZSBmdW5j dGlvbi4NCj4NCj4gQSBTRkMgaXMgYW4gb3JkZXJlZCBzZXQgb2YgU0ZzLg0KPg0KPiBBIFNGUCBp cyBhbiBpbnN0YW50aWF0aW9uIG9mIGEgU0ZDLiBTbywgd2hhdCBkbyB3ZSBjYWxsIHRoZSBTRnMg dGhhdCBhcmUNCj4gaW5zdGFudGlhdGVkIGFuZCBwYXJ0IG9mIHRoZSBTRlA/IFdlIGNhbiBub3Qg Y2FsbCB0aGVtIFNlcnZpY2UgRnVuY3Rpb25zDQo+IGFnYWluIGJlY2F1c2Ugd2UgYXJlIG5vdyB0 YWxraW5nIGFib3V0IGFuIHNwZWNpZmljIHNlcnZpY2UgYW5kIHRoYXQgd291bGQNCj4gY2F1c2Ug Y29uZnVzaW9uLiBEbyB3ZSBjYWxsIHRoZW0gIlNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2Vzqfcg YW5kDQo+IHRoZXJlZm9yZSBhIFNGUCBpcyBjb21wb3NlZCBvZiBhbiBvcmRlcmVkIHNldCBvZiBT ZXJ2aWNlIEZ1bmN0aW9uDQo+IEluc3RhbmNlcz8NCj4NCj4gVGhhbmtzLA0KPg0KPiAtUlANCj4N Cj4gT24gMS8yOS8xNCwgNjo1OCBBTSwgIlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxxQGNpc2Nv LmNvbTxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+ID5IaSBmb2xrcywNCj4g Pg0KPiA+VGhlIG9ubHkgY2hhbmdlIHRvIHRoaXMgdmVyc2lvbiBpcyB0aGF0IHdlIG1vdmVkIHRv IHR3byBlZGl0b3JzLCBhbmQNCj4gPmxpc3RlZCB0aGUgb3RoZXIgY28tYXV0aG9ycyBpbiBhIGNv bnRyaWJ1dG9ycyBzZWN0aW9uLg0KPiA+DQo+ID5BcyBhbHdheXMsIHlvdXIgY29tbWVudHMgYW5k IGZlZWRiYWNrIGlzIGFwcHJlY2lhdGVkIQ0KPiA+UGF1bA0KPiA+DQo+ID4NCj4gPj4NCj4gPj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KPiA+PiBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhdWwgUXVpbm4gYW5kIHBvc3RlZCB0 byB0aGUNCj4gPj4gSUVURiByZXBvc2l0b3J5Lg0KPiA+Pg0KPiA+PiBOYW1lOiAgICAgIGRyYWZ0 LXF1aW5uLXNmYy1hcmNoDQo+ID4+IFJldmlzaW9uOiAgIDA0DQo+ID4+IFRpdGxlOiAgICAgIFNl cnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlDQo+ID4+IERvY3VtZW50 IGRhdGU6ICAgMjAxNC0wMS0yOA0KPiA+PiBHcm91cDogICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gPj4gUGFnZXM6ICAgICAgMjENCj4gPj4gVVJMOg0KPiA+Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KPiA+PiBTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4t c2ZjLWFyY2gvDQo+ID4+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1xdWlubi1zZmMtYXJjaC0wNA0KPiA+PiBEaWZmOg0KPiA+Pg0KPiA+PiBBYnN0cmFj dDoNCj4gPj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgdXNlZCBm b3IgdGhlIGNyZWF0aW9uIG9maHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt cXVpbm4tc2ZjLWFyY2gtMDQNCj4gPj4gICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlucyAoU0ZDKS4g IEl0IGluY2x1ZGVzIGFyY2hpdGVjdHVyYWwgY29uY2VwdHMsDQo+ID4+ICAgcHJpbmNpcGxlcywg YW5kIGNvbXBvbmVudHMgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uIG9mIGNvbXBvc2l0ZQ0KPiA+ PiAgIHNlcnZpY2VzIHRocm91Z2ggZGVwbG95bWVudCBvZiBTRkNzIGluIGEgbmV0d29yay4gIFRo aXMgZG9jdW1lbnQgZG9lcw0KPiA+PiAgIG5vdCBwcm9wb3NlIHNvbHV0aW9ucywgcHJvdG9jb2xz LCBvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nDQo+ID4+ICAgcHJvdG9jb2xzLg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+PnN1Ym1pc3Npb24NCj4gPj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4gPj4NCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4NCj4gPg0KPiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPnNmYyBtYWls aW5nIGxpc3QNCj4gPnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A2F4BMBX021W3CA2exch_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 9:00 AM
To: meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Hi,

 

The Service Function NAT44 = represents the functions a NAT44 performs,  i.e. Translate source IPv4= packets, create mappings, etc. But a Service Function does not process packets, it is just a template definition.

 

A service instance actually= processes packets and is part of a Service Path.  So, two different N= AT44 devices that process packets are classified under the same service function but represent different instances. 

 

 

From: "meng.wei2@zte.com.cn" <meng.wei2@= zte.com.cn>
Date: Sunday, February 9, 2014 at 7:15 PM
To: Cisco Employee <<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">repenno@cisco.com>
Cc: "Paul Quinn (paulq)" <paulq@cisco.comsfc@ietf.= org" <sfc@ietf.org>, sfc <sfc-bounces@ietf.org>
Subject: Re: Re: [sfc] Fwd: New Version Notification for draft-quinn= -sfc-arch-04.txt

 


Hi=A3=AC

  For Reinaldo's comments 2.
  I'm not sure "SF" & &quo= t;SF instance" confuse me in the draft.

  For example, NAT44 with a rule is a SF= , NAT44 with another rule is
a different SF.  This is my understandin= g based on the description in
the draft.   (Or a same SF but different= SF instances?)

 
Thanks,
Wei


"sfc" <= ;sfc-bounces@ietf.org>  2014-01-30 14:26:55:=

> Hi Paul,
>
> Reviewing this draft and comparing with the Yang model I have a co= uple of
> comments
>
> 1 -
>
> I noticed that a SFID and SFC-domain might need more wording.=
>
> "Service Function Identity (SFID):  A unique identifier = that
>       represents a service function.  SFIDs ar= e unique for each SF
>       within an SFC domain.=A9=F7
>
> "SFC-domain" is used within the definition above but the= n the draft
> switches to "administrative domain=A9=F7 everywhere else.
>
> Also, the definition of Service Function uses =A9=F8administrative= domain=A9=F7
> instead of of "SFC-domain".
>
>
> 2 -
>
> It seems were are missing the definition of a instantiated Service=
> Function:
>
> A Service Function is something like NAT44, Firewall, etc. It deno= tes a
> class of services that provide the same function.
>
> A SFC is an ordered set of SFs.
>
> A SFP is an instantiation of a SFC. So, what do we call the SFs th= at are
> instantiated and part of the SFP? We can not call them Service Fun= ctions
> again because we are now talking about an specific service and tha= t would
> cause confusion. Do we call them "Service Function Instances= =A9=F7 and
> therefore a SFP is composed of an ordered set of Service Function<= /tt>
> Instances?
>
> Thanks,
>
> -RP
>
> On 1/29/14, 6:58 AM, "Paul Quinn (paulq)" <paulq@cisco.com> wrote:
>
> >Hi folks,
> >
> >The only change to this version is that we moved to two editor= s, and
> >listed the other co-authors in a contributors section. > >
> >As always, your comments and feedback is appreciated!
> >Paul
> >
> >
> >>
> >> A new version of I-D, draft-quinn-sfc-arch-04.txt > >> has been successfully submitted by Paul Quinn and posted = to the
> >> IETF repository.
> >>
> >> Name:      draft-quinn-sfc-arch
> >> Revision:   04
> >> Title:      Service Function Chaining (SFC= ) Architecture
> >> Document date:   2014-01-28
> >> Group:      Individual Submission
> >> Pages:      21
> >> URL:            
> >>http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-04.txt<= br> > >> Status:         https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-arch/
> >> Htmlized:       http://tools.ietf.org/html/draft-quinn-sfc-arch= -04
> >> Diff:          
> >>
> >> Abstract:
> >>   This document describes an architecture used for t= he creation ofhttp://www.ietf.= org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-04
> >>   Service Function Chains (SFC).  It includes a= rchitectural concepts,
> >>   principles, and components used in the constructio= n of composite
> >>   services through deployment of SFCs in a network. =  This document does
> >>   not propose solutions, protocols, or extensions to= existing
> >>   protocols.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the= time of
> >>submission
> >> until the htmlized version and diff are available at tool= s.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >
> >_______________________________________________
> >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<= /p>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A2F4BMBX021W3CA2exch_-- From ddolson@sandvine.com Mon Feb 10 09:10:30 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D8C1A03A5 for ; Mon, 10 Feb 2014 09:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 K9noe7HC7Qtk for ; Mon, 10 Feb 2014 09:10:28 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB021A01DA for ; Mon, 10 Feb 2014 09:10:25 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Mon, 10 Feb 2014 12:10:24 -0500 From: Dave Dolson To: Linda Dunbar , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt Thread-Index: AQHPJOJWuIDUqtgnlkaZEJ6rdtz9jJqrfb3QgAMtfTA= Date: Mon, 10 Feb 2014 17:10:24 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645C7A7AC@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7A7AC@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.7.137.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-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, 10 Feb 2014 17:10:31 -0000 TGluZGEgZXQgYWwuLA0KDQpJIG1heSBub3QgaGF2ZSB1bmRlcnN0b29kIGV2ZXJ5dGhpbmcgeW91 IHdlcmUgc2F5aW5nLCBidXQgSSB0aGluayB0aGUgZm9sbG93aW5nIHBlcnNwZWN0aXZlIGlzIHVz ZWZ1bCBhbmQgY29uY2lzZToNCg0KTGVnYWN5IG5vZGVzIG11c3QgYmUgd3JhcHBlZCB3aXRoIFNG RiBub2RlcyB0byBtYWtlIHRoZW0gbG9vayBsaWtlIHByb3BlciBTRiBub2Rlcy4NCg0KVGhlcmUg YXJlIHR3byBjaG9pY2VzIGZvciB3cmFwcGluZyBsZWdhY3kgU0Ygbm9kZXM6DQoNCmEuIEVhY2gg bGVnYWN5IG5vZGUgaXMgd3JhcHBlZCBzdWNoIHRoYXQgaXQgaXMgZXhwb3NlZCBhcyBhIGRpc3Rp bmN0IFNGIGluc3RhbmNlLCB3aXRoIG9uZSBTRiBNYXAgaW5kZXggcGVyIG5vZGUuIFRoZW4gdGhl IENsYXNzaWZpZXIgY2hvb3NlcyB3aGljaCBub2RlcyBhcmUgdG8gYmUgdXNlZC4gVGhpcyB3b3Vs ZCBiZSB1c2VkIHdoZW4gdGhlIGxlZ2FjeSBub2RlIGhhcyBubyBtZWNoYW5pc21zIGZvciBzZXBh cmF0aW5nIHRyYWZmaWMgZm9yIGRpZmZlcmVudCBjaGFpbnMuDQoNCmIuIEEgY2x1c3RlciBvZiBs ZWdhY3kgbm9kZXMgY2FuIGJlIHdyYXBwZWQgc3VjaCB0aGF0IHRoZSBjbHVzdGVyIGlzIGV4cG9z ZWQgYXMgYSBzaW5nbGUgU0YgaW5zdGFuY2UuIFRoZW4gdGhlIENsYXNzaWZpZXIgY2hvb3NlcyB0 aGUgY2x1c3RlciBidXQgaXMgYWdub3N0aWMgYWJvdXQgdGhlIHBhdGggb2YgdHJhZmZpYyB3aXRo aW4gdGhlIGNsdXN0ZXIuIChUaGlzIGlzIHdoZXJlIHRoZSBjaGFsbGVuZ2VzIGFwcGVhciwgYnV0 IGFsc28gcHJvdmlkZSBncmVhdCBmbGV4aWJpbGl0eTsgdXNlIFZMQU5zIG9yIE1QTFMgb3IgcHJv cHJpZXRhcnkgdGFnZ2luZyB0byBzZXBhcmF0ZSB0aGUgY2hhaW5zLikgTW9yZSBnZW5lcmFsbHks IGEgY2x1c3RlciBjb3VsZCBleHBvc2UgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIGZvciBkaWZmZXJl bnQgcG9saWNpZXMuDQoNCg0KSXQgbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gc2F5IGFueXRoaW5n IG1vcmUuIFByb3ZpZGVkIHRoZSBsZWdhY3kgbm9kZXMgYXJlIHdyYXBwZWQgdG8gbG9vayBsaWtl IHByb3BlciBTRkMgbm9kZXMgKG5hbWVseSwgcHJvcGVybHkgZm9yd2FyZGluZyBwYWNrZXRzKSwg d2h5IHNob3VsZCB0aGUgU0ZDIHN0YW5kYXJkIHNheSBhbnl0aGluZyBhYm91dCB3aGF0IGhhcHBl bnMgYmVuZWF0aCB0aGUgd3JhcHBpbmc/DQoNCg0KDQpPbiBhIHNvbWV3aGF0IHJlbGF0ZWQgbm90 ZSwgSSB0aGluayBpdCBpcyBhbHNvIHJlYXNvbmFibGUgdGhhdCBTRkMgY291bGQgYmUgZGVwbG95 ZWQgaGllcmFyY2hpY2FsbHkuIEkuZS4sIGEgbG9hZC1iYWxhbmNlciBjb3VsZCBhcHBlYXIgYXMg YSBzaW5nbGUgU0Ygbm9kZSB3aXRoaW4gYSBzZXJ2aWNlIGNoYWluLCBhbmQgdXRpbGl6ZSBTRkMg dG8gZGlzdHJpYnV0ZSB0cmFmZmljIHdpdGhpbiBpdHMgY2x1c3RlciwgaW4gYSBkaWZmZXJlbnQg U0ZDIGRvbWFpbi4gV2hlbiB0aGUgaW5uZXIgY2hhaW4gZW5kcywgdGhlIHBhY2tldCByZXR1cm5z IHRvIHRoZSBvcmlnaW5hbCBTRiBDaGFpbi4gDQoNCkhpZXJhcmNoaWVzIGFyZSBhcmNoaXRlY3R1 cmFsbHkgcG93ZXJmdWwsIGFsbG93aW5nIHNpbXBsaWZpY2F0aW9uIGJ5IGFic3RyYWN0aW9uLiBU aGlzIHZpZXcgYWxsb3dzIGEgdmVuZG9yIHRvIHByb3ZpZGUgYSBzb2x1dGlvbiBhcHBlYXJpbmcg YXMgYSBzaW5nbGUgU0ZDIG5vZGUsIGJ1dCBpbnRlcm5hbGx5IHV0aWxpemluZyBtdWx0aXBsZSBj b21wb25lbnRzIHdpdGggU0ZDIHRlY2hub2xvZ3kuDQoNCg0KDQpEYXZpZCBEb2xzb24NClNlbmlv ciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIEluYy4NCg0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTGluZGEgRHVuYmFyDQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMDgsIDIw MTQgMTA6NDggQU0NClRvOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWlu LWFyY2hpdGVjdHVyZS0wMi50eHQNCg0KVGhpcyBkcmFmdCBhbmFseXplcyB0aGUgaXNzdWVzIGFz c29jaWF0ZWQgd2l0aCBjaGFpbmluZyBleGlzdGluZyBMYXllciA0LTcgc2VydmljZSBmdW5jdGlv bnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIHNlcnZpY2UgZW5jYXBzdWxhdGlvbiBsYXllcnMuIFRo aXMgZHJhZnQgYWxzbyBleGFtaW5lcyB0aGUgbmV0d29yayBhcmNoaXRlY3R1cmUgZm9yIGNoYWlu aW5nIGV4aXN0aW5nIEw0LUw3IHNlcnZpY2UgZnVuY3Rpb25zLiBUaGUgZ29hbCBvZiB0aGUgZHJh ZnQgaXM6DQoNCg0KLSBUbyBtYWtlIFNGQyBXRyBhZG9wdCB0aGUgZmFjdCB0aGF0IHRoZXJlIGFy ZSBtYW55IHNlcnZpY2UgZnVuY3Rpb25zIGRlcGxveWVkIHRoYXQgZG9u4oCZdCB0ZXJtaW5hdGUg dGhlIG5ld2x5IHByb3Bvc2VkIFNGQyBIZWFkZXI7IE1hbnkgb2YgdGhlbSBkb27igJl0IGhhdmUg TDIvTDMgc3dpdGNoaW5nL3JvdXRpbmcgY2FwYWJpbGl0eQ0KDQotIFRvIG1ha2UgU0ZDIFdHIGFk b3B0IHRoYXQgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIgKHRoYXQgaXMgZGVmaW5lZCBieSBk cmFmdC1xdWlubi1uc2MtYXJjaC0wNCkgY2FuIGJlIGEgc2VwYXJhdGUgZW50aXR5IGZyb20gc2Vy dmljZSBmdW5jdGlvbnMuIA0KDQotIFRvIG1ha2UgU0ZDIFdHIGFkb3B0IHRoYXQgaXQgaXMgbm90 IG5lY2Vzc2FyeSBmb3IgZXZlcnkgcGFja2V0IHRvIGNhcnJ5IHRoZSBjb21wbGV0ZSBzZXJ2aWNl IGNoYWluIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gaW4gaXRzIFNGQyBoZWFkZXIuIMKgSXQgc2hv dWxkIGJlIGFjY2VwdGFibGUgdG8gaGF2ZSB2YXJpYWJsZSBsZW5ndGggU0ZDIEhlYWRlci4gRm9y IGV4YW1wbGUsIGZvciBwYWNrZXRzIHRvIGJlIGVuY29kZWQgd2l0aCBhIENoYWluIElEIHBsdXMg b3B0aW9uYWwgYXR0cmlidXRlcyBhbmQgaGF2ZSBzZXBhcmF0ZSBtZXNzYWdlcyAoZWl0aGVyIGlu LWJhbmQgb3Igb3V0LW9mLWJhbmQpIHRvIGluZm9ybSB0aGUgZGV0YWlsZWQgZm9yd2FyZGluZyBw b2xpY2llcyBmb3IgdGhlIENoYWluIElEIGFuZCB0aGUgQ2hhaW4gYXR0cmlidXRlcyBpbiB0aGUg cGFja2V0cyDCoHRvIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRpbmcgbm9kZXMuIA0KDQot IFJlY29nbml6ZSB0aGF0IGZyb20gdXNlcuKAmXMgcGVyc3BlY3RpdmUsIHRoZSBvcmRlciBvZiBz ZXJ2aWNlIGZ1bmN0aW9ucywgZS5nLiBDaGFpbiMxIHtzMSwgczQsIHM2fSwgQ2hhaW4jMntzNCwg czd9LCBpcyBpbXBvcnRhbnQsIGJ1dCB2ZXJ5IG9mdGVuIHdoaWNoIGluc3RhbmNlIG9mIHRoZSBT ZXJ2aWNlIEZ1bmN0aW9uIOKAnHMx4oCdIGlzIHNlbGVjdGVkIGZvciB0aGUgQ2hhaW4gIzEgaXMg bm90LiAgDQoJQW1vbmcgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIG9uZSBzZXJ2aWNlIGZ1bmN0aW9u LCBzb21lIGNvdWxkIGJlIGluIGNsb3NlIHByb3hpbWl0eSB3aGlsZSBvdGhlcnMgYXJlIGZhciBh cGFydCBiZWluZyBjb25uZWN0ZWQgYnkgZGlmZmVyZW50IG5ldHdvcmsgbm9kZXMuDQoJSXQgc2hv dWxkIGJlIGFjY2VwdGFibGUgZm9yIFNlcnZpY2UgQ2hhaW4gY2xhc3NpZmllciBvbmx5IGlkZW50 aWZ5IHRoZSBjaGFpbmluZyBhdCBmdW5jdGlvbiBsZXZlbCBhbmQgaGF2ZSBhbm90aGVyIGVudGl0 eSBtYW5hZ2luZyB0aGUgZGV0YWlsZWQgc2VydmljZSBpbnN0YW5jZSBwYXRoLg0KDQoNCllvdXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiANCg0KVGhh bmtzLCBMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6 IFNhdHVyZGF5LCBGZWJydWFyeSAwOCwgMjAxNCA5OjI4IEFNDQpUbzogTGluZGEgRHVuYmFyOyBS b24gUGFya2VyOyBOaW5nIFNvOyBSb24gUGFya2VyOyBTbyBOaW5nOyBEb25hbGQgRWFzdGxha2U7 IExpbmRhIER1bmJhcjsgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZA0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1h cmNoaXRlY3R1cmUtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMi50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNo YWluLWFyY2hpdGVjdHVyZQ0KUmV2aXNpb246CTAyDQpUaXRsZToJCUFyY2hpdGVjdHVyZSBmb3Ig Q2hhaW5pbmcgTGVnYWN5IExheWVyIDQtNyBTZXJ2aWNlIEZ1bmN0aW9ucw0KRG9jdW1lbnQgZGF0 ZToJMjAxNC0wMi0wNw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDIudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFy LXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNo YWluLWFyY2hpdGVjdHVyZS0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVj dHVyZS0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgYW5hbHl6ZXMgdGhlIGlzc3VlcyBh c3NvY2lhdGVkIHdpdGggY2hhaW5pbmcgZXhpc3RpbmcNCiAgIExheWVyIDQtNyBzZXJ2aWNlIGZ1 bmN0aW9ucyB0aGF0IGFyZSBub3QgYXdhcmUgb2Ygc2VydmljZQ0KICAgZW5jYXBzdWxhdGlvbiBs YXllcnMuIFRoaXMgZHJhZnQgYWxzbyBleGFtaW5lcyB0aGUgbmV0d29yaw0KICAgYXJjaGl0ZWN0 dXJlIGZvciBjaGFpbmluZyBleGlzdGluZyBMNC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucy4gVGhlDQog ICBpbnRlbnQgaXMgdG8gaWRlbnRpZnkgb3B0aW1hbCBhcmNoaXRlY3R1cmUgZm9yIGZsZXhpYmx5 IGNoYWluaW5nDQogICBleGlzdGluZyBMYXllciA0LTcgZnVuY3Rpb25zIHRvIG1lZXQgdmFyaW91 cyBzZXJ2aWNlIG5lZWRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcg bGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0K From linda.dunbar@huawei.com Mon Feb 10 09:13:38 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622551A03BF for ; Mon, 10 Feb 2014 09:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 qLQJU1s-lA4c for ; Mon, 10 Feb 2014 09:13:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2F0F1A0386 for ; Mon, 10 Feb 2014 09:13:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ08294; Mon, 10 Feb 2014 17:13:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 17:12:38 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 17:13:31 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 09:13:21 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" Thread-Topic: [sfc] New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPHQE+740iIXkVW06tWQcece0mepqnK82AgAGWpYD//6QNoIAGm7+A///JgOA= Date: Mon, 10 Feb 2014 17:13:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7AE10@dfweml701-chm.china.huawei.com> References: <20140129144857.28482.61199.idtracker@ietfa.amsl.com> <35A9A6D9-3ECF-41C9-B145-BDAA0254C771@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C78C9E@dfweml701-chm.china.huawei.com> <80DBC0E1-FBF6-432F-9D12-989D9B798705@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645C7922A@dfweml701-chm.china.huawei.com> <3AEE1119-4D64-42B7-88D7-23BAB6C8C5F2@cisco.com> In-Reply-To: <3AEE1119-4D64-42B7-88D7-23BAB6C8C5F2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:13:38 -0000 Paul,=20 Thanks for the reply, See the comments inserted below: -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 >=20 > [Linda] Even with Service Functions being "consumed", it is still very im= portant to SFF or/and SNF on "Where to steer traffic to consume the "servic= e function"", correct?=20 Traffic is steered to the "right" function, as opposed to having that funct= ion simply be inline because of topology. More interestingly, a subset of = traffic might go to one SF, whereas other traffic might be steered to anoth= er. =20 [Linda] Absolutely agree with your statement here. Can you use this stateme= nt in the draft instead of saying the functions being consumed? It is still very important to SFF or/and SNF on "Where to steer traffic".=20 To the particular subset of traffic, the path from SFF/SNF to SF can be "on= e armed" or "bump in the wire".=20 Linda From jguichar@cisco.com Mon Feb 10 11:12:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5031A03FB; Mon, 10 Feb 2014 11:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdOlFQmKeGNQ; Mon, 10 Feb 2014 11:12:37 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9A20B1A03A5; Mon, 10 Feb 2014 11:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39763; q=dns/txt; s=iport; t=1392059556; x=1393269156; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dc7exeycDgP7XnrDwuZgVi9tvWR/S2QsJz5ImpxzJNY=; b=YsxbO6X3mDcYcU0ryvh3GbGEFv+YotQrnq9y4hbmlhiKaRnRNgilOhsU XwIIM3QggkXfaTPCJbtmPK3aBoTSEFiFqn2dC9C5E0dDiYkg/GJXP1VKn eI4lFv1oOM/NmWXB4Cu817uSoY2WnQNIFzRw4rW3vVH9+HJ/Ojj+oaEhR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAD8k+VKtJXG//2dsb2JhbABQCYJIRDhRBoMBtAyIVBh9FnSCJQEBAQMBAQEBIApBCQIFCwIBCBEBAgEBAQEgAQYDAgICJQsUAwYIAgQBDQUJEodiCAgFqSugABeOIjcJCg0EBgEJgmaBSQSYK4EykG6DLYIq X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208,217";a="19348079" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-5.cisco.com with ESMTP; 10 Feb 2014 19:12:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1AJCZ4R004559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 19:12:35 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 13:12:35 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , "Reinaldo Penno (repenno)" , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzIA= Date: Mon, 10 Feb 2014 19:12:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.188] Content-Type: multipart/alternative; boundary="_000_CF1E8DFB15390jguicharciscocom_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:12:40 -0000 --_000_CF1E8DFB15390jguicharciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KU2VlbXMgdG8gbWUgdGhhdCB0aGVyZSBhcmUgYWN0dWFsbHkgMyBkaWZmZXJlbnQg dGhpbmdzIGhlcmU6DQoNCiAgMS4gIEEgc2VydmljZSBmdW5jdGlvbiB0aGF0IGlzIGFibGUgdG8g YXBwbHkgcG9saWN5LXNldC1BIGFuZCBwb2xpY3ktc2V0LUIgYW5kIGhhcyBhbiBpbnRlcm5hbCBt ZWNoYW5pc20gZm9yIGRpc3RpbmN0aW9uIGJldHdlZW4gd2hpY2ggcG9saWN5IHRvIGFwcGx5IHRv IGluYm91bmQgdHJhZmZpYy4gSW4gdGhpcyBjYXNlIGl0IGlzIGEgc2luZ2xlIHNlcnZpY2UgZnVu Y3Rpb24gd2l0aCBpbnRlcm5hbCBjbGFzc2lmaWNhdGlvbiBiZXR3ZWVuIHdoaWNoIHBvbGljeSBz ZXQgdG8gYXBwbHkuDQogIDIuICBBIHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBhcHBsaWVzIHBvbGlj eS1zZXQtQSBhbmQgYSBkaWZmZXJlbnQgc2VydmljZSBmdW5jdGlvbiB0aGF0IGFwcGxpZXMgcG9s aWN5LXNldC1CIGUuZy4gVGhleSBhcmUgdHdvIGRpc3RpbmN0IHNlcnZpY2UgZnVuY3Rpb25zLg0K ICAzLiAgQSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgaXMgYWJsZSB0byBhcHBseSBwb2xpY3ktc2V0 LUEgYW5kIHBvbGljeS1zZXQtQiBhbmQgcmVsaWVzIHVwb24gaW5kaWNhdGlvbiB3aXRoaW4gdGhl IGluYm91bmQgcGFja2V0IHRvIGRldGVybWluZSB3aGljaCBwb2xpY3kgc2V0IHRvIGFwcGx5LiBJ biB0aGlzIGNhc2UgaXRzIGEgc2luZ2xlIHNlcnZpY2UgZnVuY3Rpb24gYnV0IHdpdGhvdXQgaW50 ZXJuYWwgY2xhc3NpZmljYXRpb24uDQoNCkZyb206IFJvbiBQYXJrZXIgPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ Pg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCBhdCAxMDowMyBBTQ0KVG86ICJSZWlu YWxkbyBQZW5ubyAocmVwZW5ubykiIDxyZXBlbm5vQGNpc2NvLmNvbTxtYWlsdG86cmVwZW5ub0Bj aXNjby5jb20+PiwgIm1lbmcud2VpMkB6dGUuY29tLmNuPG1haWx0bzptZW5nLndlaTJAenRlLmNv bS5jbj4iIDxtZW5nLndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+ Pg0KQ2M6IFBhdWwgUXVpbm4gPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28uY29t Pj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4+LCBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KDQpNZW5nLA0KDQpJ IHZpZXcgdGhlIGluc3RhbmNlcyBpc3N1ZSBpbiAyIGRpZmZlcmVudCB3YXlzLg0KDQpGaXJzdCwg YSB0eXBlIG9mIHNlcnZpY2UgZnVuY3Rpb24gKGkuZS4sIE5BVDQ0KSBtYXkgZXhpc3Qgd2l0aCBt dWx0aXBsZSBwb2xpY3kgc2V0cy4gICAgRm9yIHRoaXMgcHVycG9zZSwgdGhlIGRlcGxveW1lbnQg b2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggYSBwb2xpY3kgc2V0IGlzIGFuIGluc3RhbmNlLiAg IEZvciBleGFtcGxlLCBOQVQ0NC13aXRoLXBvbGljeS1zZXQtQSBpcyBvbmUgaW5zdGFuY2Ugd2hp bGUgTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUIgaXMgYW5vdGhlciBpbnN0YW5jZS4gICBGcm9tIGEg Y2hhaW4gcGVyc3BlY3RpdmUsIGNoYWluIDEgbWlnaHQgY29udGFpbiBOQVQ0NC13aXRoLXBvbGlj eS1zZXQtQSB3aGlsZSBjaGFpbiAyIG1pZ2h0IGNvbnRhaW4gTkFUNDQtd2l0aC1wb2xpY3ktc2V0 LUIuICAgIFRoZSBhY3R1YWwgbG9jYXRpb24gb2YgdGhlIHRob3NlIDIgaW5zdGFuY2VzIGlzIGFy Yml0cmFyeSDigJMgaXQgaXMgcG9zc2libGUgdGhhdCB0aGV5IGFyZSBsb2NhdGVkIHRvIHRoZSBz YW1lIHBoeXNpY2FsIGFuZC9vciB2aXJ0dWFsIGNvbXB1dGUgbm9kZSBvciBkaWZmZXJlbnQuICAg SXQgaXMgZXZlbiBwb3NzaWJsZSB0aGF0IHRoZSAyIGxvZ2ljYWwgaW5zdGFuY2VzIGFyZSByZWFs aXplZCBieSB0aGUgZXhhY3Qgc2FtZSBzZXQgb2YgcHJvY2Vzc2VzIGV4ZWN1dGluZyBvbiB0aGUg ZXhhY3Qgc2FtZSBjb21wdXRlIG5vZGUsIG9yIGF0IHRoZSBvdGhlciBleHRyZW1lLCB0aGV5IGNv dWxkIGJlIGxvY2F0ZWQgaW4gZGlmZmVyZW50IGNvdW50cmllcy4NCg0KU2Vjb25kLCBhIHBhcnRp Y3VsYXIgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSAoaS5lLiwgTkFUNDQtd2l0aC1wb2xpY3kt c2V0LUEpIG1heSwgaXRzZWxmLCBiZSBtdWx0aXBseSBpbnN0YW50aWF0ZWQgZm9yIGxvYWQgYmFs YW5jaW5nIG9yIHJlc2lsaWVuY3kgcHVycG9zZXMuICAgSSBjb25zaWRlciB0aGlzIGFzcGVjdCB3 aXRoaW4gdGhlIHJlYWxtIG9mIOKAnGNoYWluIHRvIHBhdGggcmVkdWN0aW9u4oCdLiAgIFRoYXQs IGlzIHRoZSBoaWdoIGxldmVsIGNoYWluIHNwZWNpZmllZCB0aGUgbmVlZCBmb3IgTkFUNDQtd2l0 aC1wb2xpY3ktc2V0LUEsIGJ1dCB0aGUgYWN0dWFsIGNoYWluIGludm9rZWQgZm9yIGEgcGFydGlj dWxhciBmbG93IG11c3QgZW5kIHVwIHN0ZWVyaW5nIHRoZSB0cmFmZmljIHRvIHNvbWUgcGFydGlj dWxhciBpbnN0YW5jZSBvZiB0aGF0IGxvZ2ljYWwgc2VydmljZSBmdW5jdGlvbi4NCg0KICAgUm9u DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UmVpbmFsZG8gUGVubm8gKHJlcGVubm8pDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0 IDk6MDAgQU0NClRvOiBtZW5nLndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5j b20uY24+DQpDYzogUGF1bCBRdWlubiAocGF1bHEpOyBzZmM7IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1xdWlubi1zZmMtYXJjaC0wNC50eHQNCg0KSGksDQoNClRoZSBTZXJ2 aWNlIEZ1bmN0aW9uIE5BVDQ0IHJlcHJlc2VudHMgdGhlIGZ1bmN0aW9ucyBhIE5BVDQ0IHBlcmZv cm1zLCAgaS5lLiBUcmFuc2xhdGUgc291cmNlIElQdjQgcGFja2V0cywgY3JlYXRlIG1hcHBpbmdz LCBldGMuIEJ1dCBhIFNlcnZpY2UgRnVuY3Rpb24gZG9lcyBub3QgcHJvY2VzcyBwYWNrZXRzLCBp dCBpcyBqdXN0IGEgdGVtcGxhdGUgZGVmaW5pdGlvbi4NCg0KQSBzZXJ2aWNlIGluc3RhbmNlIGFj dHVhbGx5IHByb2Nlc3NlcyBwYWNrZXRzIGFuZCBpcyBwYXJ0IG9mIGEgU2VydmljZSBQYXRoLiAg U28sIHR3byBkaWZmZXJlbnQgTkFUNDQgZGV2aWNlcyB0aGF0IHByb2Nlc3MgcGFja2V0cyBhcmUg Y2xhc3NpZmllZCB1bmRlciB0aGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGJ1dCByZXByZXNlbnQg ZGlmZmVyZW50IGluc3RhbmNlcy4NCg0KDQpGcm9tOiAibWVuZy53ZWkyQHp0ZS5jb20uY248bWFp bHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPiIgPG1lbmcud2VpMkB6dGUuY29tLmNuPG1haWx0bzpt ZW5nLndlaTJAenRlLmNvbS5jbj4+DQpEYXRlOiBTdW5kYXksIEZlYnJ1YXJ5IDksIDIwMTQgYXQg NzoxNSBQTQ0KVG86IENpc2NvIEVtcGxveWVlIDxyZXBlbm5vQGNpc2NvLmNvbTxtYWlsdG86cmVw ZW5ub0BjaXNjby5jb20+Pg0KQ2M6ICJQYXVsIFF1aW5uIChwYXVscSkiIDxwYXVscUBjaXNjby5j b208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Piwgc2ZjIDxzZmMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4t c2ZjLWFyY2gtMDQudHh0DQoNCg0KSGnvvIwNCg0KICBGb3IgUmVpbmFsZG8ncyBjb21tZW50cyAy Lg0KICBJJ20gbm90IHN1cmUgIlNGIiAmICJTRiBpbnN0YW5jZSIgY29uZnVzZSBtZSBpbiB0aGUg ZHJhZnQuDQoNCiAgRm9yIGV4YW1wbGUsIE5BVDQ0IHdpdGggYSBydWxlIGlzIGEgU0YsIE5BVDQ0 IHdpdGggYW5vdGhlciBydWxlIGlzDQphIGRpZmZlcmVudCBTRi4gIFRoaXMgaXMgbXkgdW5kZXJz dGFuZGluZyBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaW4NCnRoZSBkcmFmdC4gICAoT3IgYSBz YW1lIFNGIGJ1dCBkaWZmZXJlbnQgU0YgaW5zdGFuY2VzPykNCg0KDQpUaGFua3MsDQpXZWkNCg0K DQoic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Pj4gIDIwMTQtMDEtMzAgMTQ6MjY6NTU6DQoNCj4gSGkgUGF1bCwNCj4NCj4gUmV2aWV3aW5nIHRo aXMgZHJhZnQgYW5kIGNvbXBhcmluZyB3aXRoIHRoZSBZYW5nIG1vZGVsIEkgaGF2ZSBhIGNvdXBs ZSBvZg0KPiBjb21tZW50cw0KPg0KPiAxIC0NCj4NCj4gSSBub3RpY2VkIHRoYXQgYSBTRklEIGFu ZCBTRkMtZG9tYWluIG1pZ2h0IG5lZWQgbW9yZSB3b3JkaW5nLg0KPg0KPiAiU2VydmljZSBGdW5j dGlvbiBJZGVudGl0eSAoU0ZJRCk6ICBBIHVuaXF1ZSBpZGVudGlmaWVyIHRoYXQNCj4gICAgICAg cmVwcmVzZW50cyBhIHNlcnZpY2UgZnVuY3Rpb24uICBTRklEcyBhcmUgdW5pcXVlIGZvciBlYWNo IFNGDQo+ICAgICAgIHdpdGhpbiBhbiBTRkMgZG9tYWluLsKyDQo+DQo+ICJTRkMtZG9tYWluIiBp cyB1c2VkIHdpdGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQgdGhlbiB0aGUgZHJhZnQNCj4g c3dpdGNoZXMgdG8gImFkbWluaXN0cmF0aXZlIGRvbWFpbsKyIGV2ZXJ5d2hlcmUgZWxzZS4NCj4N Cj4gQWxzbywgdGhlIGRlZmluaXRpb24gb2YgU2VydmljZSBGdW5jdGlvbiB1c2VzIMKzYWRtaW5p c3RyYXRpdmUgZG9tYWluwrINCj4gaW5zdGVhZCBvZiBvZiAiU0ZDLWRvbWFpbiIuDQo+DQo+DQo+ IDIgLQ0KPg0KPiBJdCBzZWVtcyB3ZXJlIGFyZSBtaXNzaW5nIHRoZSBkZWZpbml0aW9uIG9mIGEg aW5zdGFudGlhdGVkIFNlcnZpY2UNCj4gRnVuY3Rpb246DQo+DQo+IEEgU2VydmljZSBGdW5jdGlv biBpcyBzb21ldGhpbmcgbGlrZSBOQVQ0NCwgRmlyZXdhbGwsIGV0Yy4gSXQgZGVub3RlcyBhDQo+ IGNsYXNzIG9mIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSB0aGUgc2FtZSBmdW5jdGlvbi4NCj4NCj4g QSBTRkMgaXMgYW4gb3JkZXJlZCBzZXQgb2YgU0ZzLg0KPg0KPiBBIFNGUCBpcyBhbiBpbnN0YW50 aWF0aW9uIG9mIGEgU0ZDLiBTbywgd2hhdCBkbyB3ZSBjYWxsIHRoZSBTRnMgdGhhdCBhcmUNCj4g aW5zdGFudGlhdGVkIGFuZCBwYXJ0IG9mIHRoZSBTRlA/IFdlIGNhbiBub3QgY2FsbCB0aGVtIFNl cnZpY2UgRnVuY3Rpb25zDQo+IGFnYWluIGJlY2F1c2Ugd2UgYXJlIG5vdyB0YWxraW5nIGFib3V0 IGFuIHNwZWNpZmljIHNlcnZpY2UgYW5kIHRoYXQgd291bGQNCj4gY2F1c2UgY29uZnVzaW9uLiBE byB3ZSBjYWxsIHRoZW0gIlNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzwrIgYW5kDQo+IHRoZXJl Zm9yZSBhIFNGUCBpcyBjb21wb3NlZCBvZiBhbiBvcmRlcmVkIHNldCBvZiBTZXJ2aWNlIEZ1bmN0 aW9uDQo+IEluc3RhbmNlcz8NCj4NCj4gVGhhbmtzLA0KPg0KPiAtUlANCj4NCj4gT24gMS8yOS8x NCwgNjo1OCBBTSwgIlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86 cGF1bHFAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+ID5IaSBmb2xrcywNCj4gPg0KPiA+VGhlIG9u bHkgY2hhbmdlIHRvIHRoaXMgdmVyc2lvbiBpcyB0aGF0IHdlIG1vdmVkIHRvIHR3byBlZGl0b3Jz LCBhbmQNCj4gPmxpc3RlZCB0aGUgb3RoZXIgY28tYXV0aG9ycyBpbiBhIGNvbnRyaWJ1dG9ycyBz ZWN0aW9uLg0KPiA+DQo+ID5BcyBhbHdheXMsIHlvdXIgY29tbWVudHMgYW5kIGZlZWRiYWNrIGlz IGFwcHJlY2lhdGVkIQ0KPiA+UGF1bA0KPiA+DQo+ID4NCj4gPj4NCj4gPj4gQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KPiA+PiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhdWwgUXVpbm4gYW5kIHBvc3RlZCB0byB0aGUNCj4gPj4g SUVURiByZXBvc2l0b3J5Lg0KPiA+Pg0KPiA+PiBOYW1lOiAgICAgIGRyYWZ0LXF1aW5uLXNmYy1h cmNoDQo+ID4+IFJldmlzaW9uOiAgIDA0DQo+ID4+IFRpdGxlOiAgICAgIFNlcnZpY2UgRnVuY3Rp b24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlDQo+ID4+IERvY3VtZW50IGRhdGU6ICAgMjAx NC0wMS0yOA0KPiA+PiBHcm91cDogICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPj4gUGFn ZXM6ICAgICAgMjENCj4gPj4gVVJMOg0KPiA+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KPiA+PiBTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFyY2gvDQo+ ID4+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1xdWlu bi1zZmMtYXJjaC0wNA0KPiA+PiBEaWZmOg0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgdXNlZCBmb3IgdGhlIGNyZWF0 aW9uIG9maHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcXVpbm4tc2ZjLWFy Y2gtMDQNCj4gPj4gICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlucyAoU0ZDKS4gIEl0IGluY2x1ZGVz IGFyY2hpdGVjdHVyYWwgY29uY2VwdHMsDQo+ID4+ICAgcHJpbmNpcGxlcywgYW5kIGNvbXBvbmVu dHMgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uIG9mIGNvbXBvc2l0ZQ0KPiA+PiAgIHNlcnZpY2Vz IHRocm91Z2ggZGVwbG95bWVudCBvZiBTRkNzIGluIGEgbmV0d29yay4gIFRoaXMgZG9jdW1lbnQg ZG9lcw0KPiA+PiAgIG5vdCBwcm9wb3NlIHNvbHV0aW9ucywgcHJvdG9jb2xzLCBvciBleHRlbnNp b25zIHRvIGV4aXN0aW5nDQo+ID4+ICAgcHJvdG9jb2xzLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPiA+PnN1Ym1pc3Npb24NCj4gPj4gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4N Cj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4NCj4gPg0KPiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4g PnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg== --_000_CF1E8DFB15390jguicharciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8EA9DC762B7CCD4BA059C192B85CB2F8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb24sPC9k aXY+DQo8ZGl2PlNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgYXJlIGFjdHVhbGx5IDMgZGlmZmVyZW50 IHRoaW5ncyBoZXJlOjwvZGl2Pg0KPG9sPg0KPGxpPkEgc2VydmljZSBmdW5jdGlvbiB0aGF0IGlz IGFibGUgdG8gYXBwbHkgcG9saWN5LXNldC1BIGFuZCBwb2xpY3ktc2V0LUIgYW5kIGhhcyBhbiBp bnRlcm5hbCBtZWNoYW5pc20gZm9yIGRpc3RpbmN0aW9uIGJldHdlZW4gd2hpY2ggcG9saWN5IHRv IGFwcGx5IHRvIGluYm91bmQgdHJhZmZpYy4gSW4gdGhpcyBjYXNlIGl0IGlzIGEgc2luZ2xlIHNl cnZpY2UgZnVuY3Rpb24gd2l0aCBpbnRlcm5hbCBjbGFzc2lmaWNhdGlvbiBiZXR3ZWVuIHdoaWNo DQogcG9saWN5IHNldCB0byBhcHBseS48L2xpPjxsaT5BIHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBh cHBsaWVzIHBvbGljeS1zZXQtQSBhbmQgYSBkaWZmZXJlbnQgc2VydmljZSBmdW5jdGlvbiB0aGF0 IGFwcGxpZXMgcG9saWN5LXNldC1CIGUuZy4gVGhleSBhcmUgdHdvIGRpc3RpbmN0IHNlcnZpY2Ug ZnVuY3Rpb25zLjwvbGk+PGxpPkEgc2VydmljZSBmdW5jdGlvbiB0aGF0IGlzIGFibGUgdG8gYXBw bHkgcG9saWN5LXNldC1BIGFuZCBwb2xpY3ktc2V0LUIgYW5kIHJlbGllcyB1cG9uIGluZGljYXRp b24gd2l0aGluIHRoZSBpbmJvdW5kIHBhY2tldCB0byBkZXRlcm1pbmUgd2hpY2ggcG9saWN5IHNl dCB0byBhcHBseS4gSW4gdGhpcyBjYXNlIGl0cyBhIHNpbmdsZSBzZXJ2aWNlIGZ1bmN0aW9uIGJ1 dA0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+d2l0aG91dDwvc3Bhbj4mbmJzcDtp bnRlcm5hbCBjbGFzc2lmaWNhdGlvbi48L2xpPjwvb2w+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPlJvbiBQYXJrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgRmVicnVh cnkgMTAsIDIwMTQgYXQgMTA6MDMgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj4mcXVvdDtSZWluYWxkbyBQZW5ubyAocmVwZW5ubykmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+cmVwZW5ub0BjaXNjby5jb208L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuIj5tZW5nLndlaTJA enRlLmNvbS5jbjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptZW5nLndlaTJAenRlLmNv bS5jbiI+bWVuZy53ZWkyQHp0ZS5jb20uY248L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPlBhdWwgUXVpbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpw YXVscUBjaXNjby5jb20iPnBhdWxxQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Oywgc2ZjICZsdDs8YSBocmVm PSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJl OiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2Zj LWFyY2gtMDQudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2 PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29m ZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQw Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZp bHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R3VsaW07DQoJcGFub3NlLTE6MiAxMSA2IDAgMCAxIDEg MSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5Okd1bGltQ2hlOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDAgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAR3VsaW0iOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDAg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAR3VsaW1DaGUiOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDAgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 Ikd1bGltIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6S087fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWZvbnQtZmFtaWx5Okd1bGltQ2hlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5N ZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkkgdmll dyB0aGUgaW5zdGFuY2VzIGlzc3VlIGluIDIgZGlmZmVyZW50IHdheXMuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5GaXJzdCwgYSB0eXBlIG9mIHNlcnZp Y2UgZnVuY3Rpb24gKGkuZS4sIE5BVDQ0KSBtYXkgZXhpc3Qgd2l0aCBtdWx0aXBsZSBwb2xpY3kg c2V0cy4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIHRoaXMgcHVycG9zZSwgdGhlIGRlcGxveW1lbnQg b2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGgNCiBhIHBvbGljeSBzZXQgaXMgYW4gaW5zdGFuY2Uu Jm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlLCBOQVQ0NC13aXRoLXBvbGljeS1zZXQtQSBpcyBvbmUg aW5zdGFuY2Ugd2hpbGUgTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUIgaXMgYW5vdGhlciBpbnN0YW5j ZS4mbmJzcDsmbmJzcDsgRnJvbSBhIGNoYWluIHBlcnNwZWN0aXZlLCBjaGFpbiAxIG1pZ2h0IGNv bnRhaW4gTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUEgd2hpbGUgY2hhaW4gMiBtaWdodCBjb250YWlu IE5BVDQ0LXdpdGgtcG9saWN5LXNldC1CLiZuYnNwOyZuYnNwOyZuYnNwOw0KIFRoZSBhY3R1YWwg bG9jYXRpb24gb2YgdGhlIHRob3NlIDIgaW5zdGFuY2VzIGlzIGFyYml0cmFyeSDigJMgaXQgaXMg cG9zc2libGUgdGhhdCB0aGV5IGFyZSBsb2NhdGVkIHRvIHRoZSBzYW1lIHBoeXNpY2FsIGFuZC9v ciB2aXJ0dWFsIGNvbXB1dGUgbm9kZSBvciBkaWZmZXJlbnQuJm5ic3A7Jm5ic3A7IEl0IGlzIGV2 ZW4gcG9zc2libGUgdGhhdCB0aGUgMiBsb2dpY2FsIGluc3RhbmNlcyBhcmUgcmVhbGl6ZWQgYnkg dGhlIGV4YWN0IHNhbWUgc2V0IG9mIHByb2Nlc3Nlcw0KIGV4ZWN1dGluZyBvbiB0aGUgZXhhY3Qg c2FtZSBjb21wdXRlIG5vZGUsIG9yIGF0IHRoZSBvdGhlciBleHRyZW1lLCB0aGV5IGNvdWxkIGJl IGxvY2F0ZWQgaW4gZGlmZmVyZW50IGNvdW50cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5TZWNvbmQsIGEgcGFydGljdWxhciBzZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlIChpLmUuLCBOQVQ0NC13aXRoLXBvbGljeS1zZXQtQSkgbWF5LCBpdHNlbGYs IGJlIG11bHRpcGx5IGluc3RhbnRpYXRlZCBmb3IgbG9hZCBiYWxhbmNpbmcgb3IgcmVzaWxpZW5j eQ0KIHB1cnBvc2VzLiZuYnNwOyZuYnNwOyBJIGNvbnNpZGVyIHRoaXMgYXNwZWN0IHdpdGhpbiB0 aGUgcmVhbG0gb2Yg4oCcY2hhaW4gdG8gcGF0aCByZWR1Y3Rpb27igJ0uJm5ic3A7Jm5ic3A7IFRo YXQsIGlzIHRoZSBoaWdoIGxldmVsIGNoYWluIHNwZWNpZmllZCB0aGUgbmVlZCBmb3IgTkFUNDQt d2l0aC1wb2xpY3ktc2V0LUEsIGJ1dCB0aGUgYWN0dWFsIGNoYWluIGludm9rZWQgZm9yIGEgcGFy dGljdWxhciBmbG93IG11c3QgZW5kIHVwIHN0ZWVyaW5nIHRoZSB0cmFmZmljIHRvIHNvbWUgcGFy dGljdWxhcg0KIGluc3RhbmNlIG9mIHRoYXQgbG9naWNhbCBzZXJ2aWNlIGZ1bmN0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOyZuYnNwOyBS b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDk6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbiI+bWVuZy53ZWkyQHp0ZS5jb20uY248L2E+PGJy Pg0KPGI+Q2M6PC9iPiBQYXVsIFF1aW5uIChwYXVscSk7IHNmYzsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nm Y10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLXNmYy1hcmNo LTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5UaGUgU2VydmljZSBGdW5jdGlvbiBO QVQ0NCByZXByZXNlbnRzIHRoZSBmdW5jdGlvbnMgYSBOQVQ0NCBwZXJmb3JtcywgJm5ic3A7aS5l LiBUcmFuc2xhdGUgc291cmNlIElQdjQgcGFja2V0cywgY3JlYXRlIG1hcHBpbmdzLCBldGMuIEJ1 dCBhIFNlcnZpY2UgRnVuY3Rpb24gZG9lcw0KIG5vdCBwcm9jZXNzIHBhY2tldHMsIGl0IGlzIGp1 c3QgYSB0ZW1wbGF0ZSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkEgc2VydmljZSBpbnN0YW5jZSBhY3R1YWxseSBw cm9jZXNzZXMgcGFja2V0cyBhbmQgaXMgcGFydCBvZiBhIFNlcnZpY2UgUGF0aC4gJm5ic3A7U28s IHR3byBkaWZmZXJlbnQgTkFUNDQgZGV2aWNlcyB0aGF0IHByb2Nlc3MgcGFja2V0cyBhcmUgY2xh c3NpZmllZCB1bmRlciB0aGUNCiBzYW1lIHNlcnZpY2UgZnVuY3Rpb24gYnV0IHJlcHJlc2VudCBk aWZmZXJlbnQgaW5zdGFuY2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog YmxhY2s7Ij4mcXVvdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPm1lbmcud2VpMkB6dGUuY29tLmNuPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJs YWNrOyI+JnF1b3Q7DQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWVuZy53ZWkyQHp0ZS5j b20uY24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+bWVuZy53ZWkyQHp0ZS5jb20uY248L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogYmxhY2s7Ij4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgRmVicnVhcnkgOSwgMjAx NCBhdCA3OjE1IFBNPGJyPg0KPGI+VG86IDwvYj5DaXNjbyBFbXBsb3llZSAmbHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5yZXBlbm5vQGNpc2NvLmNv bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O1BhdWwgUXVpbm4gKHBhdWxxKSZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpw YXVscUBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+cGF1bHFAY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IGJsYWNrOyI+Jmd0OywgJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr OyI+JnF1b3Q7DQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZndDssIHNm YyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkhpPC9zcGFuPjxzcGFuIGxhbmc9IktPIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+77yMPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiBibGFjazsiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZuYnNwOyBG b3IgUmVpbmFsZG8ncyBjb21tZW50cyAyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsgSSdtIG5vdCBzdXJlICZxdW90 O1NGJnF1b3Q7ICZhbXA7ICZxdW90O1NGIGluc3RhbmNlJnF1b3Q7IGNvbmZ1c2UgbWUgaW4gdGhl IGRyYWZ0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48YnI+DQo8YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDsgRm9yIGV4YW1wbGUsIE5BVDQ0IHdpdGggYSBydWxl IGlzIGEgU0YsIE5BVDQ0IHdpdGggYW5vdGhlciBydWxlIGlzDQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+YSBkaWZmZXJlbnQg U0YuICZuYnNwO1RoaXMgaXMgbXkgdW5kZXJzdGFuZGluZyBiYXNlZCBvbiB0aGUgZGVzY3JpcHRp b24gaW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+dGhlIGRyYWZ0LiAmbmJzcDsgKE9yIGEgc2FtZSBTRiBidXQgZGlmZmVyZW50 IFNGIGluc3RhbmNlcz8pDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PGJyPg0KPGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IGJsYWNrOyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+VGhhbmtzLDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7 Ij5XZWk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PGJyPg0KPGJyPg0KPGJyPg0KPC9z cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7 c2ZjJnF1b3Q7ICZsdDs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZuYnNwOzIwMTQtMDEtMzAgMTQ6MjY6NTU6PC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1D aGU7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjx0dD4mZ3Q7IEhpIFBhdWwsPC90dD48YnI+DQo8 dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFJldmlld2luZyB0aGlzIGRyYWZ0IGFuZCBjb21w YXJpbmcgd2l0aCB0aGUgWWFuZyBtb2RlbCBJIGhhdmUgYSBjb3VwbGUgb2Y8L3R0Pjxicj4NCjx0 dD4mZ3Q7IGNvbW1lbnRzPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDEg LSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgSSBub3RpY2VkIHRoYXQg YSBTRklEIGFuZCBTRkMtZG9tYWluIG1pZ2h0IG5lZWQgbW9yZSB3b3JkaW5nLjwvdHQ+PGJyPg0K PHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmcXVvdDtTZXJ2aWNlIEZ1bmN0aW9uIElkZW50 aXR5IChTRklEKTogJm5ic3A7QSB1bmlxdWUgaWRlbnRpZmllciB0aGF0PC90dD48YnI+DQo8dHQ+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXByZXNlbnRzIGEgc2VydmljZSBmdW5jdGlvbi4g Jm5ic3A7U0ZJRHMgYXJlIHVuaXF1ZSBmb3IgZWFjaCBTRjwvdHQ+PGJyPg0KPHR0PiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgd2l0aGluIGFuIFNGQyBkb21haW4uwrI8L3R0Pjxicj4NCjx0dD4m Z3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJnF1b3Q7U0ZDLWRvbWFpbiZxdW90OyBpcyB1c2VkIHdp dGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQgdGhlbiB0aGUgZHJhZnQ8L3R0Pjxicj4NCjx0 dD4mZ3Q7IHN3aXRjaGVzIHRvICZxdW90O2FkbWluaXN0cmF0aXZlIGRvbWFpbsKyIGV2ZXJ5d2hl cmUgZWxzZS48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgQWxzbywgdGhl IGRlZmluaXRpb24gb2YgU2VydmljZSBGdW5jdGlvbiB1c2VzIMKzYWRtaW5pc3RyYXRpdmUgZG9t YWluwrI8L3R0Pjxicj4NCjx0dD4mZ3Q7IGluc3RlYWQgb2Ygb2YgJnF1b3Q7U0ZDLWRvbWFpbiZx dW90Oy48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8 dHQ+Jmd0OyAyIC0gPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEl0IHNl ZW1zIHdlcmUgYXJlIG1pc3NpbmcgdGhlIGRlZmluaXRpb24gb2YgYSBpbnN0YW50aWF0ZWQgU2Vy dmljZTwvdHQ+PGJyPg0KPHR0PiZndDsgRnVuY3Rpb246PC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0 Pjxicj4NCjx0dD4mZ3Q7IEEgU2VydmljZSBGdW5jdGlvbiBpcyBzb21ldGhpbmcgbGlrZSBOQVQ0 NCwgRmlyZXdhbGwsIGV0Yy4gSXQgZGVub3RlcyBhPC90dD48YnI+DQo8dHQ+Jmd0OyBjbGFzcyBv ZiBzZXJ2aWNlcyB0aGF0IHByb3ZpZGUgdGhlIHNhbWUgZnVuY3Rpb24uPC90dD48YnI+DQo8dHQ+ Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEEgU0ZDIGlzIGFuIG9yZGVyZWQgc2V0IG9mIFNGcy48 L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgQSBTRlAgaXMgYW4gaW5zdGFu dGlhdGlvbiBvZiBhIFNGQy4gU28sIHdoYXQgZG8gd2UgY2FsbCB0aGUgU0ZzIHRoYXQgYXJlPC90 dD48YnI+DQo8dHQ+Jmd0OyBpbnN0YW50aWF0ZWQgYW5kIHBhcnQgb2YgdGhlIFNGUD8gV2UgY2Fu IG5vdCBjYWxsIHRoZW0gU2VydmljZSBGdW5jdGlvbnM8L3R0Pjxicj4NCjx0dD4mZ3Q7IGFnYWlu IGJlY2F1c2Ugd2UgYXJlIG5vdyB0YWxraW5nIGFib3V0IGFuIHNwZWNpZmljIHNlcnZpY2UgYW5k IHRoYXQgd291bGQ8L3R0Pjxicj4NCjx0dD4mZ3Q7IGNhdXNlIGNvbmZ1c2lvbi4gRG8gd2UgY2Fs bCB0aGVtICZxdW90O1NlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzwrIgYW5kPC90dD48YnI+DQo8 dHQ+Jmd0OyB0aGVyZWZvcmUgYSBTRlAgaXMgY29tcG9zZWQgb2YgYW4gb3JkZXJlZCBzZXQgb2Yg U2VydmljZSBGdW5jdGlvbjwvdHQ+PGJyPg0KPHR0PiZndDsgSW5zdGFuY2VzPzwvdHQ+PGJyPg0K PHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBUaGFua3MsPC90dD48YnI+DQo8dHQ+Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7IC1SUDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+ Jmd0OyBPbiAxLzI5LzE0LCA2OjU4IEFNLCAmcXVvdDtQYXVsIFF1aW5uIChwYXVscSkmcXVvdDsg Jmx0OzwvdHQ+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwYXVscUBjaXNjby5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5wYXVscUBjaXNjby5j b208L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+Jmd0OyB3cm90ZTo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+ DQo8dHQ+Jmd0OyAmZ3Q7SGkgZm9sa3MsPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7PC90dD48YnI+ DQo8dHQ+Jmd0OyAmZ3Q7VGhlIG9ubHkgY2hhbmdlIHRvIHRoaXMgdmVyc2lvbiBpcyB0aGF0IHdl IG1vdmVkIHRvIHR3byBlZGl0b3JzLCBhbmQ8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDtsaXN0ZWQg dGhlIG90aGVyIGNvLWF1dGhvcnMgaW4gYSBjb250cmlidXRvcnMgc2VjdGlvbi48L3R0Pjxicj4N Cjx0dD4mZ3Q7ICZndDs8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDtBcyBhbHdheXMsIHlvdXIgY29t bWVudHMgYW5kIGZlZWRiYWNrIGlzIGFwcHJlY2lhdGVkITwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0 O1BhdWw8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDs8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDs8L3R0 Pjxicj4NCjx0dD4mZ3Q7ICZndDsmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dDwvdHQ+PGJyPg0K PHR0PiZndDsgJmd0OyZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVs IFF1aW5uIGFuZCBwb3N0ZWQgdG8gdGhlPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyBJRVRG IHJlcG9zaXRvcnkuPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyA8L3R0Pjxicj4NCjx0dD4m Z3Q7ICZndDsmZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtcXVpbm4tc2ZjLWFy Y2g8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsmZ3Q7IFJldmlzaW9uOiAmbmJzcDsgMDQ8L3R0Pjxi cj4NCjx0dD4mZ3Q7ICZndDsmZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlPC90dD48YnI+DQo8dHQ+Jmd0OyAm Z3Q7Jmd0OyBEb2N1bWVudCBkYXRlOiAmbmJzcDsgMjAxNC0wMS0yODwvdHQ+PGJyPg0KPHR0PiZn dDsgJmd0OyZndDsgR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNz aW9uPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyBQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJz cDsyMTwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDs8L3R0Pjwv c3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1x dWlubi1zZmMtYXJjaC0wNC50eHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Okd1bGltQ2hlIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1xdWlubi1zZmMtYXJjaC0wNC50eHQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8dHQ+Jmd0OyAm Z3Q7Jmd0OyBTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L3R0Pjwvc3Bhbj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMt YXJjaC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMtYXJjaC88 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGlt Q2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyBIdG1saXplZDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1xdWlubi1zZmMtYXJjaC0wNDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjx0dD4mZ3Q7ICZndDsm Z3Q7IERpZmY6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3R0Pjxicj4NCjx0 dD4mZ3Q7ICZndDsmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgQWJzdHJhY3Q6PC90 dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YW4gYXJjaGl0ZWN0dXJlIHVzZWQgZm9yIHRoZSBjcmVhdGlvbiBvZjwvdHQ+PC9zcGFuPjxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXF1aW5uLXNmYy1hcmNo LTA0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6R3VsaW1DaGUiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+ PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgJm5ic3A7IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIChT RkMpLiAmbmJzcDtJdCBpbmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNvbmNlcHRzLDwvdHQ+PGJyPg0K PHR0PiZndDsgJmd0OyZndDsgJm5ic3A7IHByaW5jaXBsZXMsIGFuZCBjb21wb25lbnRzIHVzZWQg aW4gdGhlIGNvbnN0cnVjdGlvbiBvZiBjb21wb3NpdGU8L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsm Z3Q7ICZuYnNwOyBzZXJ2aWNlcyB0aHJvdWdoIGRlcGxveW1lbnQgb2YgU0ZDcyBpbiBhIG5ldHdv cmsuICZuYnNwO1RoaXMgZG9jdW1lbnQgZG9lczwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsg Jm5ic3A7IG5vdCBwcm9wb3NlIHNvbHV0aW9ucywgcHJvdG9jb2xzLCBvciBleHRlbnNpb25zIHRv IGV4aXN0aW5nPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgcHJvdG9jb2xzLjwv dHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyA8 L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDsmZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsg PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZjwvdHQ+PGJyPg0KPHR0PiZndDsg Jmd0OyZndDtzdWJtaXNzaW9uPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0OyB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn LjwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7Jmd0 OyBUaGUgSUVURiBTZWNyZXRhcmlhdDwvdHQ+PGJyPg0KPHR0PiZndDsgJmd0OyZndDsgPC90dD48 YnI+DQo8dHQ+Jmd0OyAmZ3Q7PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj4NCjx0dD4mZ3Q7ICZndDtz ZmMgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+Jmd0OyAmZ3Q7PC90dD48L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6R3VsaW1DaGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjx0 dD4mZ3Q7ICZndDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6R3VsaW1DaGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNo ZTtjb2xvcjpibGFjayI+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+PGJyPg0KPHR0PiZn dDsgc2ZjIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6R3VsaW1DaGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjx0 dD4mZ3Q7IDwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpH dWxpbUNoZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CF1E8DFB15390jguicharciscocom_-- From Ron_Parker@affirmednetworks.com Mon Feb 10 11:41:15 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7891A047C; Mon, 10 Feb 2014 11:41:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It1J0nNxh3Ei; Mon, 10 Feb 2014 11:41:11 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9EED61A03C9; Mon, 10 Feb 2014 11:41:11 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 11:41:10 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , "Reinaldo Penno (repenno)" , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgD//3++UA== Date: Mon, 10 Feb 2014 19:41:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A339CMBX021W3CA2exch_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:41:16 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A339CMBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEppbS4NCg0KSSBhZ3JlZS4gICBCcm9hZGx5IHNwZWFraW5nLCB0aGVyZSBhcmUgMiBkaXN0 aW5jdCB3YXlzIHRvIHNlbGVjdCBhIGRpZmZlcmVudGlhdGVkIHBvbGljeSBzZXQgZm9yIGEgcGFy dGljdWxhciBjbGFzcyBvZiBzZXJ2aWNlIGZ1bmN0aW9uLiAgIEluIHRoZSBvbmUsIGl0IGlzIGNv bnZleWVkIGltcGxpY2l0bHkgYnkgdGhlIFNGQyBjbGFzc2lmaWVyIHdoaWNoIG1lcmVseSBzcGVj aWZpZXMgdGhlIGNoYWluIGlkIOKAkyBldmVyeXRoaW5nIGVsc2UgZm9sbG93cyBmcm9tIHRoYXQu ICAgIEluIHRoZSBvdGhlciwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gdXNlcyBsb2NhbCBtZWNoYW5p c21zIHRvIGRldGVybWluZSB3aGljaCBwb2xpY3kgc2V0IHRvIGFwcGx5LiAgICBUaGUgZm9ybSB0 aGF0IHRoZSBsb2NhbCBtZWNoYW5pc21zIHRha2VzIGlzIG91dHNpZGUgb2YgdGhlIFNGQyBwdXJ2 aWV3LCBJTU8uDQoNCk9ydGhvZ29uYWwgdG8gYWxsIG9mIHRoYXQgaXMgdGhlIG11bHRpcGxlIGlu c3RhbnRpYXRpb25zIGZvciBsb2FkIGJhbGFuY2luZyBhbmQvb3IgcmVzaWVsaWVuY3kgcHVycG9z ZXMuDQoNCiAgICBSb24NCg0KDQoNCkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWls dG86amd1aWNoYXJAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAy OjEzIFBNDQpUbzogUm9uIFBhcmtlcjsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBtZW5nLndl aTJAenRlLmNvbS5jbg0KQ2M6IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnOyBzZmMN ClN1YmplY3Q6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0DQoNCkhpIFJvbiwNClNlZW1zIHRvIG1lIHRoYXQgdGhl cmUgYXJlIGFjdHVhbGx5IDMgZGlmZmVyZW50IHRoaW5ncyBoZXJlOg0KDQogIDEuICBBIHNlcnZp Y2UgZnVuY3Rpb24gdGhhdCBpcyBhYmxlIHRvIGFwcGx5IHBvbGljeS1zZXQtQSBhbmQgcG9saWN5 LXNldC1CIGFuZCBoYXMgYW4gaW50ZXJuYWwgbWVjaGFuaXNtIGZvciBkaXN0aW5jdGlvbiBiZXR3 ZWVuIHdoaWNoIHBvbGljeSB0byBhcHBseSB0byBpbmJvdW5kIHRyYWZmaWMuIEluIHRoaXMgY2Fz ZSBpdCBpcyBhIHNpbmdsZSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggaW50ZXJuYWwgY2xhc3NpZmlj YXRpb24gYmV0d2VlbiB3aGljaCBwb2xpY3kgc2V0IHRvIGFwcGx5Lg0KICAyLiAgQSBzZXJ2aWNl IGZ1bmN0aW9uIHRoYXQgYXBwbGllcyBwb2xpY3ktc2V0LUEgYW5kIGEgZGlmZmVyZW50IHNlcnZp Y2UgZnVuY3Rpb24gdGhhdCBhcHBsaWVzIHBvbGljeS1zZXQtQiBlLmcuIFRoZXkgYXJlIHR3byBk aXN0aW5jdCBzZXJ2aWNlIGZ1bmN0aW9ucy4NCiAgMy4gIEEgc2VydmljZSBmdW5jdGlvbiB0aGF0 IGlzIGFibGUgdG8gYXBwbHkgcG9saWN5LXNldC1BIGFuZCBwb2xpY3ktc2V0LUIgYW5kIHJlbGll cyB1cG9uIGluZGljYXRpb24gd2l0aGluIHRoZSBpbmJvdW5kIHBhY2tldCB0byBkZXRlcm1pbmUg d2hpY2ggcG9saWN5IHNldCB0byBhcHBseS4gSW4gdGhpcyBjYXNlIGl0cyBhIHNpbmdsZSBzZXJ2 aWNlIGZ1bmN0aW9uIGJ1dCB3aXRob3V0IGludGVybmFsIGNsYXNzaWZpY2F0aW9uLg0KDQpGcm9t OiBSb24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgMTAs IDIwMTQgYXQgMTA6MDMgQU0NClRvOiAiUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIiA8cmVwZW5u b0BjaXNjby5jb208bWFpbHRvOnJlcGVubm9AY2lzY28uY29tPj4sICJtZW5nLndlaTJAenRlLmNv bS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+IiA8bWVuZy53ZWkyQHp0ZS5jb20uY248 bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4NCkNjOiBQYXVsIFF1aW5uIDxwYXVscUBjaXNj by5jb208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Piwgc2ZjIDxzZmMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1xdWlubi1z ZmMtYXJjaC0wNC50eHQNCg0KTWVuZywNCg0KSSB2aWV3IHRoZSBpbnN0YW5jZXMgaXNzdWUgaW4g MiBkaWZmZXJlbnQgd2F5cy4NCg0KRmlyc3QsIGEgdHlwZSBvZiBzZXJ2aWNlIGZ1bmN0aW9uIChp LmUuLCBOQVQ0NCkgbWF5IGV4aXN0IHdpdGggbXVsdGlwbGUgcG9saWN5IHNldHMuICAgIEZvciB0 aGlzIHB1cnBvc2UsIHRoZSBkZXBsb3ltZW50IG9mIGEgc2VydmljZSBmdW5jdGlvbiB3aXRoIGEg cG9saWN5IHNldCBpcyBhbiBpbnN0YW5jZS4gICBGb3IgZXhhbXBsZSwgTkFUNDQtd2l0aC1wb2xp Y3ktc2V0LUEgaXMgb25lIGluc3RhbmNlIHdoaWxlIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1CIGlz IGFub3RoZXIgaW5zdGFuY2UuICAgRnJvbSBhIGNoYWluIHBlcnNwZWN0aXZlLCBjaGFpbiAxIG1p Z2h0IGNvbnRhaW4gTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUEgd2hpbGUgY2hhaW4gMiBtaWdodCBj b250YWluIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1CLiAgICBUaGUgYWN0dWFsIGxvY2F0aW9uIG9m IHRoZSB0aG9zZSAyIGluc3RhbmNlcyBpcyBhcmJpdHJhcnkg4oCTIGl0IGlzIHBvc3NpYmxlIHRo YXQgdGhleSBhcmUgbG9jYXRlZCB0byB0aGUgc2FtZSBwaHlzaWNhbCBhbmQvb3IgdmlydHVhbCBj b21wdXRlIG5vZGUgb3IgZGlmZmVyZW50LiAgIEl0IGlzIGV2ZW4gcG9zc2libGUgdGhhdCB0aGUg MiBsb2dpY2FsIGluc3RhbmNlcyBhcmUgcmVhbGl6ZWQgYnkgdGhlIGV4YWN0IHNhbWUgc2V0IG9m IHByb2Nlc3NlcyBleGVjdXRpbmcgb24gdGhlIGV4YWN0IHNhbWUgY29tcHV0ZSBub2RlLCBvciBh dCB0aGUgb3RoZXIgZXh0cmVtZSwgdGhleSBjb3VsZCBiZSBsb2NhdGVkIGluIGRpZmZlcmVudCBj b3VudHJpZXMuDQoNClNlY29uZCwgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFu Y2UgKGkuZS4sIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1BKSBtYXksIGl0c2VsZiwgYmUgbXVsdGlw bHkgaW5zdGFudGlhdGVkIGZvciBsb2FkIGJhbGFuY2luZyBvciByZXNpbGllbmN5IHB1cnBvc2Vz LiAgIEkgY29uc2lkZXIgdGhpcyBhc3BlY3Qgd2l0aGluIHRoZSByZWFsbSBvZiDigJxjaGFpbiB0 byBwYXRoIHJlZHVjdGlvbuKAnS4gICBUaGF0LCBpcyB0aGUgaGlnaCBsZXZlbCBjaGFpbiBzcGVj aWZpZWQgdGhlIG5lZWQgZm9yIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1BLCBidXQgdGhlIGFjdHVh bCBjaGFpbiBpbnZva2VkIGZvciBhIHBhcnRpY3VsYXIgZmxvdyBtdXN0IGVuZCB1cCBzdGVlcmlu ZyB0aGUgdHJhZmZpYyB0byBzb21lIHBhcnRpY3VsYXIgaW5zdGFuY2Ugb2YgdGhhdCBsb2dpY2Fs IHNlcnZpY2UgZnVuY3Rpb24uDQoNCiAgIFJvbg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKQ0KU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCA5OjAwIEFNDQpUbzogbWVuZy53ZWkyQHp0ZS5j b20uY248bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPg0KQ2M6IFBhdWwgUXVpbm4gKHBhdWxx KTsgc2ZjOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb c2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFy Y2gtMDQudHh0DQoNCkhpLA0KDQpUaGUgU2VydmljZSBGdW5jdGlvbiBOQVQ0NCByZXByZXNlbnRz IHRoZSBmdW5jdGlvbnMgYSBOQVQ0NCBwZXJmb3JtcywgIGkuZS4gVHJhbnNsYXRlIHNvdXJjZSBJ UHY0IHBhY2tldHMsIGNyZWF0ZSBtYXBwaW5ncywgZXRjLiBCdXQgYSBTZXJ2aWNlIEZ1bmN0aW9u IGRvZXMgbm90IHByb2Nlc3MgcGFja2V0cywgaXQgaXMganVzdCBhIHRlbXBsYXRlIGRlZmluaXRp b24uDQoNCkEgc2VydmljZSBpbnN0YW5jZSBhY3R1YWxseSBwcm9jZXNzZXMgcGFja2V0cyBhbmQg aXMgcGFydCBvZiBhIFNlcnZpY2UgUGF0aC4gIFNvLCB0d28gZGlmZmVyZW50IE5BVDQ0IGRldmlj ZXMgdGhhdCBwcm9jZXNzIHBhY2tldHMgYXJlIGNsYXNzaWZpZWQgdW5kZXIgdGhlIHNhbWUgc2Vy dmljZSBmdW5jdGlvbiBidXQgcmVwcmVzZW50IGRpZmZlcmVudCBpbnN0YW5jZXMuDQoNCg0KRnJv bTogIm1lbmcud2VpMkB6dGUuY29tLmNuPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj4iIDxt ZW5nLndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+Pg0KRGF0ZTog U3VuZGF5LCBGZWJydWFyeSA5LCAyMDE0IGF0IDc6MTUgUE0NClRvOiBDaXNjbyBFbXBsb3llZSA8 cmVwZW5ub0BjaXNjby5jb208bWFpbHRvOnJlcGVubm9AY2lzY28uY29tPj4NCkNjOiAiUGF1bCBR dWlubiAocGF1bHEpIiA8cGF1bHFAY2lzY28uY29tPG1haWx0bzpwYXVscUBjaXNjby5jb20+Piwg InNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPj4sIHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBSZTogW3NmY10gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dA0KDQoNCkhp77yMDQoN CiAgRm9yIFJlaW5hbGRvJ3MgY29tbWVudHMgMi4NCiAgSSdtIG5vdCBzdXJlICJTRiIgJiAiU0Yg aW5zdGFuY2UiIGNvbmZ1c2UgbWUgaW4gdGhlIGRyYWZ0Lg0KDQogIEZvciBleGFtcGxlLCBOQVQ0 NCB3aXRoIGEgcnVsZSBpcyBhIFNGLCBOQVQ0NCB3aXRoIGFub3RoZXIgcnVsZSBpcw0KYSBkaWZm ZXJlbnQgU0YuICBUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgYmFzZWQgb24gdGhlIGRlc2NyaXB0 aW9uIGluDQp0aGUgZHJhZnQuICAgKE9yIGEgc2FtZSBTRiBidXQgZGlmZmVyZW50IFNGIGluc3Rh bmNlcz8pDQoNCg0KVGhhbmtzLA0KV2VpDQoNCg0KInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+ICAyMDE0LTAxLTMwIDE0OjI2OjU1Og0KDQo+ IEhpIFBhdWwsDQo+DQo+IFJldmlld2luZyB0aGlzIGRyYWZ0IGFuZCBjb21wYXJpbmcgd2l0aCB0 aGUgWWFuZyBtb2RlbCBJIGhhdmUgYSBjb3VwbGUgb2YNCj4gY29tbWVudHMNCj4NCj4gMSAtDQo+ DQo+IEkgbm90aWNlZCB0aGF0IGEgU0ZJRCBhbmQgU0ZDLWRvbWFpbiBtaWdodCBuZWVkIG1vcmUg d29yZGluZy4NCj4NCj4gIlNlcnZpY2UgRnVuY3Rpb24gSWRlbnRpdHkgKFNGSUQpOiAgQSB1bmlx dWUgaWRlbnRpZmllciB0aGF0DQo+ICAgICAgIHJlcHJlc2VudHMgYSBzZXJ2aWNlIGZ1bmN0aW9u LiAgU0ZJRHMgYXJlIHVuaXF1ZSBmb3IgZWFjaCBTRg0KPiAgICAgICB3aXRoaW4gYW4gU0ZDIGRv bWFpbi7Csg0KPg0KPiAiU0ZDLWRvbWFpbiIgaXMgdXNlZCB3aXRoaW4gdGhlIGRlZmluaXRpb24g YWJvdmUgYnV0IHRoZW4gdGhlIGRyYWZ0DQo+IHN3aXRjaGVzIHRvICJhZG1pbmlzdHJhdGl2ZSBk b21haW7CsiBldmVyeXdoZXJlIGVsc2UuDQo+DQo+IEFsc28sIHRoZSBkZWZpbml0aW9uIG9mIFNl cnZpY2UgRnVuY3Rpb24gdXNlcyDCs2FkbWluaXN0cmF0aXZlIGRvbWFpbsKyDQo+IGluc3RlYWQg b2Ygb2YgIlNGQy1kb21haW4iLg0KPg0KPg0KPiAyIC0NCj4NCj4gSXQgc2VlbXMgd2VyZSBhcmUg bWlzc2luZyB0aGUgZGVmaW5pdGlvbiBvZiBhIGluc3RhbnRpYXRlZCBTZXJ2aWNlDQo+IEZ1bmN0 aW9uOg0KPg0KPiBBIFNlcnZpY2UgRnVuY3Rpb24gaXMgc29tZXRoaW5nIGxpa2UgTkFUNDQsIEZp cmV3YWxsLCBldGMuIEl0IGRlbm90ZXMgYQ0KPiBjbGFzcyBvZiBzZXJ2aWNlcyB0aGF0IHByb3Zp ZGUgdGhlIHNhbWUgZnVuY3Rpb24uDQo+DQo+IEEgU0ZDIGlzIGFuIG9yZGVyZWQgc2V0IG9mIFNG cy4NCj4NCj4gQSBTRlAgaXMgYW4gaW5zdGFudGlhdGlvbiBvZiBhIFNGQy4gU28sIHdoYXQgZG8g d2UgY2FsbCB0aGUgU0ZzIHRoYXQgYXJlDQo+IGluc3RhbnRpYXRlZCBhbmQgcGFydCBvZiB0aGUg U0ZQPyBXZSBjYW4gbm90IGNhbGwgdGhlbSBTZXJ2aWNlIEZ1bmN0aW9ucw0KPiBhZ2FpbiBiZWNh dXNlIHdlIGFyZSBub3cgdGFsa2luZyBhYm91dCBhbiBzcGVjaWZpYyBzZXJ2aWNlIGFuZCB0aGF0 IHdvdWxkDQo+IGNhdXNlIGNvbmZ1c2lvbi4gRG8gd2UgY2FsbCB0aGVtICJTZXJ2aWNlIEZ1bmN0 aW9uIEluc3RhbmNlc8KyIGFuZA0KPiB0aGVyZWZvcmUgYSBTRlAgaXMgY29tcG9zZWQgb2YgYW4g b3JkZXJlZCBzZXQgb2YgU2VydmljZSBGdW5jdGlvbg0KPiBJbnN0YW5jZXM/DQo+DQo+IFRoYW5r cywNCj4NCj4gLVJQDQo+DQo+IE9uIDEvMjkvMTQsIDY6NTggQU0sICJQYXVsIFF1aW5uIChwYXVs cSkiIDxwYXVscUBjaXNjby5jb208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+IHdyb3RlOg0KPg0K PiA+SGkgZm9sa3MsDQo+ID4NCj4gPlRoZSBvbmx5IGNoYW5nZSB0byB0aGlzIHZlcnNpb24gaXMg dGhhdCB3ZSBtb3ZlZCB0byB0d28gZWRpdG9ycywgYW5kDQo+ID5saXN0ZWQgdGhlIG90aGVyIGNv LWF1dGhvcnMgaW4gYSBjb250cmlidXRvcnMgc2VjdGlvbi4NCj4gPg0KPiA+QXMgYWx3YXlzLCB5 b3VyIGNvbW1lbnRzIGFuZCBmZWVkYmFjayBpcyBhcHByZWNpYXRlZCENCj4gPlBhdWwNCj4gPg0K PiA+DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1xdWlubi1zZmMtYXJj aC0wNC50eHQNCj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVsIFF1 aW5uIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4+IElFVEYgcmVwb3NpdG9yeS4NCj4gPj4NCj4gPj4g TmFtZTogICAgICBkcmFmdC1xdWlubi1zZmMtYXJjaA0KPiA+PiBSZXZpc2lvbjogICAwNA0KPiA+ PiBUaXRsZTogICAgICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEFyY2hpdGVjdHVy ZQ0KPiA+PiBEb2N1bWVudCBkYXRlOiAgIDIwMTQtMDEtMjgNCj4gPj4gR3JvdXA6ICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+IFBhZ2VzOiAgICAgIDIxDQo+ID4+IFVSTDoNCj4gPj5o dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1xdWlubi1zZmMtYXJjaC0w NC50eHQNCj4gPj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLw0KPiA+PiBIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQNCj4gPj4gRGlmZjoNCj4g Pj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYXJj aGl0ZWN0dXJlIHVzZWQgZm9yIHRoZSBjcmVhdGlvbiBvZmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0DQo+ID4+ICAgU2VydmljZSBGdW5jdGlv biBDaGFpbnMgKFNGQykuICBJdCBpbmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNvbmNlcHRzLA0KPiA+ PiAgIHByaW5jaXBsZXMsIGFuZCBjb21wb25lbnRzIHVzZWQgaW4gdGhlIGNvbnN0cnVjdGlvbiBv ZiBjb21wb3NpdGUNCj4gPj4gICBzZXJ2aWNlcyB0aHJvdWdoIGRlcGxveW1lbnQgb2YgU0ZDcyBp biBhIG5ldHdvcmsuICBUaGlzIGRvY3VtZW50IGRvZXMNCj4gPj4gICBub3QgcHJvcG9zZSBzb2x1 dGlvbnMsIHByb3RvY29scywgb3IgZXh0ZW5zaW9ucyB0byBleGlzdGluZw0KPiA+PiAgIHByb3Rv Y29scy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj5zdWJtaXNz aW9uDQo+ID4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ ID4+DQo+ID4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID5zZmMgbWFpbGluZyBsaXN0DQo+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBt YWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A339CMBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 R3VsaW07DQoJcGFub3NlLTE6MiAxMSA2IDAgMCAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okd1bGltQ2hlOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDAgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAR3VsaW0iOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxAR3VsaW1DaGUiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDAgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Ikd1bGltIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6S087fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5Okd1bGltQ2hl O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTIyNjc5 ODQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyOTg3MjQ4NTg7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSwgSmltLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SSBhZ3JlZS4mbmJzcDsmbmJzcDsgQnJvYWRseSBzcGVha2luZywgdGhlcmUgYXJlIDIg ZGlzdGluY3Qgd2F5cyB0byBzZWxlY3QgYSBkaWZmZXJlbnRpYXRlZCBwb2xpY3kgc2V0IGZvciBh IHBhcnRpY3VsYXIgY2xhc3Mgb2Ygc2VydmljZSBmdW5jdGlvbi4mbmJzcDsmbmJzcDsNCiBJbiB0 aGUgb25lLCBpdCBpcyBjb252ZXllZCBpbXBsaWNpdGx5IGJ5IHRoZSBTRkMgY2xhc3NpZmllciB3 aGljaCBtZXJlbHkgc3BlY2lmaWVzIHRoZSBjaGFpbiBpZCDigJMgZXZlcnl0aGluZyBlbHNlIGZv bGxvd3MgZnJvbSB0aGF0LiZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0aGUgb3RoZXIsIHRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIHVzZXMgbG9jYWwgbWVjaGFuaXNtcyB0byBkZXRlcm1pbmUgd2hpY2ggcG9s aWN5IHNldCB0byBhcHBseS4mbmJzcDsmbmJzcDsgJm5ic3A7VGhlIGZvcm0gdGhhdCB0aGUgbG9j YWwNCiBtZWNoYW5pc21zIHRha2VzIGlzIG91dHNpZGUgb2YgdGhlIFNGQyBwdXJ2aWV3LCBJTU8u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5PcnRob2dvbmFsIHRvIGFsbCBvZiB0aGF0IGlzIHRoZSBtdWx0aXBsZSBpbnN0YW50 aWF0aW9ucyBmb3IgbG9hZCBiYWxhbmNpbmcgYW5kL29yIHJlc2llbGllbmN5IHB1cnBvc2VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBb bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZl YnJ1YXJ5IDEwLCAyMDE0IDI6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbiBQYXJrZXI7IFJlaW5h bGRvIFBlbm5vIChyZXBlbm5vKTsgbWVuZy53ZWkyQHp0ZS5jb20uY248YnI+DQo8Yj5DYzo8L2I+ IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjQGlldGYub3JnOyBzZmM8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1xdWlu bi1zZmMtYXJjaC0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5I aSBSb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZWVtcyB0 byBtZSB0aGF0IHRoZXJlIGFyZSBhY3R1YWxseSAzIGRpZmZlcmVudCB0aGluZ3MgaGVyZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgaXMg YWJsZSB0byBhcHBseSBwb2xpY3ktc2V0LUEgYW5kIHBvbGljeS1zZXQtQiBhbmQgaGFzIGFuIGlu dGVybmFsIG1lY2hhbmlzbSBmb3IgZGlzdGluY3Rpb24gYmV0d2VlbiB3aGljaCBwb2xpY3kgdG8g YXBwbHkgdG8gaW5ib3VuZCB0cmFmZmljLiBJbiB0aGlzIGNhc2UgaXQgaXMgYSBzaW5nbGUNCiBz ZXJ2aWNlIGZ1bmN0aW9uIHdpdGggaW50ZXJuYWwgY2xhc3NpZmljYXRpb24gYmV0d2VlbiB3aGlj aCBwb2xpY3kgc2V0IHRvIGFwcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkEgc2VydmljZSBmdW5jdGlvbiB0aGF0IGFwcGxpZXMgcG9s aWN5LXNldC1BIGFuZCBhIGRpZmZlcmVudCBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgYXBwbGllcyBw b2xpY3ktc2V0LUIgZS5nLiBUaGV5IGFyZSB0d28gZGlzdGluY3Qgc2VydmljZSBmdW5jdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgaXMgYWJsZSB0byBhcHBseSBwb2xpY3ktc2V0LUEgYW5k IHBvbGljeS1zZXQtQiBhbmQgcmVsaWVzIHVwb24gaW5kaWNhdGlvbiB3aXRoaW4gdGhlIGluYm91 bmQgcGFja2V0IHRvIGRldGVybWluZSB3aGljaCBwb2xpY3kgc2V0IHRvIGFwcGx5LiBJbiB0aGlz IGNhc2UgaXRzIGEgc2luZ2xlIHNlcnZpY2UNCiBmdW5jdGlvbiBidXQgPGI+d2l0aG91dDwvYj4m bmJzcDtpbnRlcm5hbCBjbGFzc2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Sb24gUGFya2VyICZsdDs8YSBocmVmPSJt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgRmVicnVhcnkg MTAsIDIwMTQgYXQgMTA6MDMgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O1JlaW5hbGRvIFBlbm5v IChyZXBlbm5vKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlcGVubm9AY2lzY28uY29tIj5y ZXBlbm5vQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bWVuZy53ZWky QHp0ZS5jb20uY24iPm1lbmcud2VpMkB6dGUuY29tLmNuPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuIj5tZW5nLndlaTJAenRlLmNvbS5jbjwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj5QYXVsIFF1aW5uICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bHFAY2lz Y28uY29tIj5wYXVscUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDssIHNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lbmcsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHZpZXcgdGhlIGlu c3RhbmNlcyBpc3N1ZSBpbiAyIGRpZmZlcmVudCB3YXlzLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5G aXJzdCwgYSB0eXBlIG9mIHNlcnZpY2UgZnVuY3Rpb24gKGkuZS4sIE5BVDQ0KSBtYXkgZXhpc3Qg d2l0aCBtdWx0aXBsZSBwb2xpY3kgc2V0cy4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIHRoaXMgcHVy cG9zZSwgdGhlIGRlcGxveW1lbnQgb2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggYSBwb2xpY3kN CiBzZXQgaXMgYW4gaW5zdGFuY2UuJm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlLCBOQVQ0NC13aXRo LXBvbGljeS1zZXQtQSBpcyBvbmUgaW5zdGFuY2Ugd2hpbGUgTkFUNDQtd2l0aC1wb2xpY3ktc2V0 LUIgaXMgYW5vdGhlciBpbnN0YW5jZS4mbmJzcDsmbmJzcDsgRnJvbSBhIGNoYWluIHBlcnNwZWN0 aXZlLCBjaGFpbiAxIG1pZ2h0IGNvbnRhaW4gTkFUNDQtd2l0aC1wb2xpY3ktc2V0LUEgd2hpbGUg Y2hhaW4gMiBtaWdodCBjb250YWluIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1CLiZuYnNwOyZuYnNw OyZuYnNwOw0KIFRoZSBhY3R1YWwgbG9jYXRpb24gb2YgdGhlIHRob3NlIDIgaW5zdGFuY2VzIGlz IGFyYml0cmFyeSDigJMgaXQgaXMgcG9zc2libGUgdGhhdCB0aGV5IGFyZSBsb2NhdGVkIHRvIHRo ZSBzYW1lIHBoeXNpY2FsIGFuZC9vciB2aXJ0dWFsIGNvbXB1dGUgbm9kZSBvciBkaWZmZXJlbnQu Jm5ic3A7Jm5ic3A7IEl0IGlzIGV2ZW4gcG9zc2libGUgdGhhdCB0aGUgMiBsb2dpY2FsIGluc3Rh bmNlcyBhcmUgcmVhbGl6ZWQgYnkgdGhlIGV4YWN0IHNhbWUgc2V0IG9mIHByb2Nlc3Nlcw0KIGV4 ZWN1dGluZyBvbiB0aGUgZXhhY3Qgc2FtZSBjb21wdXRlIG5vZGUsIG9yIGF0IHRoZSBvdGhlciBl eHRyZW1lLCB0aGV5IGNvdWxkIGJlIGxvY2F0ZWQgaW4gZGlmZmVyZW50IGNvdW50cmllcy48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNlY29uZCwgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgZnVuY3Rpb24gaW5z dGFuY2UgKGkuZS4sIE5BVDQ0LXdpdGgtcG9saWN5LXNldC1BKSBtYXksIGl0c2VsZiwgYmUgbXVs dGlwbHkgaW5zdGFudGlhdGVkIGZvciBsb2FkIGJhbGFuY2luZyBvciByZXNpbGllbmN5IHB1cnBv c2VzLiZuYnNwOyZuYnNwOw0KIEkgY29uc2lkZXIgdGhpcyBhc3BlY3Qgd2l0aGluIHRoZSByZWFs bSBvZiDigJxjaGFpbiB0byBwYXRoIHJlZHVjdGlvbuKAnS4mbmJzcDsmbmJzcDsgVGhhdCwgaXMg dGhlIGhpZ2ggbGV2ZWwgY2hhaW4gc3BlY2lmaWVkIHRoZSBuZWVkIGZvciBOQVQ0NC13aXRoLXBv bGljeS1zZXQtQSwgYnV0IHRoZSBhY3R1YWwgY2hhaW4gaW52b2tlZCBmb3IgYSBwYXJ0aWN1bGFy IGZsb3cgbXVzdCBlbmQgdXAgc3RlZXJpbmcgdGhlIHRyYWZmaWMgdG8gc29tZSBwYXJ0aWN1bGFy IGluc3RhbmNlDQogb2YgdGhhdCBsb2dpY2FsIHNlcnZpY2UgZnVuY3Rpb24uPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgUm9uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+UmVpbmFsZG8gUGVubm8gKHJlcGVubm8pPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg RmVicnVhcnkgMTAsIDIwMTQgOTowMCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRv Om1lbmcud2VpMkB6dGUuY29tLmNuIj5tZW5nLndlaTJAenRlLmNvbS5jbjwvYT48YnI+DQo8Yj5D Yzo8L2I+IFBhdWwgUXVpbm4gKHBhdWxxKTsgc2ZjOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGksPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBTZXJ2aWNlIEZ1bmN0 aW9uIE5BVDQ0IHJlcHJlc2VudHMgdGhlIGZ1bmN0aW9ucyBhIE5BVDQ0IHBlcmZvcm1zLCAmbmJz cDtpLmUuIFRyYW5zbGF0ZSBzb3VyY2UgSVB2NCBwYWNrZXRzLCBjcmVhdGUgbWFwcGluZ3MsIGV0 Yy4gQnV0IGEgU2VydmljZSBGdW5jdGlvbiBkb2VzIG5vdA0KIHByb2Nlc3MgcGFja2V0cywgaXQg aXMganVzdCBhIHRlbXBsYXRlIGRlZmluaXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkEgc2VydmljZSBpbnN0YW5jZSBhY3R1YWxseSBwcm9jZXNzZXMg cGFja2V0cyBhbmQgaXMgcGFydCBvZiBhIFNlcnZpY2UgUGF0aC4gJm5ic3A7U28sIHR3byBkaWZm ZXJlbnQgTkFUNDQgZGV2aWNlcyB0aGF0IHByb2Nlc3MgcGFja2V0cyBhcmUgY2xhc3NpZmllZCB1 bmRlciB0aGUgc2FtZQ0KIHNlcnZpY2UgZnVuY3Rpb24gYnV0IHJlcHJlc2VudCBkaWZmZXJlbnQg aW5zdGFuY2VzLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m cXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86bWVu Zy53ZWkyQHp0ZS5jb20uY24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWVuZy53ZWky QHp0ZS5jb20uY248L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZxdW90Ow0KICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YSBocmVmPSJtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+bWVuZy53ZWkyQHp0ZS5jb20uY248L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ U3VuZGF5LCBGZWJydWFyeSA5LCAyMDE0IGF0IDc6MTUgUE08YnI+DQo8Yj5UbzogPC9iPkNpc2Nv IEVtcGxveWVlICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJt YWlsdG86cmVwZW5ub0BjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cmVw ZW5ub0BjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1BhdWwgUXVpbm4gKHBh dWxxKSZxdW90OyAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0i bWFpbHRvOnBhdWxxQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5wYXVs cUBjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZndDssDQogJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZxdW90OyAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5zZmNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDssDQogc2ZjICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFJlOiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGk8L3NwYW4+PHNwYW4gbGFuZz0iS08iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj7vvIw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7IEZvciBSZWluYWxkbydzIGNvbW1lbnRzIDIu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyBJJ20gbm90 IHN1cmUgJnF1b3Q7U0YmcXVvdDsgJmFtcDsgJnF1b3Q7U0YgaW5zdGFuY2UmcXVvdDsgY29uZnVz ZSBtZSBpbiB0aGUgZHJhZnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyBGb3IgZXhhbXBsZSwgTkFUNDQgd2l0aCBhIHJ1bGUgaXMgYSBTRiwg TkFUNDQgd2l0aCBhbm90aGVyIHJ1bGUgaXMNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5hIGRpZmZlcmVudCBTRi4gJm5ic3A7VGhpcyBpcyBteSB1bmRlcnN0YW5k aW5nIGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj50aGUgZHJhZnQuICZuYnNwOyAoT3IgYSBzYW1lIFNGIGJ1dCBkaWZm ZXJlbnQgU0YgaW5zdGFuY2VzPykNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PldlaTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZxdW90O3NmYyZxdW90OyAmbHQ7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5zZmMtYm91bmNlc0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+Jmd0Ow0KICZuYnNwOzIwMTQtMDEtMzAgMTQ6MjY6NTU6PC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29s b3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgSGkgUGF1bCw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0K PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0 OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpH dWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBSZXZpZXdpbmcgdGhpcyBkcmFmdCBhbmQgY29t cGFyaW5nIHdpdGggdGhlIFlhbmcgbW9kZWwgSSBoYXZlIGEgY291cGxlIG9mPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6 YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZndDsgY29tbWVudHM8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtj b2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+Jmd0OyAxIC0gPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7 Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPiZndDsgSSBub3RpY2VkIHRoYXQgYSBTRklEIGFuZCBTRkMtZG9tYWlu IG1pZ2h0IG5lZWQgbW9yZSB3b3JkaW5nLjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl O2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZxdW90O1NlcnZpY2UgRnVuY3Rpb24gSWRlbnRpdHkgKFNG SUQpOiAmbmJzcDtBIHVuaXF1ZSBpZGVudGlmaWVyIHRoYXQ8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXByZXNlbnRzIGEgc2VydmljZSBmdW5jdGlvbi4g Jm5ic3A7U0ZJRHMgYXJlIHVuaXF1ZSBmb3IgZWFjaCBTRjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+ DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGhpbiBhbiBTRkMgZG9tYWluLsKyPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29s b3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJnF1b3Q7U0ZDLWRv bWFpbiZxdW90OyBpcyB1c2VkIHdpdGhpbiB0aGUgZGVmaW5pdGlvbiBhYm92ZSBidXQgdGhlbiB0 aGUgZHJhZnQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBzd2l0Y2hlcyB0byAmcXVvdDthZG1p bmlzdHJhdGl2ZSBkb21haW7CsiBldmVyeXdoZXJlIGVsc2UuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgQWxzbywgdGhlIGRlZmluaXRpb24gb2Yg U2VydmljZSBGdW5jdGlvbiB1c2VzIMKzYWRtaW5pc3RyYXRpdmUgZG9tYWluwrI8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xv cjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+Jmd0OyBpbnN0ZWFkIG9mIG9mICZxdW90O1NGQy1kb21haW4mcXVvdDsuPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1D aGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7 Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPiZndDsgMiAtIDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl O2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IEl0IHNlZW1zIHdlcmUgYXJlIG1pc3NpbmcgdGhlIGRlZmlu aXRpb24gb2YgYSBpbnN0YW50aWF0ZWQgU2VydmljZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8 L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7 IEZ1bmN0aW9uOjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48 YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNr Ij4mZ3Q7IEEgU2VydmljZSBGdW5jdGlvbiBpcyBzb21ldGhpbmcgbGlrZSBOQVQ0NCwgRmlyZXdh bGwsIGV0Yy4gSXQgZGVub3RlcyBhPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgY2xhc3Mgb2Yg c2VydmljZXMgdGhhdCBwcm92aWRlIHRoZSBzYW1lIGZ1bmN0aW9uLjwvc3Bhbj48L3R0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNr Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IEEgU0ZDIGlzIGFuIG9yZGVyZWQg c2V0IG9mIFNGcy48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+ PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+Jmd0OyBBIFNGUCBpcyBhbiBpbnN0YW50aWF0aW9uIG9mIGEgU0ZDLiBTbywgd2hhdCBkbyB3 ZSBjYWxsIHRoZSBTRnMgdGhhdCBhcmU8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBpbnN0YW50 aWF0ZWQgYW5kIHBhcnQgb2YgdGhlIFNGUD8gV2UgY2FuIG5vdCBjYWxsIHRoZW0gU2VydmljZSBG dW5jdGlvbnM8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBhZ2FpbiBiZWNhdXNlIHdlIGFyZSBu b3cgdGFsa2luZyBhYm91dCBhbiBzcGVjaWZpYyBzZXJ2aWNlIGFuZCB0aGF0IHdvdWxkPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7 Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPiZndDsgY2F1c2UgY29uZnVzaW9uLiBEbyB3ZSBjYWxsIHRoZW0gJnF1 b3Q7U2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXPCsiBhbmQ8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyB0aGVyZWZvcmUgYSBTRlAgaXMgY29tcG9zZWQgb2YgYW4gb3JkZXJlZCBzZXQgb2YgU2Vy dmljZSBGdW5jdGlvbjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IEluc3RhbmNlcz88L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtj b2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBUaGFua3MsPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1D aGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgLVJQPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1D aGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgT24gMS8y OS8xNCwgNjo1OCBBTSwgJnF1b3Q7UGF1bCBRdWlubiAocGF1bHEpJnF1b3Q7ICZsdDs8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwYXVscUBjaXNj by5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl Ij5wYXVscUBjaXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsNCiB3cm90ZTo8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+ PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7SGkgZm9sa3MsPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29s b3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPiZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDtUaGUg b25seSBjaGFuZ2UgdG8gdGhpcyB2ZXJzaW9uIGlzIHRoYXQgd2UgbW92ZWQgdG8gdHdvIGVkaXRv cnMsIGFuZDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDtsaXN0ZWQgdGhlIG90aGVyIGNv LWF1dGhvcnMgaW4gYSBjb250cmlidXRvcnMgc2VjdGlvbi48L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0O0FzIGFsd2F5cywgeW91ciBj b21tZW50cyBhbmQgZmVlZGJhY2sgaXMgYXBwcmVjaWF0ZWQhPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZndDsgJmd0O1BhdWw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6 YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGlt Q2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1xdWlubi1zZmMtYXJjaC0wNC50eHQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFu Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7 Jmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhdWwgUXVpbm4gYW5kIHBv c3RlZCB0byB0aGU8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBJRVRGIHJlcG9z aXRvcnkuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgPC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6Ymxh Y2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPiZndDsgJmd0OyZndDsgTmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1xdWlu bi1zZmMtYXJjaDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IFJldmlzaW9uOiAm bmJzcDsgMDQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBUaXRsZTogJm5ic3A7 ICZuYnNwOyAmbmJzcDtTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEFyY2hpdGVjdHVy ZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1 bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNw OyAyMDE0LTAxLTI4PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgR3JvdXA6ICZu YnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2si Pjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiZndDsgJmd0OyZndDsgUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7MjE8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xv cjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDs8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGUiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0LnR4dDwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGlt Q2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IFN0YXR1czogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDwvc3Bhbj4NCjwvdHQ+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMtYXJj aC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMtYXJjaC88L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpH dWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBIdG1saXplZDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgPC9zcGFuPg0KPC90dD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZSI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcXVpbm4tc2ZjLWFyY2gtMDQ8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtj b2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBEaWZmOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29s b3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgQWJzdHJhY3Q6PC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZndDsgJmd0OyZndDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVj dHVyZSB1c2VkIGZvciB0aGUgY3JlYXRpb24gb2Y8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXF1aW5uLXNmYy1hcmNoLTA0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6R3VsaW1DaGUiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXF1aW5uLXNmYy1hcmNoLTA0PC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgJm5ic3A7IFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5zIChTRkMpLiAmbmJzcDtJdCBpbmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNvbmNl cHRzLDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyBwcmluY2lwbGVz LCBhbmQgY29tcG9uZW50cyB1c2VkIGluIHRoZSBjb25zdHJ1Y3Rpb24gb2YgY29tcG9zaXRlPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1D aGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgJm5ic3A7IHNlcnZpY2VzIHRocm91Z2gg ZGVwbG95bWVudCBvZiBTRkNzIGluIGEgbmV0d29yay4gJm5ic3A7VGhpcyBkb2N1bWVudCBkb2Vz PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3Vs aW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgJm5ic3A7IG5vdCBwcm9wb3NlIHNv bHV0aW9ucywgcHJvdG9jb2xzLCBvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6 YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZndDsgJmd0OyZndDsgJm5ic3A7IHByb3RvY29scy48L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFj ayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyA8 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxp bUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1 bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7c3VibWlzc2lvbjwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9y OmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4mZ3Q7ICZndDsmZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxi cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZndDsgJmd0OyZndDsgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0OyZndDsgVGhlIElF VEYgU2VjcmV0YXJpYXQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtj b2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgJmd0O19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6 YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPiZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpHdWxpbUNoZTtjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpHdWxpbUNoZSI+c2ZjQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4N Cjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZn dDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hl O2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6R3VsaW1DaGU7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZndDsgc2ZjIG1haWxpbmcgbGlzdDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGlt Q2hlO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6R3VsaW1DaGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlO2Nv bG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOmJsYWNrIj4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Okd1bGltQ2hlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A339CMBX021W3CA2exch_-- From repenno@cisco.com Mon Feb 10 12:21:33 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31861A046A; Mon, 10 Feb 2014 12:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9h1KhlvcWT7; Mon, 10 Feb 2014 12:21:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 262D01A01FD; Mon, 10 Feb 2014 12:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4526; q=dns/txt; s=iport; t=1392063692; x=1393273292; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=GeHPMIZtGLdcjCFYe8YDcuKAkzzla4KR0upODq5w6u8=; b=WsM0eOBkIDFhwjSbOS2NA42jZx22+gzr1Y5ZxoMHm/5zaK2TFZlukA23 WJiaga+55BXvTLq+THUYrUt85mhZcvoIkgQD1Q8YWEXBcKG1iL0dNZSmf M716FBRtFHvpwRWHqpAqrf+1a3lcS/wV7+b44uCIfnzufMq4reIpWD4oP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMsz+VKtJXHB/2dsb2JhbABZgkhEgQ+/YYEWFnSCJQECBHcCEgEIBA0DAQIoORQJCAIEAQ0FiAXJRheObBEHhDgBA5grkiCDLYIq X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208,217";a="302919564" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 10 Feb 2014 20:21:31 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AKLVHU001884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 20:21:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 14:21:31 -0600 From: "Reinaldo Penno (repenno)" To: "Jim Guichard (jguichar)" , Ron Parker , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoJqu+juAgABFpAD//40egA== Date: Mon, 10 Feb 2014 20:21:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.70.161] Content-Type: multipart/alternative; boundary="_000_CF1E73D38D67repennociscocom_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:21:33 -0000 --_000_CF1E73D38D67repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1E73D38D67repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8B7EB9AF250A4845B8AC7E8166A1E52E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Based on the definition I see this differently.

The same service function could be instantiated with  policy-set-= A and later instantiated with  policy-set-B. It is still the same serv= ice function, but different instances. 

Therefore I would consider {1 below} one service function (say, NAT44)= and two different service function instances, one that applies  polic= y-set-A and other that applies  policy-set-A.

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Monday, February 10, 2014 at = 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= Cisco Employee <repenno@cisco.com<= /a>>, "meng.wei2@zte.com.cn= " <meng.wei2@zte.com.cn> Cc: "Paul Quinn (paulq)" = <paulq@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, sfc <sfc-bounces@ietf.org>
Subject: Re: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

  1. A service function that applies policy-set-A and a different service fu= nction that applies policy-set-B e.g. They are two distinct service functio= ns.
 --_000_CF1E73D38D67repennociscocom_-- From Cathy.H.Zhang@huawei.com Mon Feb 10 12:55:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176491A0852; Mon, 10 Feb 2014 12:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.746 X-Spam-Level: X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 beDRkBEfyxRT; Mon, 10 Feb 2014 12:55:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6420C1A0836; Mon, 10 Feb 2014 12:55:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL32039; Mon, 10 Feb 2014 20:55:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 20:54:34 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 20:55:44 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 12:55:27 -0800 From: Cathy Zhang To: "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , Ron Parker , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmkUAauKj/rzmUy13AQN4o8lEpqvG8GAgABFpACAABNCAP//gUTA Date: Mon, 10 Feb 2014 20:55:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.79] Content-Type: multipart/related; boundary="_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:55:53 -0000 --_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_" --_000_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for "Service = Instance" to bring everyone on the same page as to its semantics. Thanks, Cathy [cid:image002.png@01CF265F.0FB67C80] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I share the same view as = Reinaldo.

I think each Service Func= tion is associated with a type, such as FW Service Function or NAT Service = Function

while each Service Instan= ce is an instantiation of a Service Function on a Service Node and is = associated with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, th= ere could be multiple Service Nodes (physical/virtual) that support a speci= fic Service Function, such as FW,

and a service instance co= uld be instantiated on any one of the Service Nodes (as to which Service No= de to instantiate the service instance,

it depends on load status= of the Service Nodes, network proximity etc., which is out of scope) .&nbs= p;

Multiple flow chains can = be associated with the same Service Instance on a Service Node, which means= these flows will be applied the same policy set

for that specific type of= service function, as shown in the following diagram.

 <= /p>

BTW, I would like to sugg= est that the draft adds a definition for “Service Instance” to = bring everyone on the same page as to its semantics.

 <= /p>

Thanks,=

Cathy

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I s= ee this differently.

 

The same service function c= ould be instantiated with  policy-set-A and later instantiated with &n= bsp;policy-set-B. It is still the same service function, but different instances. 

 

Therefore I would consider = {1 below} one service function (say, NAT44) and two different service funct= ion instances, one that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A service function that applies policy-set-A and a different s= ervice function that applies policy-set-B e.g. They are two distinct servic= e functions.
--_000_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_-- --_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: application/octet-stream; name="image001.emz" Content-Description: image001.emz Content-Disposition: inline; filename="image001.emz"; size=14655; creation-date="Mon, 10 Feb 2014 20:55:26 GMT"; modification-date="Mon, 10 Feb 2014 20:55:26 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+x9C5wUxbV+T1fPdEMvOoDgAisOK8qyoAFd1kUQesGgOyyG8BKuoAgkYuSxGBVE o4MPLgIhaIyiYlxDvCbIVYIvQBBUAqgkKnqN8goxJmJMLuQX/3/EqNzv6+marR12pmeX2VlUit/H OfU4VdVV59Sp7urpDWiaNgX47eHDh98Bugc0bSPiMiwWmva4rmmRbw8ZpGkBLVYS0PYFNQ3JtULn 1oi207TXQU5AHWpYUiS0lR0NDRVo3YEIgOq6BZyAVgA+DOjhjTtBtNFoi2DZGHAtwLIdnaCWB57h VEck+B6O7sobbk6sfyfHTOQVOkaCL3Y0rTPK5HvlXJLEG46WKN8JeRbANsOADIVgmIahOsw+voFr 3QSwj92cGvmOTqimLqXv6nVk0if1ejKp/2z0QY4puueFMQM17bSBR9O22tf/3LT5XFmzymerjHqd 2aqzuaPF5Pxz7jBlibBxrj04En0zKud8AnI4xyxDGQLaeL5LknioqtYFyAdknajeLXU6/pf1SN5C RaOQ3gNgPxjeA/8LAGalfXqY/yLNb2tBxGNS1oSs5FHUvR6vb+WIeyGW4Nk36mhnMPkAdTST8WyM 8bccTXfQlxJA2vo8AxGEi4KnX8i+MkiKy+svyyH5sOUERCUGGEuGK1/olta08WeGo2Oib1aQdum+ tuKche2it057rKKyw+nR2xQ6xItLerEX/2zUXdEYyh3y6NyO97nx/b97MHoG6vtf0EtQv0pHe3FS lhsHegC0ZGzfqEqHfHxhlPVFot+Nsp1MKPvNcpLyehjn9VWivitA2U4qqgk3BAKBFMxtc6JtMIhh jJ83/FoReKmn1CcC459S3y9HbhmAqXApSIJqeiBhB0xXg9RdykmbqZnveElZhul0KewX+T4AbEfr AISBKjigW5ExGjz7L0Pcog4fRjbK3KrPEHNclCIeBm5Exnd85G4UF+s3iiH6TaJSl3JLIFfoI7dE dNLvFxH9AUDKvQw5w0dukxD6b4HNgJQ7BLlDGKh013dIHAp8Jj51IeVCWCQ+9ZEzzU8DlnnIhZTr Aznh08++ptDPB/qZRqKfV0Iu4iM32YzoV5mdgMKE3B2Qq/SRm2sO0eeaFwPfScgthtwcH7nF5hx9 sXmrC3l9lJsPhU83novNBcZic6ELKTcXcht85OaaG4255ovGHeZLhpS7CnIf+8hdZf7dmGz+w7gS kHL9INcsmL6f55vNg32BPoCUsyB3ko+cZZ4UNIEQIOU+g575yX0mTgoe8iDlNkOuuU97vxXNg5uA l0WzRHsPQO4fPuNyv/iHsUT8Hfg4MS43Qe4lH7kbxYvGjWIjsCEhNwNyC33kZoiFRpVYAMw3uOhZ gFxnYpCn3oxB2mpABrnOdEFCTNxpzBfrjDvFGuNR8b6xTOw1tonPjVfEv43PRTD4mTAw5kYwaAaD Zea/jV7m58Zl5l5jrPm+MctcY8w01xlzzDuNmDkfuFWfY96uzzSH6bPMkfpYs5t+mXmm3stsqZeZ rfSgaekh4DNh6Z8Dr4hW+jbRUl8mztQfFd30O8VIfb4YpsfE7cCturyevugnr6s/kA9wHjsCs4Hh QGtA+gC5BiMpsd+AemW03yhS6hkE/m3Y6lagKfcexU7cp/G61f2qyjfGnqep2rUcvc69UvXsdtHF zd+rIA313F4xsbwgOmfZtoqiJ05NS7t6+eetxV4J5SVdWvVTN/7lW/e49ZGy/nT0Li+/bHgwynKS frHBirI+7MWjrD8Tyn6znKS8HsZ5fayPlPWnov57JayNjh4LQ2+wBLj7danfUGl3n9QZFKaRcq/E 9YF6x/IMWDdcKm2M6artJe9zVmH9eRCFRqNciSsZ/0+uPyFEV4k79JfFtfq7SeCaxf7KIGVQpcay thlHurojKNPTvAN4sBbS1R0v20v0NHuJdHX3NKMiYl4q7CSkq5tl3xVxpKv7ZZRZJaJAr1pIXg/7 YSzyAY475+pagGujOidyrpCc0RrIdW88MALgumc5QnfAc/7kPU2m9z7zx5UdbuPUPOPg3BUBcl/c GTyRTgflfp26VuaWraHqfr1s3HwvN07kdVNO6jH37gyyrCzDdDlmLJ+sx8vRcanH7L8Mqk4uFw/q j4sHXHAOwsATkFvg6X8quSfEfP0Jcaf+pJiX2Cc+B7kbfeSeE7P11eIGfQ0g2/st5Gb4yG0WVfoW YCsg5f4Auak+cn8QU2GjU1xIORuOdYqPXJ45RW9hTnUh5QogV+Ujd4pZpXcETjVnJPrZDXI3+Mh1 N2/QzzRnAzcm5HpBbp6PXKl5p15qzgcWJOR6Q+4BH7ne5gN6b6wvhLw+yvXCmI6GDqSa995mqeht nutCypVCbpCPXKl5oSg1LxK9zAoh5c6E3EgfuTPNUaK7eYnoBki5UyF3uY9cR3O8OAUoAKRcC8hN 9JFrYU4UeYANSLl3IeMn966YKP7gQcpthdx4n/a2iPFiM/BbcXmivTWQucRHbrW4RDwnRgEjE3JP QqbCR+4JcZF4QlwIDErIPQ6Zc33kHhfniuWiFOgl5Hou9+trIUu9oQ9ZDcgg15kuSFgrSsR6MVCs E47YJCrFS/ATvxfDxGviu2KHGAH/MhxjPlw0N0eIduZ3RVtzmCh0fVWlKDId0cUcKIrNEtEV/q0r dLbYfEjvYi7Si8y79Aj27oXmXL2tebPezrxFb27eBD97E2z+Jn0H8Jq4Rf+9uFl/SczVN2GPvk7c pa8Xi/S14iHgwZT79d7oN9fa64AyoDWQzf06TFQr9OrkWA0Cvw/juAs4vnev+3l3Nyc+BxgqrRg8 /XA+oN5XqHx9y8Cn83bNC7H+I0fOHfBB2WkD1Hq+WWX6Z3Dtx1qZ2vOl6oPK53JODadGbztBuyxA 0gIvPhjUAXoAQSACcI9HhAEZ3gOzTEZAZfw08BE3vW4dVvatdeq4AVmub2G3jvh/zZPiwxCvQoe4 dv0ba1a8VPz/dUxEMLRQ4UDtCpxxXqVN0K7B/0jbdJZ2ZecF/6H9YJpe9iZ3bc5G2NEGeIxyZBPa teOWNLtFP0vrjrKpwqDyisqnzhj6CvM//FarmV+iD8SqMzrdvWvuz5s18wSZ9/QTd04zXj5LO0mf jx7PD1D2POSb2gQxob2mXfDiWdr3P737P1yRja2tHqPAg67MX4S0s7RBlxXP3LTyi1u0A4ASOPbX QvZnE4tnepesLUT8wgsqBm5t09acB17Tus08acj60Io11c24nr+LtLZzus0kzzRWh0651/zphuKZ W5GvtjfpeldFXP8j7zvaojz5fKCVx7MOxpmOoI/AfzcBA4GuwHCAvZH9BOsG6hd1sDIeTfyPoXTD WKQM176H2bse8zcRXMStA913Ketj26Qyjb6S/TgBE1vk8cwv9HhWrPL0d5OA0UCyvzuaNfa4rdXY 2lLX1saXx21tH2hdthaIKxsyP914lhZrd9v1tCdE3XWI8+yGQx0s6kzkgRKLc8k00rpszS2P/2hr E3Nga8aIuK1Rl6StkU+2tQ82tLayaWvz0AZtjrb2AyDZ1loijbbWHEhla+ORV6FN036IJyFXgMat radrX9K2aEeEjKu0IXa3AnVVA9m0u2KnZj9Wt/1mtk9oevvtP6AzxoZIdR0GcrjWhQEZOMdhGQEd BlTBeDhvDfWV2nbVV34K+93roLokXxlw9Yu6ptqv1D10wQ1vPz9NZx/f+EffetnvpPaN7ytvuiRu v9Xon7Rf8o1tv/egjYFAD+BSoBfA+VID7Zdzncp+JyGvSBsKXzld+z685RTXW0aw0Pas02Y5HwRt WOUZb4gts32udZnZ8nEbxFC5IeP9qmuDK8vjPjQMWrcNUkcYVBtknPrDeWa46LGpOstFfhkI1ceH fi8HNnjRpU3jQ6m7Y4EewGVAsg22QxrHkHaZygaHIq+rFnHLcKwbZEch2BGQPTs69u5D/X107T7X 7f9yWSaz9cr/unJZT+3xUZ85qLzaZzVd5bs5iXu7Rnnepbal8o3dbrJeFWyZPuDx5f3K1TH5JpUZ OfI+32s/1spkMl8jR27J4LqyUya5P6o+q3wudawp72WkTXWGPyRS2ZOBHO5JwoAMjXEvs/pZC97V 2Yh+4LlfyQC0hb3Ukfcy9PP0+eo+Su4B5D5qybnn8BVPzblK1Gsf9f0c7KMWX+bto3C18l6G+4rG vpdZgfHoC3AuJwAtAY6RGriPCgOVaiJ47kUZpoAfpF2iRY54+ncx7m4mJZ4Dsh7OBeuXzyLIJ6cx TwXLNGhvBrnRgN/eTOp8JjZuODW+tRPqtgBJC7x4Yz2Tl/08VmxzxBraZnhA3DZ5j1O3bYaRwaDa JuNSH8hri/taYRDn9xMM6hSTSP2eE16ZA9vsPrlp7nFGYAwmArTN7wEtAdqCDDwjl2OYyjaHogwn hvbUEBtaAblqIJs25Gdnme5ZmtoW2c90tsj8nPlJ1xadjXFbTP3ML4C5pN6otqjqEbK0Az3OMViu DP6yPrY4OQe2WHV10z3z64sxaQ3QLvMB1RYRdW2RtprKFichrwgWPR1vh0yBX4zA4/KM7AqAdRHS 73H8yUsqeZZhWkNsme2PBjKx5eM2iIHyQqbP/LS19Icry+M2+AboXodV1D6jDrjrOdNVG2RcruXk xy85z6IuVV1av2d+V+XABvtObxp/eDvGYyRAG5wMJNug3O83Q14qGxyPvCpI34CTM55R842DCP5J u5N2GEA5lTcQb4jNrYBcNZAtm0u+X4Wu9Uf1Xoj15x4x0/vnpvefW3z855ac+c+Ya7vSf+YPwIDC fo+0XeoW9Uy1Xal31BmGk7b3MlhOOzBVr4///EEObHflNU3jP6sxHH0BjhXPzDoCtC81cP3DeyAp bZc2z7vJmrdLpuP8LKKN0obg/661bJhzwfql3yRlnOnkac+MEw2x63x0Ng/IzK79n1Ul27X67Enl i53U5+Xy/vCbWibTPYvf+OSynuR5P5r13P+6GkcPVf1U+W7QVe5hGNS+qWVUPpMylmPoDuorAXTv WySZ/kYHIvg+QbDO39zh2wLRj55fWUFaNeyRioJFy6OBt++pmD35iaieht7o5Z9xx/6ohnKS3n75 v9x45Jb/79Z3KuiHqJ90Xx2U5T5GOmklvh2gUuv9k6Osz+nUMcr6M6HsN8tJyuthnNfH+kjZTiqq pfgsgZBfLLhtW0UbJ+g+F+RaShQBnG+usZ0AC5gAJKdx7c8HZHgPzDKgswfYQMrf6V2OMmUA2yBl kFTTc/NNg7ClaafAcYxG20VuD+L/0dcz0L+ErVP0llaBi1LGgXzIfYaOp5PLtw4F8q1PA+2sgwEp 1x1yu3zkuls7A2daOwJnAVKuAnJbfeSi1pbAYKASkHLTILfRR26atTEw3drgQsotsfEbfB+5++0N gQfsjS6k3DrIbfGRW29vCbwAbLC3Jvq5E3I7fOR22TsCu+2dwK6E3H7IHfSRO2B/GjhgHwI+S8gd hFyBz7wftAv0g/YpLuT1UW4WlCLdvB+0bxAH7dkupNwByC31kTtgPyQO2D8X++2HE7/N2Q25533k dtvrxC57vdgJyPY2QO51H7kX7DfEemAdIOUegBx/V5fu+h6w/yDuB5YAUm469MxPbrr1BzHNg5Sr hNwbPu0Ntt4QUaDCej3R3lmQW+8jd6a1XnS31gHPJ+TaQe5hH7l86+ci33oIWJqQawm52T5yLa3Z ImzdAMw64jdSEchTb8Zg7VgNyBBfZQ4f5nO7iDVTdLHuF2dY94re1ipxrrVSDLNeEt+xXhQzrK1i urUFY75F3GdvFWvsF8Wz9ktiu71SvGGvEu/b94o/2feLffZM8aE9CzhF32efqv/J/iLwvq3pb9h/ CWy3Pww8a/9PYI39TuA++/XAEmC69XpgBvAd653AMOt/AudaHwZ6W38JnGFpehfri0DEOlWPYP2T v/nivh+XkvimQQw8bnW0F7201qDSR8i9OJJikjfBK76hHHleiCV47uMLAdbD8SnyeJh5rfRBiFvY t38Oh5W8d1f3IirfGPuYYqdmH6+2pfJf13YxnUnPLMyBi/5slKtj8s0qc20G1/51LeM/71tmLPcd n2yVyUQPt8x437c/yfWodq3yudR5A2sO10eGToCl0AIvPhjUAXoAWCa1CMA1lAgDMsg9e3L8NCRE 3MS6bVxZx+tcA7Asu30Mu3XE/2sOosaHIV6FDrFPDX1Hvmyd+l5J9wGoqhxIelbPlCOD93uyt2RO fX9PNgeC/I3L1Tl43jfle6eZfIeE/k6+V0I++b2STH5PxvFuC1CH8oFWHs90xj3dcn9PtgLxeQB1 jHwLQAfUQP0KA5VqIni5v5ni5g3Q/N4rwRbJ1QXWT56UYL/UNOapYJ7cY+C5Y6wI8TyAcoUez76o PPcPk4DRQPL+4Wh81nHbrPn92dvraZvWAIznBmhIOYaaSLLN+LcRma4+i2ecesU5ZIjcH3+vZOP9 9TtHm5ID21wxNW6b1CVpm+STbTOT35/xejO1zREo+9+ABTwJJNsmbUKOYSrbHIoymCDXnhpiQysg Ww1k04aKnZo9dd22mNkeqult8dryzhgbItV1GMjhWhUGZGgMP/n2f9/cTEu8f/kr2OFeh+0ln2lT /6gHqi0yHgSkLa7D+yTkPzm7fu+VTM2BLR6oittiNfonbZF8Y9viLLQxDzgRuBc4CdABNXAMcQ+c 0k+ORV7t90pqfKD0dxx38nKeqDuN5/OO2xmG1w2ZvjsS29YHy7FTHvd5Q0HrtjPqAYNqZ4yrdja+ 9K/8vKy2GnVy/8J8Ur93KaflwM6qr20anzceY3AfQDt7CEi2M6ZzDGkjlYAaOHYMI5AYf2OrZh95 3J44UnzvhM9wjiG/Vd0ce8glnj3tS2lPnG/OvWpPUhc4twxDD3WxWC5/6fR6vc8xPQf2dGBm09jT YozHzwGO1dNAsj1xL0p7wtFASnuahDy++3jk+1g1928cd4I+keCcqLyB+OlAff3ZCshUA5ntPzPx Z9l7jtXU+08+S+uMsSHq2n8yn+POMQ8DMjTG/jP2gvqcJvV7WdQz6pxqx1IHpR0vsd4ULLf4z/W7 F6zKgR1X3dg0+89qjAf3n22AxwBcqmtfIIlAO8ZeMaUdT0Zert7L4lwWAtQ9+mSVH4S0vuhsDyAT u87kmXHyc9y67eGr+Ty42PG7X/Zf0zIZn+yVyWQd/rqW8Z+LTPQ5W2UymdPGOidRz09UvjHOSy0n pMu9gu69b7bwJCw0CPx7OIdBuR9hkJRrxCTGvfJyz4KnkQ7L1YRIee31JJ5TBEJZ7nu0CP/b2F9z n8GQZ9i4wY0H5iTaQCLebTNFdzARgPKyPxvnLqjQ+v3R/Z587N1/VnAT1cYxXd9NPx4COgEWMAHg 2ooiibSO4PMBGeTZT2ckELiG812SxLP9y4EygPWRMkia6ftap0OGfWJ9rRX+UvCVQDugK8BO9ARY rhlAv8XrezzwX/oCsRN/c+Fj/deBZ3XG7xCv6qvEPv0W8ZnLy3rZT9ke2JjkcT8dU663HHleiCV4 tlsIsK/0TUUezzrpm6rATAKSfZOqwyrfzYnXBVGtGDzbzwfUMiqfSRnLsY5lfa6QNsMRtJxmdepz rPetri7z7wVE9oaicX1ultBnC2NUBEid6QSeadnQY85xGcAgqarHXA/UIPWHcl2AfID6wCDLyjJM l3rI8lK/TwZ/NkD9Jpin6veCwHJxp+gvFoqLxU8CawXjN4ue+J5+PzFPjHd5WS/bkO2BzYp+sz/H jn43P5b1O7FeD33jbui3nVK/Y8sq3b+Hob16lqffdkK/eZ9VBFC/OZ+dAAvIhn6zvjKAQVJVv+9+ Y6ibJ/+TukQ5qd/UBwZZVpZhutRD8qp+lyNO3f4uwDxVv+cH9uFv9vQxFonBxk8CBw3GfyS+ZawS pcZCMdblZb3sh2wPbFb0m3UeO/qd95XQbwwZ9LtFnfrNvyfDfUikzYro+Pt2ePuRFgn9pl5L/aYu dAKypd+sT+q1pKp+I7tWkLpEOanf1Ac1yDJMl3rI8lK/Z4Dn9fwn0ANgnqrf3zL36l2tR/Qzrd/o 55j7dcY7Wvfow6yHkf6Sy8t62YZsD2xW9Jv9OXb0+4SvkH6fWKd+87cbzoJ9FfgbR4NJ4/uTExP6 zWcpnYBjQaelLqXS3fXoZzHwLtADSNbd/fbL+qUtiLf0/Tbxsj68xVP6bS1eA/2zy39zdDf8FdFd 7q1b1qm7+A1TNNZbj1bh90PVH0z09h4tE7obhg5wLWuKvYfcL6N5N6i6K9dm6ieDLCvLMF3qIXl1 be6B+DxgDJCs32VmRzHJGhMcaY0PFpunC8anWdHgdCsWvMC6Ikhe1tsYazPrLAQ43ryn5Do9FJ28 AGjK+8hix/9+tBvKsN8MmZSvbxm4v/7x2vl/rP81BeeU4xc6af/2RFOXUe/XVV699sa+LsOpmZdO GDkLkLTAiw8GdYAeQBCIAAEPYVAZ3gOzTEZAZfw08BE3ve45Up6l1DmHfG5D3Qm7dcT/432PGh+G eBU6xX419D3g2E71W9nV5aiKSHq/iSlHBu894D/KnPq+B3wNBPke8AwcujT235Xofk/8fInrhny/ iXzy+03Zfg+4CtdoA3J97g4ezdYK1K8QUFkrNb7ecc0bjfRB+E7HdG2mFvG+j805FwD1RPJyrcf+ KlaEdOoP8wo9nnWpPNfSe1DJPCB5Lc2WDao2rvK5tPfGaEu9FpVX21LTVb6x/YLalso3drt168y4 DPxR05VRx0fl1Xls7Otqen80bkB6fzRuQK780dJdmfijgLteYvmq9b4D41xLueYxVM2eYHBdHT+q fu/bXpMDfzTr/rg/4tor/RH5ZH+U7XffqzAe9EfnAvlAX+Do/NHZrrz0Qbn1R/VfN1QbV/lc2ntj tKVei8qrbanpKt/YfkFtS+Ubu9261u1rlt7t64+asow6PiqvzmNjX1dT+yOOfzp/xPxc+aPVu7Pn j7Z5/uiiy+rnj36YA39kVTetP6rw/NHFR+2PzsmqP5oMnzw2w/ujhqwbqo2rfC7tvTHaUq9F5dW2 1HSVbwy/YDmtdAe6VUL98t5Lqt93s1qn/G5W7+h33e9I/U1cGH10yePRR57sF932/Mq09Hde/qZu n0SrUV7Sjy8+5MbDN3wR/Qj1nQhahvpTUZY7D/mkxo4f16Ldvrg7yvqGdrnPrT8Tyn6znKS8Hsb5 nSzWR8p2UlH/72bZ0TZO68Tz9FaYjyKAzyq4D+0EWMAEQD6/kGnZON9nG2UAg6SNdf7ZB23wWjoA YQIRfjNxNPgiQAY+l2HAMoMyecGWlu2ilHGgPeT2wOGlk2tv7TbaW7uMDtZOQ8qVQO45H7kS61mj l/WMUUp47V0KuaU+cmOtB41xwGWAlFsAubt95BZYdxsLrbtcSLntuCG5y0fuLfsu4237bhdSLgAF edBHTs970BCAkbc00c+ukHvGR6447xmjW96zwHMJuYGQ2+kjd0HeLuOCvN3AnoTcEMjZPvM+JM8O DsnLcyGvj3I7Q+nnfUjertCQvN0upNwFkGtuppe7IM82L8jLMwfmtTClXDfIne0j1y3vHLM4r8Ts Ckg5A3KVPnIib4ipAwFAyr2NeR/lI/e2Pcp8C9gOSLmF0DM/uYXWKHOBByl3GeSG+LQ3zhpijgUu tSoT7ZVCrsRHrpdVYpZY5wBnJ+Q6QK6Fj1x7K89sb9lA84RcS8jtDqWfv5bW7lDY2gXsDPG9IYgk 1pkIItSbMUhbDcgQX2Xkd7N2hLpapllkGWa51dXsb3UxJ1n9zSusfuYi60JzoTUIYz7IfNO+0PzS 7mf+2+5vRvK6mB3zupqleYbZK880++XtCJ2fh/aht/3yTgj2yvuTUZr3gdExb6MRyXvJ+Lf9a+NL e7nxpv2IsR1YaD1iLAKusJYbk6xfG/2tl4xya6NRZH1gdLX+ZESsE4IRrH/yevqi47wuHpDkAzHg ImAzMBNoDUD13Oc98tk3oll7J6TQq5/jNgj88e9mpX//tjH2bcVOzTlr8n3voon2QC12IO39/Ne7 zJcZXPvXtUwG8+4EB/rqT7bKZKKHTp5/f5LqUe+LVN73upLqORrbMWCDXGcZ5F5c0gKkWcBgwAF6 AHwGHwECHsKgMrwHZpmMgMr4aeAjbnrt83Jpv52RR6S6DmzL3D6GWcQLqc7LeQ/Q0PNyrdb5hDMA VZWzudrfA2HKkcE7L/+zzKnvefkcCPK8/NocPA/65cr486BsfDeL490WoA7lA608nvrBuKdb7nez ViO+AJgFPA38CKC8GqhfrKNSTQQv9zdV4C/GtIyARqX7dpZAOYL1sy+khExT02WalJGUZeTeQz13 Z3ohwGtjv1See4lJwGjA79xd6n+x4+8Hj9tpzTe0ylw7LRiA9WID7qLLMdREkp0GXD1iuvq7acap Y9QJhthnU/VWoCvHfG5yLplG6vc9ketyYKcHVsftlLokzxHJN+QcUYdcpnY6AmWfAWYBzwHJdlqM NDmGqex0KMoMBGhLDbGhFZCrBrJpQ/52ltl+qult8cuUZyjxNeXLep2hUDca6jNjtc5Q0n9Di3qj 2qKqR8jSNpbGv6HVuax+ZyjX58AWS9bFbbEa/ZS2SL6xbZE2SJ95C3A/cDvA+VIDbRGPIlL6zLHI O9pvaLHNQiA7Pu+4nWEo3ZDpN7TK9rhnlfBz9HlDQfc6rKD23jTg6gHTVTtjXK7X5If2iX9Dqwy2 Wx+fNzMHdvbBhqbxeeMxLg8AtLNqINnOTkQax5D+LJXPo9/M9Btax+2prnvBHPqtp/jtnex8Q2vW P+Pf0Prgwfp9Q2tWDuyp5OWmsafFsIVHANoT95DJ9sS9KO0JxwQp7WkS8q7QGucbWn72V7/9Zyb+ LHvPtJp8/4nnap0xN0Sdz2yQbyCHe4UwIENzMGEZAR0GVAXi+5mG7j+1Wt86P7pvaOWf38ugPg59 rH7f0LohB3b89Oam2X9WYzy4/7wDWA7MB2g7aqAd4/lISjuejLxcfUPLz64z/YaWex+VyfPjTJ7F fkWfDfvfL2ewpmUyPlkrk8k6/HUtk8FcZKLP2SqTyZw2kl2oZykq3xhnmJZz0rH8u+jEN4fi32Rp I7pjLY4A6je0+Ltordl57u+i//r5fO930W1cX00/fhJQBNCfw10nzokm1JGWjfe42EYZwCCp+h6X /PZKvETN80XKdQHyAemjZNnTkcb+M721wl8KvhKYAQwC5gFTAZZrBtC3cQzKzFnGRGtxaKS1JFRs xgzGp1pzQtOt50IDrftD5GW97IdsD2xW3llgnewf90tN/52ttl8hnT+5Tp3ndyzw7TjAHkxKxW7j nJzQed6fdAIsoKl1WupSKt1djz5eBbwLTAeSdXe//Wzo0hbE5tB+m3g2NLzFf4Vua/EC6Dsu/83R 3fxjWXcPy/eXeQplOe1S6u7enlNd3SWN6267hO5y/SsC5HqXTT2mbpUBDJKqa/PheFbif1V35doM U3ODLCvLMF3qIduRazP1ewzwLnA5cKR+rwpe2oJ4KbjfJlYFh7f4RfC2FmtBt7u8rJdtyPbAZmVt Zn+4No8FMxRIPrNS9yAq3xj7kWKn5ixZbUvlG6Ndy2lf5zv07ncMfxZxv/e27VcFUUKmPcJvHCKv LtrJS39h0F1ueUn39f2pG+d3tljXF6CsIxVlOdZFuvfLvrVoycdOlPWNb3dBlPVnQtkWy0nKPjDO a2J9pGwnFfV/h35B9CSnfSwMfeK+g8/ni0Dl3qszeAKqe75Lknjq4hF2Fj/WTui9amfk+wAW0AEI A6sE3kkHRoMvAWRgXxhCSFglNuPfKrEnCbRT9leGuET8/XeWDZpxpKu7I8r0NDcDe2ohXd3xsouM nuYiI13dPc3HjI7m80YwCenqZtk9Io50dW9GmVXiMWBRLXCiLKCvR/uB5gMcd+JagHvQVGuUMufl KOaFWIKX68945IwAuP5YTgfdAc/5kz4l09/EzB9XdriN0z7hT6gXRUB9dJDrdBlA/SJlkFT1F2Xj +ESpJsi1mXJSj3l9DLKsLMN0OWbkOZYWwP6GgeWKHhchLoOqk8uhwY+L3S5KUSAMPAm5bcBo8Knk nhSviSfFq2KleEVIuTWQ8fvb1GvEWvxbI54HpNwrkFvp096raI0tbgOk3G7IPO4jxyvbI3iVyxNy QTM+NumuL2QuF6b5uAvZXj7kODbp5NqZT4r2QAdzZaK9rpDj2KSTKzbXiGJzrehm1vxt6l6Q49ik kys1XxWl5mvAtkR7vSHHsUkn1xtri4S8PsotMvzkfmL0NonFid+AlELuFz5ypeYyo9T8pdHLfDQh 1w1yT/nIFZtPG8XmM0ZXQPazA+Re8JFrb24w2gH5gJQzIfeyj5xpvmyEgCAg5egL/OT2iJeN3R6k HG1og097r4kNxqvAK+KFRHu0Ib/f8KwVzxhrxNPAUwk52tCjPu09KX5pPCmWAb9IyNGGFvvIPS4W G8vFT4BFhlzP5TqzFvLUG/qQ1YAMcp3pgoS14sfGC+JhY71YamwWy41N4lfGdvEb43Wx0tiL69iD 6wiaTxkG5ruNudJoZf7GiJi/gq9abhSZS40u5sPQgx9DDxYBe2Are0UX83VRZG4XHc1NIgJ/2cpc L9qYLwgDdhQE9mCl2Qu8Ll4Q28V6scn12ZvAbUfK617unsTfZpf+qT/6mw/09nAd6MVAa0D6ALkG I6nee+gipZ5Cj+dYDQK/D2O5C/gm7qGLnabZu6vtYjo5/V6I9d/yzzsH3LzqR2l/i/B1LtP/vYW+ 136slUmeL/XeT+VzOe+GE187qFidAEuhBV58MKgD9ACCQATgPpAIAzK8B2aZjIDK+GngI2563Trc GXlEKh3HEu6ub2EW8UJz0LCMgA4DqtAh9qmhZ9YjnuDfb3M2oh8b4DHKURWR9C4XU44M3u8M/lfm 1Pd3BudBkL8zmN0+B9/lez9+Zs31XL4zST75nclsf5fvJlzjtwEuZCOBCwDeH6iB+kUdrFQTwUuf PRb8cO172jXa9Xi2OhFcxK0D3Xcp66MOkMq008HnASdgYos8nmUKPZ51qzz93SRgNJDs71LpaLFT 4yNSlTluazW/FVjt2tp42BdtjX8rsS5bC7i6gLy0701Wte5iUWfGP1RSr789emMObK3go+y950Wd bQtQl/OBVh7PdMaZjuD+pmcemFEAbW0KkGxrLZFGW+M6WgmoQdraeCRWaNO0H+JJyBWgcWs727Uv aVu0M0LGVdoQu1uBuqqBbNpdsZPeNjPdJzS1/bKfnTE2RF1rDPMN5FAPwoAMnOOwjIAOA47WVxZs 3BPSEr7yAOx3r8Mmkt97ZtvUNfW9Z6l7AQogFL3Ry2C52KMiRN1jGqnfb31uat/4vvKev2fv/S5e b6b2uxhlvw0MAsYC3IPRztRA+7WBVPY7CXlF2lD4yuna9+Etp7jeshx/12danTbL/hG0YUnJN8SO 2fZoIBM7Pm5/GCgvZPq7gxGu/fF3PfK3dnXbH/WDQbU/xqk7nGOGrfdNcN+vrH6ifu9X/igH9jf2 QNP4T+ruOID2dzmQbH/5SOMY0iZT2d9Q5HXVIm4ZjnVD7GgjFvSngWzZ0bF4D+rnn5P7XJfvy2WZ TNcrv+vKZT3J46M+b1B5tc9qusp3cxJ7TS2T8tkq0xjtWk5Bnefj/FskZ/3mdvfdu/af3Brt9+aT 0coFc6LDFv0mI9p3zL/ccpIObfv/3HhHvN/E+khZfyb05xfd5ZaTdFXwp1HWF5t2T5T1Z0LZb5aT lNfDOK+T9ZGy/lTU/3y8Hc7HC2JhrHNYrmqdj3ON7ARYwASA+1Ouh509wJ59z8xZB4O3PUyspUxv Dcg6+4BnOx2AMDAdkauwUx0NvgSQgftLBmShzPDQHGtA6N4kjEFekRQAjUvEz8xZdqsdR7q6d6PM fns4cFUtpKs7XjZo7reDZrq699sdzN12d3NrEtLVzbL3WnGkq3sOyky3OgDBWpBnLH0xHhYgz8zn gp8E4GYe94u150T6PSTHlDkvR9wLsQTP+aTPHQ+MAOj3LOcU3QHP+dPr+R3J+Jl5gasLBuRPAYoA 6gvbknrZEXw+IMN7YJYBSn9T6ij3B2UA6yNlkDSTM3XK8SyK7dMuGJLP1Jku9Zzlk/X8SqtGz4tY gRdUnb3Suio02ZrsohT5YeBqyI2BEYwGn0ruamt06GrrktAUa1RIyl0HuQofueusi0LXWxeGZgJS 7jbI9feRu93qF7oDmAtIuZ9Bro+P3M+sPrDh81xIua22pp3nI/eKfV7oVbuPCyn3HuT6+cjtsPuF dgK77P6Jfu6D3IU+ch/ZF4Y+si8K/c2uSMj9C3KjfOQ+sS8JfWKPBsYk5A5CbrKP3EF7cugg1h+i 1Jt3yvF9g9Fp5v2gHTIP2qYLKfcJ5Nr6yH1in2x+Yueb/7LbJb6v9zfIneEj95HdxfzILjL3AbK9 XZDr4SO30+5p7gDeA6Tcq5Dz+37gq3aJ+QqwFZBy90LP/OTuxXcHf+ZBys2FXE+fft5h9TRvB26z eiTamwm5Ih+5660i8zp8K/A664yE3BTItfORu9rKN6+2TgbaJuQmQ47vG4xOM++T8Y3CK60QEDTl et/B0xv2l3pDH7MakEGuM12QMBPfN5xttTZvsMLmrdYpZgx+ZKF1mnmnVWgusU6H/+mMMe9sbrFP N9+xC/GtydPMP7q+7BTzr3bY/IvdGjpgmB/C/30Ind1nXx36iz029Ff78tBue1joj/aI0Ft2Zegd e0hoix2FH47C5qOhJcCd1pDQQqsyFLNGhG61hoVusC4PzbbGYg26Grgq8d1G6b/6o7/5wB3ABOBF 4DpArrVcd1X/JXkMQUa+rBDy9DUcnyKP5/qtpg9CvFrE/y5Q8n2euu9W+W5OvF6IfuX34MW4FvpZ zoN6jSrf2NeL6aQqeIH8iQMXTdyW9oz5611mRwbXnq0ytcdZnXeVV/WksefLcGrsqxO0wgIkLfDi g0EdoAcQBCIA1wsiDMgg95LJ8dOQEHET69Y9Ze9Zp25yP8u1JezWEf+Pz9HV+DDEq9AhrjkNPhd/ VX3W36Bz8U/QvBvqey4+F1I8F785B88aFwY6mzwD599nk+fi5BtyLs7xbgtwfriutfJ46gbjTEdw z+puAvMT4PvAw8DVAOXVQP2iDlaqieCl3x0LPhvn4my3EGD/WLfKD0LaJGA0kOynjsYeDScxHgkb 64Q2eL0FHv2m2NpS19aycy6utYmfizuFv6vXudotObC1EuwBaVfUJWlr5JNtLZO/xUWdzdTW5qFs NUBbexZItrWWSKOtcR1NZWvjkXfkuXgvd93HcuHaLvtEyLhKT0c67Ut9H4VlC730uuxuBfKqgWza XbFTs++q234z8+9Nb787Up6Lx/doO+p1Ls65aKivLHhN9ZXWgKM5F5/snYsP/XX9zsVjObDfFbh/ o61SJ6X9km9s+2Ub9JVTgeXANQDnSw20X9hWSvudjLwjz8UH4lycp3WROu02ABmCdiyptGmZ1xC7 noVN3BQgM7vOxB6Pvb20/zpTu891r0W5LJPJOGerTO3rUu93VF4dQzVd5Rv7HlltS+Ubo13L6Zjy XG7SFd9xz6m+VTk4+n/tXX9sVdUdb+8PdvQIPkBKbQu2pbDXsgQYFVEkvsGCtmXBEbO1KJMQRNQa mFmGP0ZXESYaWcz+boGFASZjg6DB8iPQSmaEll9FqBQElowfAtYJWNiymH0+991ze97jvXdvy6MY w0k+fL/n3O/n3HPvOd/vufd+80p2aGP5qf89Wr4pZ1P5PwPI4y2XHHslf9t2xakzD8f+hkCy/2SS ds/gOOX4y9Ux8kXx63L2t/2Xvyln/0Ekx007JQfjelhnHo79UfI8yaR/Xu515OWG1oYQtxBmYr5D MW4VAAKYDfCZhG1FLuCHSXMe/M6X7dpDsF8K71sZ+xkIqD4nQOd5coEQwLxcJgJ1JfRSQBU++7D0 QcN8cdZaIg5Z9XGowrGwIkBGGdG8HG2bZBSp+m6HzVfyLJCJ36V3IVXfUbsG2DfYqfr+Srba7fKM 3RSHVH3Ttl5EkarvJbCZL1qBhhio77QP434IQM/L/Qz1ncDTgD4nar9Cc6BvmVNgOAt4AuB+JSL3 GRHonL+e5eWGOmvBAv8+IAyo9aLWZTryclyL4wEWJYPk5chT61w9Y8Tn5diu7in1+HXOvJxa57w+ VfQ1+6zItPFd3sE4GIQAft/vwI2phJ6MVy2+tKrFRfy9mwveb+b4ff64D28h/r+yl0W79Qqgzvcm eAd9eMvEAest4G1A8erAa/Hh1YkW+HCzA8VrkhkZzT68j2SztUu2OFC8w+Ad8OEdkQesNuAzedAb 5xnw2n14Z2W7dU4eA457vEvgXfDhXZYXrcvyS6DD4zG/xhfJyhTzBxv7KmIPoa6PvAZf3hZwtjpQ POYPW3x4l+Ve+7LcZ1+S+73zMV95wod3Tp60z8pT9hlAne8z8L7w4bXJ8/YR4DCgeLvA6/Dh7ZId 9kdAE6B49Vhnfrx60WHXuVC8t8E773O+t8R5exnwpvjCO98r4J3y4b0sTtkLxUnghMd7Ebz9Prxq sc+uFnuBFo/HvNxWH948sdV+VmwBGrz/rysX6ysE0O+5brjHNACqqDgTzct9aL8mdtuvio/tJeKw vVgcst8Vx+3l4pi9EtdRj+tokifsRsx3qzxm75fH7c/lIfuYPGyflh/b/5K77XPyQ6yFBiATuom2 r63T8op1TJ62Psd+ul+ewP87dtJqhB81AfWINSuB5eKk9a44YS129vTT1qviivWa+NpaKEzcv0zv etT+9QguIBtYClQATcAsQMVaxubhAPcLlFql30hejn0WAuyT920K5Crzdl6O86A/7+v6yIg3Bxkl 0Itgm8q+uzaYWi4Ft+B3r2P6Tn6w359T5qa+3zYbAlx7umxi77M+77quz+nNni8r0rXeCrAqBKBk nltnvIgAowGExIx8gL5NhABVjkJZrSqQqj4Mer7TnnjtcY0Tya4VjwtODAnRxC38nhxSFcjpwAIM iGPq6bfGjL36t8Ye5eX+o4bU07zc673wrbFoSPrycrzfWQBjPOPUAFdnO+vufuLl5Zaj7edAPfAL wAD0wvXFNThVb4Su9t2noKcjL8fxFQIcH/vWde5Tc4BKwO87Yndi421f6/q96hOOr6UnL7cxK5qX a1zRvd+rLu4FX2sZlr68XHd8bRnW7gqAvvYBEO9r/dFGX2McTeZrs3Ds+rxcqRNj8Rjn+C79l1B1 XapnSOQOasOwoa/5+d162KwC0ul3JZGu56jEe0yw/f3W+++GpHm5aBza0K28HOeip3tl7T59r7Qm 3Uhe7lM3Lxde37283Bu94L8//WH68nK831kA/SAbGODqbGed7SjOXlkHhXtlJbAOmAnQz/RC/+0L TNUboau9ch70RHm5MU5e7pmEfsuxEPRjJZVPs94Tnw6ak1NruCTi56/fvefo7o45cRyKva6baxMs 5vlfV5B+Yq9Lf9fRdf1ceruu3+z3Y/1cun4zzisi+QlzcvmD1pdv3LCjjLLzv5vLOv7yt/KmbRvL 8v60IZBs/fu/yxthr2RG3SWnvm/kFae/vZDsP5mk3SYcpwz9vjNG7hn7bRn7q33QKGf/QSTHTTsl eT2s8/rYHyXPk0z65+QeRU4uvzaE+MR3Rca/MCTjKWNmASCA2QDbGMeKXMDHJkJ1S5dOXnyuAt06 dioG0mYgoPqcAJ3nUd8Qp6NSBqNKtJUCqqj43AcN08UYY64YYtTEoQrHwooAqTiMxbRdK6NI1fcO 2LTKMUBZDFL1HbXthH2nkarvVtnP3CELzLVxSNU3bWtEFKn6ngub6aIf0Gno4EQJ4GFXqpzcUtQ5 xzuAsYA+J2qu0FyrzflPUHeL32/lCowILDl/PcvJ5TvfKSzwOcYwoNalNp6ka/Bp2I8HuNYoWZQM knPT13FmlN7t38KVi651HHb7oNDXZLkoMyrEYw7G4VgImAbeA+76T8abJsYZ08T9xuOi1FC8KvBG +PCqxHBjhigyngQU7znwcn14z4sc4wWgGlC8ReBl+fAWiSz46CAHirdW4v9S8OGtk4OM92SWA8Xb Al6OD2+rzDG2AdtlrjdO/garyIfXLIuMZjncaJEjPN4R8Ep9eG3yfqNNjgMe8Hjt4D3mw2tHbFFQ 10depy/vKnjENe98beDdgQBXibUTBlTR11mbvNNsk9I8Iu8y1flawMvx4TXLXLNZ5pl7AMXbDt5w H942OcLcCmwBFO898Ip9eOtksUmsBRSvBuvMj1cjihEji81FgOIxdz3C53wviBHm88BzYrjHexK8 PB/eDJFnVolcIMfjPQ7eXT68aUKa08SdwB0erwK8az7zXiGuGeXiKtBpqHiei4kOATPA57rhHtIA qKLmn/vxDPGN8SvRx5wpTHOu6G/OEXebL4lsc74YbNbiGmrEvbjn95prZI65WQ4235fZZpO829wp +5u7pWl+IvtgHXxj7MH+tgdrt1lWGJ/Ih4zdcqKxU44ymrBfvi/DxmZZbKyBH60FahBraoH5oth4 SYSNOc6ePcqYKSZiLA8hDlUAZd71qP1J5dzewLjzgZ0A95GBgHpm0PcnpQfNuYXdfnDLYr5lTkH9 dp4t+k6tP8Pr+shIdA5wqzJKoHMvzgZ0G13vrk3Cd7c/9vXPNX1vbYoDXHu6bGLvsz6Puq7P6c2e LwtrjD7PwudAock8t14BGQFGAzaQD/CZjQgBqhyFslpVIFV9GPR8pz1Bng3rSnveZGhyi5sDxnEL LRxjyD1Cwe/DISpumQ65AANizOnpt8NP92Xh8iONuOcIiT3Ks33rDieju3m2JSDy929LeuHb4Tvj 05dn4/3OAjg/2cAAV+faYN1dWzF5Nq6HeiAMkK8Xri9MQtJvh0/hWDrybDxvIcDxcR/Xde5Tc4BK IND3/oCx8bavdeXZ8vbT19KTZxudHc2z5a/sXp5taS/4Wukj6cuzcc0G9bVlsF0B0Nc+AMIA+ar0 h0JfYxydqhpdqZ5rZ6F+fZ5trBP3TRxjfwqqrkv13NgPAZXnp6/RvtDVE/ndehxbBaTT70oiXc9R iffTYPv7rfffYp+9srjX9sqG5gkiw9srrUk3kme752D078JmrPlrt/6u8x96wX/XT0pfno1rP6j/ 1sF2OVACMM82CiBfL/TfvkAy/52HY9fn2SZlpDvPxnEVAvTvRD59EQangGA+HcQXv3vP0f4xJnbM ieNQb9oEuc/psom9Lv1dR9f1e6i367r+fqzrQyN91LNmRkHE9nQRKbSy3bVpuH9TDntUqDRS6NkM 1ez1McTPEbpxSkHkBx430Z5APwhFTZ1/dd+YgpZrwEWA/hDkGm5kfEH6/3Ek+vcXQhhTV6majKeH yTdy7iD3ZihOyPlR5SiU1UD8PeQ7aAhgYdyLP36r+4mf499hjAuAoHOcrvVYgHMKYDbAe8T3sKkA 32f+geB8BPgRGhu1+jzUL6Be7PzSGopTYt/VVWsyGX/9eTAMAbx+IxIdC6rO77XvoYISAqj/Hw4x sdaANAEA --_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=23430; creation-date="Mon, 10 Feb 2014 20:55:26 GMT"; modification-date="Mon, 10 Feb 2014 20:55:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAt8AAAHlCAYAAAAtA5CSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFsGSURBVHja 7d0NzB3Xfd/5B7jTJ7f35skSrosKXid1N86WQXc3DDZBmbRrqECcZVa7Cd00K6JubMVwbdZRAArZ tbiovI6tXTG2V6bsQmZkK5BSKaAcw2ITqaaqrCxIDkyhss0mbChLskXZK4mQbYWKZYV6MTL7/O99 ZuacM+fMnJk7c+68fD/AQOLzMjN3npl7f3Pmf87ZiAEAAAAEscEhAAAAAMIgfAMAAACBEL4BAACA QAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAAAARC+AYAAAACIXwDAAAAgRC+AQAAgEAI 3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE8A0AAAAEQvgGAAAAAiF8AwAAAIEQvgEAAIBACN8A AABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAA QCCEbwAAACAQwjcAABVtTaN4YzKN5/Ot5tY5n8XRxka8IUs0C/M60m1O4ulsK+677PVE8Wze/9eD YSJ8AwBQwdZ8Hk8ny5AcTbesX88tJUF9FlX/nWZeS7jwnTs+yg1GU6G5rfC9yt8WMBG+AQCowCd8 J19XW7PVn9XWN5vGkxG01toCbP44dT98V/nbAjaEbwAAKqgXvt0ty4sSloKf0cpRHK2t6c9sf30a qT+T7dNkc57f5mSyE/yX27ZtK/k9n/3wO26TOIom2u+bodm6LUvIzW5cNozXo4fv5va92t8WsCF8 AwBQQZ2yEzX4Fq3PDOG2bc03JwVlG/myjixoZ2EzKXOZbE6VAJmtI9nfxc9tr8d3P/yOW35bevhW jof5GrRjo9fI60E8C9/N7nu1vy1gQ/gGAKCCWjXfHq2jubpvCcuW4JyGTPVrBSUQZgut/m/l/zcj Z4vwlud++B23nf1IA7UEZSV8T+37kd0wzN37ZCk7aXbf6/1tARXhGwCACqqUnYi0ldU36KWhdDto TiaOwOcKnfYgqAbXdP2LFm1L+La0Bqv7VLfDoRm+1f3aiKL2w3cj+77a3xYQhG8AACqoGr71Fl6/ gJYGzYlfuCsL32pQTWrCZR+t4duz5bv+cVNKR8yabY/wndZcr9Dy3djfvMbfFiB8AwBQgbsEYbId lvWAppaSuGqDk9ZTrc66oA57sQ/boU/7d1n4zu2z2bFR35ZW5621kBfvh99x0/cxbT3OlaBkrfDZ z6i13L41303ue7W/LWBD+AYAoAKf8F02Soe2vlzrb1nrsCVIeoy8oYXcpCOjWQ9u2VZa5uGxH37H Td9H/Xju3BRYt5VvXc6VlGy/rmUoNkY7aWzfq/1tARvCNwAAABAI4RtoSNKykh9pYNliYmthWbRE lQx1xZTTTb6e9uoys5Yxaj8BAG6Eb6CCosfN5qQRCb1+0/IYtKATEFNOd3vWO+ffipEPAAAOhG+g AleP98X3LFNEmxNfqK3fZier3LaYcro34Vu9WZlMqAMFALgRvoEKCsO3bfphs5NP2snJvZ50fUw5 3fkpp3PHbfvvW3XmPADAuBC+gQrKQnM2YYQ+PFY0dYVId0ssU053f8rp/P6rozQw6x0AII/wDVTg rvneCdVGoF2GWQlhetBTW0rLMOV0d6ectv3OluOpAgAAgvANVFDW8m0NsDuhTK3xzlrE/VtGmXK6 e1NOC32CkPCdYwEA/UL4BirwqdVOp0COIvsEFZPtQFlzSDqmnO7alNP2GnQm4AAAuBC+gQqqdZR0 jdzh1yrKlNM9mHK6IMCb9f8AAAjCN1CBV/h2hD2h1m+XBTymnO7+lNNmq7t9H5h0BwCQIXwDAFCR z414+/tQ9mTLZ1Slfs1m2/b+NrH+oc0QjOYRvgEAqKjOyDiN7wPhu5PrJ3yjDOEbAICKymaoDYHw 3c39JXyjDOEbAIAKime6rTgbrLEOW3BzhejSvhmOmV3t+6vMMOvo+1B1RljnvAi2YUtts/GW9GNx 7e9W6Qy++W3kZ9Utnt236LURvlGG8A0AQAWucGUbQcc2G6zfDK1Vw7ffKD/u15JtM+uEXX1WXdu6 bSM+ld20yPft+5H/uawje/FQormhWpX9nm3awnfR37PotRG+UYzwDQBABVmwNcLwtPqY+LlJouqG 702/8e1zr8W6vXzLcVMzwrpGCPLej8LjYw/p+twFypwBZfuxWW0ugOy1Eb5RjPANAEAFpeG7aDbY HoRv637VnBF2FvlNPuW9H57hW6gt8+bfJjczrW2Y1YLZfYtfG+EbxQjfAABU4Cw7WaHlO1++0I2W 76KZY0uPU0HpR9WWb7/j4yoDiuLItd30Rsqs8a4+uy8t3/BF+AYAoAJXh8vc7KqO2WCLZ2hVasMl 2Gktzm3XfBfUUNeYEdYMqOo++dR8F+9HefgWeuv0zmRdyj67O1iWzO5b+NoI3yhG+AYAoCKzHCJR fTbYFWZoNYOj5+9p2yoYZcTdSuw3I6xtRJAoikpbvs1RTPxHg8mHXXWfi0ponGHc8fcsfm2EbxQj fAMAUFGdMgwUHM+Whudj2D90EeEbqIhppeNOvuYurJ8P+jG+D/C37vL1nZb2cJOEDiF8AxUxrXTc ydfchfUTvsf5XrCum/BBHcv0Zsb9nlV/nfyN0C2Eb6AippXu5mtmHwEAfUD4Biooa0lxT0VcPq20 /vvFw4x1fVpp81gVTS3NtNIAgDEhfAMVFPaqd04tPfWaVtq1/vLw3b1ppdX1l00tzbTSAIAxIXwD Fbhmtlt8zzH6ge/MdoufrRO+ezKttPqay4cOY1ppAMAwEb6BCrzCt1lW0aPwbduvutNKq+sqKrdh WmkAwJgQvoEKCstOarZ8+08gEbble5VppV2/V6flm2ml0a/3huZG6yh7z+nkcVhcH66O4Mvruq3O 6m39DYCmEb6BCoo6XLqnlo68ppU21180tXTXp5VOvu8ztTTTSmMY7w2Eb+26s9y4ak+kch2XLU8T zU7PBX1MzG2sczQqoAzhG6jINa20cE5F7Dmt9GIdHlNEd31a6eX6/aaWZlppDAGtruZ1Zz6N0icl Uv+dXPfm+0kapCcT7/DdhXkYgDKEb6AippVu+HgyrTT6eN56Du9ZNkxn+fCYE0d5VNENpH+/DOfv uW5+1Zt1W1mW6/UYoVgL49N8YLZ2lPYJ31z36AHCN1AR00o3fTyZVhp9PWeLS718h+ksHB5zc+o5 BGbdIUHnXkOhWgO6Y722a88sB9HfRwv6mlg6TRf/bZjVEt1H+AZqYFrpBo8l00qjb+fs1K+Ts+8w nX79D6p3BPYpwfAdjck1Tr/9+it6PeaNiVE6p91I5L/nYxZx7aPbCN8AAFRQOXx7DNOphl09iPoN gVl3SNDq4dvvCZXr9aTbzdWAK+s3ylAI3xgawjcAABWs0vLts85pZJskqnrLd93XIswAWzV8u15P +n1L+d7M0fGbshMMDeEbAIAK/Gu+/YfpdA295z0EZt0hQY3XImxDoVYO37kacdewqkopius40uES A0P4BgCgIt/hPasM06nNvmqbebVgCMyq29Jei8dQqHVCrfp63Dcb9sm1rCO/MNQgBoLwDayIyTV2 9peZ7QCsGZPsoA8I38CKCN9LzGwHYJ0YBhZ9QfgGVkSr685xYGY7AGuUvBdzA46uI3wDFTGzHTPb AQBQF+EbqICZ7ZjZDgCAVRC+gQqY2Y6Z7TBs586di2+55Zb4iiuuiC+99NLF8oY3vME9gQ0LS0eX 5PyV5f3vf3988uRJLvCOIHwDFTCzHTPbYXhOnz4dHzx4MN69ezehjWXwy759++Jjx47FFy9e5OJf E8I3UAEz2zGzHYZDQvf+/fsJZCyjXC655JJFi/iFCxd4MwiM8A1UwMx2zGyH/pMWv0OHDlkDya5d uxaBXFoG77///sUC9NH58+cX56+Umxw+fDjes2ePM4SfOnWKAxYQ4RuoiJntyjGzHbrqkUcesYaQ vXv3xidOnOAAYdCklVtau+Um07wG5OsIg/ANYBCYZAdlpMxE+hWogUPqvGndxtgkIdxWD04tePsI 3wB6j5ntUEaCt9naJyOaEDQwZlJuYo7mI2VXaBfhG0DvMbMdikipiRm8ZThBAMtWcGnxNm9M0R7C NwBg0KSem+ANuMkTIPM6OX78OAemJYRvAMBgyaglaqA4cuQIBwWwkBZwdax7GQWFYQjbQfgGWpQM 9cTC0qVFZnEcy/UnASIJEzLKCQA3eX9Qb1Zl8ik0j/ANrEg6rEhrmtTMyTS+5qM7FpYuL9LSlUxB LWNfy6PmobR2maM5SKdLAMWk3lu9buQmFs0ifAMVSauh1IweOHDAOlYqC8sQFrmJlIk5+jz5hvoI XW4uAJSTa159L5DSLTSL8A14kjekqlNRy2PupFWRhaVLS5UbRxmKTD6A+zQsHwECqI8b13YRvoES MjWvvPkUBRN5TCeP68dUT4vhSGrBpXyqqGxK6qellKMPZSnyWnh0DtRjlmwxHn6zCN+Ag4wN7Aoi 0qJ99OjRxc8AQyPhWm4mpbOVOSOkLNJq3vWWZKlfV28aAPiT61+95mlUahbhG7CQNx7bY3lpAWcq aoyJtBhL7bftepAyrK62gqslYnITvYpnvv18fOpPn4g/deefxO+78a74PdfdwcLSq+VDt9wb33HP w/GXz34zfuHFl0rPebNsi8+9ZhG+AYU8WjN7eichg5ESMGYSsqWUwwzh0qrcxU6Z6lMr6Rxdx3ee /94ibO/91Q+zsAxmedM7Prq4kXz5lVed5760dDMxVXsI38AOc4KB5PE6bzpARlrCbeVYXZu8Rvpi 1J0qW0LJ7931UPzmd3+MsMYy2OUtV920eKJjQ/huF+EbiJfBW+q4zbpuaroBO7NDlizSD6IrVgnf V99wIhdU3nbNrfENt38+vvO+04tH9ywsfVqkpfvaT35uEbjNc1vKUUyE73YRvjF6tuAtH9b07gaK SbmJWYbSlQ/puuFbgogaTC678sb43lNn+WNjEOSpjgRxKT1Ry1DOPP609nOE73YRvjFqErBlZkoz eAPwIx2xzBFRZHjOdasTviWAqKHk8vfe7NU5Deibx558VjvXpUVcPdcJ3+0ifGPUpCOW+gZTt2MW MGYSttUALv+/7nG164RvGRVCbQ188pnn+ONisO5+8Iz2lEdaxBOE73YRvjFaEhjUNxdpAafUBKhH Ppy7dCNbNXzLyCZldbDA0Kj9G+RJT4Lw3S7CN0ZJQrb64SzDpfVh1j6gy2RSnq6Un1QN32YroIzt DQyddCC2nfeE73YRvjFK5kgNvLEAq5NSE7mRTa4rGbpzXU+TqoZvGVpQLTkBxkBGQlHDd9LxkvDd LsI3RkfeVNT6VJm1EkAzzPKTdQ0/WDV8S72r2vkMGAMzfMu/BeG7XYRvjI7a6i0hnJkrgWapk/BI CF6HPoXvrfksjpKgE80Cb3MST2db7W9vGsUbk2k8n2/FUI7Jzt99sjlfyz4QvteD8I3RUT+UpZMl gGYdP35c++CW4QjXeZ13OXzPoo3cZEUhQmrI8L01n8fTyfK1RdOtRo/bukJrM8feXKJ4FvjmhPC9 HoRvjIpMCqK+oUhIANAsqfNWJ9+Rjpih9SF8b82m8WRNoSskwrd5PGbxVNnv7Dxo7vj4InyvB+Eb o6KOxiAlJwwtCLRDAm9yrUkQD32t9SJ8p2UH9tZnawup0Sqe/sz216eR+jNZ4FUDarrNyWQn8C23 bdtW8ns++1H4OrXwbdnfgtKL3JOBSRRHk3yrcbav2ba0JZrZj5Vj220ej6K/M+F7HAjfGBV1JAZm sgTaI6Um6xx2sBfhOxcUsxBuay2eb05ydeHWILjz/SxoZ8EwazGeKmUn2TqSgLn4uUVg9dsP39eZ hm8lbGYBW38CkO6/sp3Z5vK1uFq+k+OR7KsebP22rf5OG8djsQ2ltXsjcL2/ivC9HoRvjIa0vDU5 CoNMz3vvqbOLD20Wlj4uMsZv8mHbygeMcr0dOXIk6PXepw6X+dbd7YBpCc5pYFO/VtBqatZ16/9W /n8zcrbebnnuRxF7+FZvNOz152qHRPO1VSk7SX7Wd9u219zk8TBfW8hafxPhez0I3xiNRx55RHsz OXHiROV1yCx4137yc9qbFQvLEJZ3fuD2xoO4GoBD1333cahBbfSLycTSIS8f0so6TqohVW1J1n5v M3K2vFpDYsWwWDd8i7RV2WgdLgrf1k6sdcJ3S8cjf3yUFvnAAZzwvR6Eb4yG+Ri8yhCDL7/y6mIS jje/+2MENZZBL++78a7FTWYTZAz9dY0s1NdxvtNQmYTvkjBWFr7VltpplLUiW8O3Z0tvVauE73Qd aZnG8mecZScFpTZttXw3+XcnfI8D4RujYU7+UWU6+atvOJELKZddeWP8nuvuoHyBpbeLnNdvu+bW 3Lkt4bOJAH7gwIH0etuzZ0/Q670P4Ttp1dXqigvqsIWEP+3fZeE7V1e+rG22l6AYdc1aC3nxfhRZ pewk38lx+TNpi/girM7i2dQenPWRRDzD97zl47Gzj0kpjdpSH3r0FsL3ehC+MRrq5Doy+oIvddrp JHRLrTcwFE8+89ziRlI9z+Xf8sRnFYcPH17bZDv9GmrQ0enS+v2NSuFbaKUbSWdMsx7csq00+Hrs R+HrbKDmu2yfsg6W+dFOoiiqvu02j8eKv98kwvd6EL4xGmr49g0C0qlSfWO6/L03xy+8+BIHE4N0 w+2f1873T3z6geDXXFOYXh4oR/hej16G79DT4hbuwxqGBkI9dYLAh265N31TknpvaSEEhkpauqXj pfqUJ/Q11xTCN1CO8L0enQ3fzoHyzSGSAofv3H6tYWgg1FMnCKj1sDLKCTB0D3zpMe3D+JlvPx/0 mmuKGr4vv/zy0p8nfGOMCN/r0YvwXTZ26Tr2ybcnOrqjahCQ8hL1TenuB89wEDF45nm/Sv+GroTv 17zmNYsJtmTEFdknmfDn/Pnz2s8TvjFGhO/1GET4ts7wZfyeOSzRlmXq3aJtmvSe1oTvPqgaBFxv SsDQqee9hNJQ11yT1PAtI63YxmWWjtcyHKLs529edzPhG6ND+F6PAYRvpQzEnFK3YNxO26D22df0 KW5tCN/9Q/gG/AwtfP/Mz/yMe2KUneX1P/FmwjdGh/C9Hj2s+ZZgXD45QL6l22gt14YwMr7m0Ymy TviWMW+l4498IMkik77IIjMvon19Ct/mOLNhtxmmnGtxvXHz6v47rLEzd5/Dt5STSFmJtGqXBW61 BfzqD99K+MboEL7Xo/8t357h2/za8v+j7d+fpNuYRX4lJ6JO+J5Op6UfAnv37l08Bt2/f38a0mUa dAnpp06d4oxdQV/Ct3Vq5AAhNWT4rlLiVefYrWO83CaPybqfqvUpfMv74tGjRxeNG2prt+8i77kS 2Kn5xhgRvtdj8OFb/d2sZXuazVaVDHYfRd4lJ6Jq+JY396ofCkXL7t27FyE9qVeU5dixY2lr+sWL Fzm7DX0I39nkC37nYV8Rvt3HowudubsavuV9VBojZPIeder6suUHf/AHrXXfsp4E4RtjRPhulm8l wwBqvvOP57PZvPQAY3bMlA/oXGuT56PequFbwrCEYvngSMKytG7LB4i0vDQZzG0dimQ5dOjQYrtH jhxJQ7rZ43/IehG+Lf0V7Oe+u4U0/Zntr08j9WfynYy1bW6HvklJR+Z8GVe9llrz+rbus2PWt9yT AeO1bZRd49q00f7bbfN4rPLe0oauhG95j5L3qyqt2vKEUd7v1LITKfdTG0Dke/JerCJ8Y4wI382S 9x55r5LG0KJG0GGMdmKdqtXecph9cGfhRp16t6wVzloS0OAHpdw1yQeO1CwmIV0+OJIA3VZIlyXZ hlqXLvsxlLr0XoTvXFBUp0HOXxPpuavcNFqDoNkZWTlfs9biqfWmNgmYi59bBFa//ahyfZv7rJaB qdeyrV/GbNP2WvLTb2fTT2fbyqabLtnuvN3joRpr+JYP++PHjy8aCao0SMhTQHnPkg+706dPp+uz TbIjrd+ybtmWifCNMSJ8N0vNaXKTL0/XbI2cTC/fU/LHTFqvpWVIPuQOHjyYBugqnY2qLvIBZtal y4dm1+vS+9Th0tq6awnO6Y2n+jUtXPoO02lMXuUo51qsw3M/irjDt3qzYfma0lHadqPsW3aSlaVV 3G5Lx0M1lvCdvHfJ+4iMwV2lVTtpGLhw4YJz27bwLe9PrtaodYXvtkqwqu9H/slw/npY1xwbxZ2Q q4xUBp1v+P6lX/ql9POexb24ntDJ0zs1HxG+B04+nJKQLi1DcnIk9ZKy+H7o1VnkJOxSXXofhxpU w2ZaC1zy5KWs46QaUNWWZGtfCsuHnT5SUL0nQHXDt1CfVOVawSPPUpWNmuG7peOhGmr4fu1rX7to IKjSqi03+vI70uqmtmr76Mv08q4bNfeIX+2cG66nNU2H7yqvq0on5GT/+9jZep18wzdLM4u8/0lj JeEbqSQUywddEpZlRjgJz/JoN0RdunzQmnXptkfEdZjhWz7M5RG3q+69K+N8p4HSsyNeWfhWW2qn kSMAV2z5rmqV8J2uIy03y75vLTspKLVpq+V7FX0P30n/Frne3vjGN1Z6H0hmoGzi5rwv4dsVGm0t 4mqJZdOt5D7htYkRkayvy/K0rmon5FWeNo0Z4TvsIk/vJOcQvlGZPDpZR+dRtS5dHuGYdellLWNm +Jb9Tz70JeybH/brCN/mB6DeRyFfd7z40NkOf7YaZ3enTbPlafmotqgjc/o7Wgt58X4UWaXsxDV2 v3r8lh/As3g23cpPsKUFGM/tzts9HrZzoC/hW/qDyA27fKC4ZpIsa9Vuo09JH8J3cd8mW0i1zczs 6mBtOXctM0DbW6Jd10PJteHRQl0cvu3vWT7XROh5CoaCspMwZSdSZSA5IymVI3yjNevsPJrUpSct abL88i//sha+ZWxgs0xGHQFhvUMNOj4Ird/fqBS+hVa6kXTG9OjInH7ge+xH4etsoObb+tqN/Vqu Ox8uoiiqFL5dr7mp4yHa7sxdhSt8ywdHcj3L9eUzd0GyzLaDW/JEK4R+hG/3terfQlzQwXruNwO0 +p7gHuUnH77rdDYuKjtxXS9+4bsbtfN9Q4fLZpnZJikzMRG+sXbr7Dzqal2XVnSml8dYJef8f3vZ ofhfvPt/W4TXKqVn8oEjJV3mDW9IvQjfBeP6+9ZGF3awnvpPQlcrfNfobFz4ulZo+VZfF+HbH+G7 WUn4NjtYmgjf6I3QnUf/x//pF+P//p+9j/CN0ZHz/fX/3Zu9O1ZL2ZmtVXsd08snhhm+bT9X0Hoe KnxXeGLjaqEuCtiE7/YQvpslrdw+/dQI3xgkW+fRKp2/kmX+mtelAZzwjbGQ8/2/+YUrnU+G5KZX SrTKJukifBerWnZSeR1T/xmgm2r5Ln/N9teVBfn8DQZlJ+0hfK8H4RujYQYBVzmL1ItLPfhn776f shOMUnLOy83nT//jn1tcD3XG8Cd8F6va4dK+jqIA7z8DdL2a7+qdjW2vS+3vYPs9Oly2h/C9HoRv jIYaBH7kR37EGrjVx0XUfGOsujK9/Cr6MtSga2z6JsL34vueM0DXCd/u9W94hW/XCCzmsfEpaWGo wXoI3+tB+MZoqEHgda973eLxudSOd32cbyC0sYdvWUJpepz4sWKSnXrMz7kzjz+9+Drhu12Eb4xG H2e4BNZhjOH77gfPaK/7O89/L8h+Zi3BlEtwDMO799RZ7bx/5tvPL75O+G4X4RujQfgG/IwxfEvo UF/3Hfc8HGxfk5IJOgrWPH47pTG0eld39Q0nrOVWhO92Eb4xGoRvwM8Yw7d4z3V3pK/7ze/+WNoK CAzRA196zHmtE77bRfjGaBC+AT9jDd/mNf/OD9wev/zKq5wQGBy5sZQbzORcv+zKG7VSK8J3uwjf GA3CN+BnrOFbmB0vL3/vzfGpP32CkwKDISVVavC2fb4RvttF+MZo9CV8d2WyCG2MYKWe0hzarM3x dbNjkR8azbqvO2MZ219H8TqQGXP4Foc+8hntGMgiJSlyLKSDmrwXsLD0abnzvtPxJz79wOJm0jy3 f++uh3LXAOG7XYRvjEZvwrdjvNqi8XHbGKYsndjCCLQhw7c2zq9tbF/zmDiOA8OQVZOc8z93+Qfi O37nM8GuuSatEr6l1ESCypve8dFcUGFhGcoipSYyyo8N4btdhG+MRl/Ct3uyi3yLuDrBRdOt5L6B ta3wra53YpuOWjkek0nxDHhMwFHNW97yf8R3/Pj/EL+w+Tfj7/y9Hwt2zTVplfCdePKZ56yt4Cws fV9uuP3z8QsvvuQ89wnf7SJ8YzT6EL6rTjetBVCzLGQ7aE6jfIuwWU5izi5nb2FXZrQrafm2rr9G 6E0nH4lmzlb4RNn000w9Xc3Rn/pftj8dNrLl6NEg11yTmgjfCQnhUm4iZSdSfsLC0rdFhhSU81f6 L/iMYU/4bhfhG6PRj/DtDon28J0FXdvX0mUntGrBOvlaEnKNbfpNN22G7/w+lgVn+3HQJ83IWvjt 4bk8fHejjr4v3vTPr4sfe83rsvC9a1ccO2aCbfKaa1KT4RsYG8J3uwjfGA01CPzG3/7bcSwfyMeO xfEjj1h/fi3hOw2Z+c6BvjXftkCersMxlXVSW60G7VrhezO//jolH+bv2Fr4VWXhW32NhO9yUuv8 np9/t976XSPAEr6BfiJ8t4vwjdFQg8CBSy7Rg4W07O3bF8dHjsTx/fcvfl7q4dTw7eqY0qTq4dv2 cwWt56HC94qdQtMw7bkewndz1PP+gR/+B/p1cupU7WuO8A30B+G7XYRvjIYaBP7+3/27cTyd6sHC XPbuje/62csWnc8kiHzolntb38eqZSeV11ESvtX1NtXyXf8YuBfz9VN20hx11rvL/tn74r/+AeU6 2bOn9jVH+Ab6g/DdLsI3xuHChfiWt789PixvItvLn29uFgfvndbwP7riqqDTTVftcGlfR1GAV4Lt Tg121sqst6LXq/nO1q/+noR+32H+XDcIIh160Kgfp8Nlc8wp1hdPg9TrQkq1PBG+gX4ifLeL8I3h kRruEyfkkz+OL700js0SE59l797FeqRneOjppm0lIKKJ8L34vjI8YVH5Sr3wveVYv/8Y20XlIVnn 0OX+auOAF5SmMNSgH3N2RxmOLL54MY53786uDbmePDtfEr6BfiJ8t4vwjX6T+mwZBu3gwWXQrhqy bYu09CkkgKiB5G3X3Bqfefzp1l5SUcsv6mGSnWIy9Ni1n/xcblr19Ebz5En9GpHrzQPhG+gnwne7 CN/oyzvBMgBIa/b+/XpLnOfy/73+9YuSk0NJh8sLF/S6b1mnpUOZBBBp8TYnKZCvSTC/456HG50G 2Bxmj6mROZ5tLOq41VJeop7b8m8Z21oj1516TZ0+XXrZEr6Bvn7kEr7bRPhG90gAlgv98OFla7aM RFIlaMvPy+9JUD9+PA0J1iAgHciSljx5vO4gI0CYLeBtLkmZhJReMBvbisdypyxGWr05HuWL3FTm greQUpNptc6XhG+gnwjf7SJ8Y32k5VnKRqTMQz4ckyBcZZHfOXBgGbRlXQW1qNYgINuWFnVPjz35 rNYhjYVlKMtlV95YPpymXGcVOl8SvoF+Iny3i/CNMFbtBCktbvJ7hw4tP/B3xuKuoskgIKOeyKN7 eWzPwtLnRcpP5KbSizwdkmtH7XwpN9EBrrmqCN9AfYTvdhG+0bxVO0HKh7RMeCNBXQK71Hs3YJ1B ABgMuSbV61VuiDt4zRG+gfoI3+0ifGOVq3PlTpCLIf3kg1HCuoT2grrrVRG+gYZ4dr4kfAP9RPhu F+EbflrqBBkS4RtoiNx4q50v5Sa6Y9cc4RtY5RInfLeJ8A1d4E6QIRG+gUYvKP26t3w4r/Oa2717 N+EbqInw3S7C95h1oBNkSIRvoEFSIqa+Z8j/G2Vj67zm9u3bl277UnmfAuDt9OnTWvi+v+Of731D +B6LjnaCDInwDTSspPPlOq+5g9vvdVzvQN1L+4QWvh+Rxjo0hvA9ND3rBBkS4RtogdyUq0/DlP4c 67zm1G3LcnEg72NACEeOHOH6aVEvw3cyY10yXXTw7e/MPrixM2ve2gygE2RIhG+gBdIipna+VEo8 1nnNyWNyNTwcl/c4AF727t2bXjvSfwLN6mz43prP4+lkQ3vz3EgD93rCdxb6bfvU4n4MuBNkSIRv oCXSAKC+3+wE3XVfc5dcckm6fakBB1DO7Gwp1zGa1YvwHU23jO+tMXxPpvF8vtzm1jRKT87GWsBH 1gkyJMI30BJH58t1X3Nq3fd0+73x/AgbHYCqzJKtcz3s49V1gwjfrhZp9fdmkR6S1fXbvmZu07qP q5af0AlybW8ohG+gYdLabXS+XPc1JyM2SOhO9uGAPP0D4CRBW71m9kvfMTRuAOFbKU+JZsvvpy3S Wct4+rWdlmstsOe+FsWzeXn4nm9O/MpO6ATZCYRvoGVqI8L2B/i/+fVfX/s1d2j7JkBtlDkp78UA rNQhOiWEM8pJO3pY8y3BWAnfm3qoTuRbuo3WcqVkJPe1nRBfuH9Kq7d2cyBBm06QndRm+H7m28/H Xz77TRaWXiyPPflsOxeZvF8pnS8ff+Mb1x6+ZZQGtfZ71/Z77GneV4EctUyLWu929b/l2zN8m19b /n+0/fuTdBvJ98tKTgrLTcxxb+kE2RlNhu8HvvRY/KFb7o3fc90d8Zve8dF4769+mIWld8vbrrk1 ft+Nd8V33nc6fuHFl5q50KS/ifI+t78DT5uktVsNFQRwQGfWee/ZzicML9iewYdv9Xezlu3pct3R LAvSUeRVcqK2mFtDurR80wmy828udYPAk888twjcBDeWoS2XXXljfO+ps6tfaEbny/Py+LoDpV4y PbYZwJkyG2N34cKFRV23em3I0ILydbRnADXfSu32TrlIVoutB2mzY6a0WufKWwpKTtQW79yi/l7S mk0nyE5ZNXx/4tMPOIOLtH5LKGdh6cMiQdt1Lsv3pYxqJUbnyyMd6WdhBnBZrrjiCkZBwSjJEyG1 JCv5bGR0k/YNY7QTayi2t2AnLeJqJ8ksrBeXnBSGb89OmlifVcL3Dbd/PhdS5HG91M9+5/nvcXDR Oy+/8uri/P29ux6K3/zuj2nn9uXvvXnx/ZVIJ/Gd8H1xe/nHr399J163BHBp9Vbfv6VjmdS7Ejow BjJ1vJSVmDnm0ksv5UY0EKaXx2jUDd9S320GEwktwFDIDaTcTKrn+bWf/NxqK5WaaqX1+z/MZp15 vTKCgzqDnxrC5RH80aNHGeUBgyG129LKLSP/2EK3LDKdPMIhfGM06oRvCSVqq6A8rqelG0N19Q0n tAB+94NnVlrfKaX1e7FIKV5HSCCRVnB5L9hwPtFcBnJpEWRh6dtSdm4n43jT+Tg8wjdGo074Nuu8 afHGkMmIJ2+56ibtKc8qjlx99aLDpTYxWAdHUJAQLp3MyoIKC8sQFrmhlL4OlFmtD+Ebo1EnfKsd 01Z+DA/0gIx4ot5wnnn86ZWuuSvM0Z86PHaw1LtKEJdg4tNqyMLSl0Vawg8fPhzfz2hrnUD4xmhU Dd9SXtLkI3igD5o875Nr7pQ59GrPWtykhVBCCwtLnxbG6e4uwjdGo2r4llkAKTnBGKnn/afu/JOV r7k9Zuv3/v0cZACjRfjGaFQN3xK2Cd8Yo6bDtyy3b23pAfzkSQ40gFEifGM0CN+AnzbC90//8A9r M1/Gu3d3svMlALSN8I3RIHwDftoI34tr7tgxvfWbsYUBjBDhG6NB+Ab8tBa+xZ49eudLZtQDMDKE b4wG4Rvw02r4Nma+pPMlgLEhfGM0CN+An1bDtzh4UA/gjD0MYEQI3xgNwjfgp/XwLaUmu3Zl4VtK Ueh8CWAkCN8YDcI34Kf18C2OHtVbv+XfADAChG+MBuEb8BMkfAs6XwIYIcI3RmMo4XtrPoujndex Ec0Cbm8ST2db7W9vGsUbk2k8n7e/rb7Ymk3jyc7ffLI5b317wcL3qVN66/eBA/yxAQwe4RujMYTw PYs20teQLi0H1ZDhe2s+j6eT5euKpluNH7cQwbWdY28u7f4tgoVvccUVdL4EMCqEb4xG38N31voZ xbOBtgoTvs3jsR2+lZurxVOBAC3gQcO3rfMlAAwY4Ruj0fvwnQavfKuntYXU0iKe/tz296ZJK/ok 2g54+UCXbm8y2Qn92XZt25Pf9d0P52s0wrd1fx3hM/dUYLHdbH22391yfH8jiry32+bxyG0nUPlJ 0PAt6HwJYEQI3xiN3ofvXFBchmFba/F8c2KtCbeGwe2fyYJ2Fgyz1uKpVnairiMJgIufjabe++Hz GrXwvZF9LQvZ2ROAdP+V7cw2ba9lbj0eyf66yjxc2zV/p+njYUp/f0hlJ0KGGVQ7X0pLOJ0vAQwU 4RujoQaBn/4nPx4/9cKZ+KXvf8/5813tcGmt+zaCc9pCarSyqkFRLesw67r1fxvfswT1xTosX3ft h4s7fNta3ZWvKeUYtnKVKmUn+vEt3q7rdTd1PLRjo7R6N1mSYxM8fAup9VZbv6UWHAAGiPCN0VCD wK/85j+MP/6f9qfL8Ueviu/82jXx/U/9TvzQ+ePxoxe+EP+HLz/Q6aEG1cDpXJzhO99yqgZUtSU5 F8wtrcyl+9Ny+BZZq3B+JJii8O28makavls4Hum6hjraiUlGO1EDuIyGAgADQ/jGaKhB4B/85I9p 4du2/Ou73t75cb614OgR6IrCt9pSm9Q52wJwlZbeqlYJ3+k60qCafd9ZdlJQbtNGy3etY1LSqt+G tYVvKTWR8b7pfAlgwAjfGI0kCPyNH5jEP3f5T8Q3//mvFYbvG/7f3+pU+E5adrW64g13Z0AJba4a Z3unTbOmfFnb7C5JSVrGd34v6aTosR8uq5SdZJ0o899PW8UXQXgWz6ZGucpOQFZbmL3Dd5vHI7c/ 9pb9pq0tfAuz8+WxY7x5ARgUwjdG4cVXL8TX3Xpl/M6j/zC+/j/+Ymmr9x9/8+Pxw3/+REeHGrR0 unSEtCrhW2ilGzvhzhp2LdtblKt47ofzNTZQ8229ETH2K+tgmR/tJIqiSuG71eNRFL5bHHJyreFb Ol/u3p2F70suofMlgEEhfGOwvvVXT8RfPH/bop67LGyri/yOYHp5jNVaw7c4eVJv/T54kD8KgMEg fGMwvv/Xryw6SkqrdVlJyW/9+1+IH3z6dxc/q379z75zT7o+wjfGau3hW+zfrwfw06f5wwAYBMI3 eu0vX342Pv2tP4r/8IkPlrZoX3/v2+J/9Ct/L37N62ZpEJDWcfnejX/2v8Zff/4hbd2Eb4xVJ8I3 nS8BDBThG71z/sVHF63Wt331ysKwLa3f0rItoVpaxV1BQIYYlHWaCN8Yq06Eb3HkCJ0vAQwO4Rud JxPhSDnJPd+4Pr7pzFsLA7fUd0vNtrRom/o+wyUQSmfCt63z5YUL/IEA9BrhG530Fy89tSgn+YPH ry4M21Iucve5I4tabRnRpAjhG/DTmfAtTpzQW78PHeIPBKDXCN/ojCe/+5XFDJO3nn1XYeCW78vP mTXaZQjfgJ9OhW9B50sAA0L4xtpIS/XZ5+5blJNIC3ZR4JYW8Ief/ay1nMQX4Rvw07nwfe6c3vly 717+SAB6i/CNoCQ8S4guG3tbarsllEs4Lysn8UX4Bvx0LnwvV6a3ft9yC38oAL1E+EarZJQRKQ+R MpGysbdl9BIZxUTKT9pA+Ab8qOf9R++4M9g1V0g6X8o61M6X8jUA6BnCNxonY29LB0jpCFk29rYM 8ycdK6WDZdsI34Af9bx/z03/+2LEoRDXXCk6XwIYAMI3GiHjZPtM5S7lJDL2tgwdWPcDva4hhO+t +TyeTpavIZpurXE/ZnG0cyxlmWzOla9N4ulsK/fv5l57FM/m9vVtzabxRNkn93671wE9fP/LY7+x eHIV4przona+lDpwOl8C6BnCN2pJxt72mcpdykkkmNsmsglJDQKXyCPrEp0M30m4nEzj+U54VAN5 blF+rknzzcly/dEs27eWw/cscr8u82YgW/LbTvbdFs6xZIZvuY7rXL+thO9HHtE7X156KX8wAL1C +Ia3ZOxtn6nck7G3pQSlK44ePaoFs4sl9aJnHn+6c+HbFhxtreFqC3AbLeQ+AbbJ8K2ua2Jp+V98 X70hmUZaq7y2LssNDHS28C030dKHo4qDBw+mf4fdMllOUw4f1stPjh/njwagNwjfKPTUC2dqTeXe RSdOnNDC9yPSglbgO89/Twshdz94Zq377yo5sYZv5Wt6UN8JsdvBcxrprciu1mPXtszW5bKWb+v6 PQNwGqajmbXVPffzBeUnTbfID80LL76knfeHfj8bd/+h89VC7r59+9K/9aVNtlDLjbM8vQrU+VJu 1OX9Q1ryDx06tHgtssgNhfWJEwtLD5c9e/ak5/bh7RtcOd9PnjxZ2lCF6gjf0Eg5STL2ts9U7vJh vMrY2yGdOnVKe6O5//77S3/nsitvTEPIh265d6377wqN9vCdBd1cC7H5prsdYrVQvRNqs9Zjv9KN 4vCd30efEK2/vp31psHaHZ7TdVt+pit18529Tv70CS18/5v7/i9tRtkqnaPlwzw5z6644opmd7Tl zpfy/nDkyJF47969BDOW0S8SyOV6OE0fi0YQvrH4MJWxt32ncm9y7O2Qzp8/r72Z3OIxTvANt38+ DSFvesdHF6Uo65KFTr2zYJWab2coT4K28fNJnbXZelw5fG/m1+9b/mH+nKtVP3+c3OE6eV2Eb93L r7waX/7em9Nz/i1X3bQoHVMnwZIRinzt2rUrPRelFa1x+/bpnS9Lnmb5kPcFqU8ncLGwuFvI5UkQ 6iN8j1Qy9rbvVO5tjb0d2nT7Azp5A5HHamUee/LZRehWw4g8ll+HauHbPpqHs/U8VPiu0Sk0a8X2 uLkoGe3EfF2Eb921n/yc1up9xz0PL74uN+fq+4L05yhz7tw57W917Nix5nfY7HwpYbwGeawufUKK Qre0gMt7xvHjxxet4rJcuHCBkwaDIddBcm7LeS7nu/r0ihDeHML3SCRTuUvLte9U7iHG3g5NHp1V 7QAmAUQb9/i6O+Inn3ku+L5XKTupvI6S8G2ut4mW72qv2b2kpTZKJ8ui40DZSZ60eKtPeRa13h/5 jPYz6jCiUpJW9vRLHlGrfycJ462QchO1/KRiGJC+H66AIaUyEi4I2RgzOf8ljMv14Loxbe36Hqhe hu91d5gqGkmhS6QWW2qyq0zlHnrs7dDkkbL6piF14D7MFkFpDf/Epx9YtIyHO+/9O1xWvXa0kLtT g521OOdb0avXfGfr135n+1oqHDFl6g7t6dCDUrOutHhvWGrau/T+0SXSqfjeU2e1vg2uJzzyfqK+ b8h7RhG1M+KlbQ4HuELnS2mNV5+GqaGbMAHkyXUhoxiZ142UmPmUcmKps+HbXceqfpCH/fB0t8J1 Y8KOZCp337G3ZRQTGc1kTOQOXn3TOOTZSUtaBt93411aQFGXd37g9kWLeNuLWgaSfM0M30W/bwZP 7XvWALs8t831qOHbte7cvx0BWV2H6/XaXld2E7y9j0Xh23gNZg15iL9bFxe1nEpdpObbdVMp7xnq +4irHE06ZbVecqKSoQbV1u+SkjJ5H9i/f781dEvfEADF5DqxtYTL1xgdpVwvwrfZmreulivZ7lRt tWt5LGUfVaZyl/G5ZZzuLo29vQ4HDhzQJtup8kYhI0GoHdJCL2ZL8Lr2o8+LeuPA8dCf5vzeXQ8t bjRd5AZfvbGXPiG2oUXlpja5xuRmN0jZhrSue3S+lH0xy0yk1Y7aVaA6ae1WO1bLIkOMEsCLDSJ8 +4xPbHYcs42YULUW1DVyRNuSqdx9x95ex1TuXWaO9111FAYJJxJSpPXQfFzfevg2ht0jNHL8Vg3c ch7LMJpSguJDWrvV9xlpDVdJDbX6dElamIOQIdDUzpeW7UogUMceT+pVae0G6rP1m2h8aNGBGUD4 9huf2Gwx1AJ77mvuMhLro/OScYpXpU7l7jP2dhemcu86dexeCQqr1HdKGJfZL0MtyTko10XI7Q5h Sa5xueEe+7F45tvP1z7npd5bfd9Rx/pXw61cW0HHBS7ofGkL3rTQAc2wPVEigLv1sOZbgnH5KAr5 lm6jtXwa5WfoU2bRc+7XNKo8VFodyVTuMqauz9jbXZvKvevMmtR9NYcoA8ZIRjpRGwLkpl/IiAjq dXWo4YlvSpmdL9/whrTzpQyb1nbwllGQuMll6cvS9KhdtgDeen+Pnup/y/em//jE6teW/x9t//4k 3UbVsX9trecrvXF/9yveU7nL2Ntdnsq9D9S6VFkkOADwIzf86vvSF77x+4s+FHX7UzRGRlxQW7/f //7FzbZaCiMBoYk69Ae+9NiiZEdKdyjrYunrkpSeyfm8KnmKrI6XL/XglHXlDT58W2fxi6bLdatD lEVRacmJTTrcWY3wnYy97TuVu4y93Zep3PtAgoEaFuTD+eTJkxwYwJP6ZO7ol/bHr3ndLL2e1tqB ce9erfPl3p/8ycbKzIS0GBK4WYYaxFdtEZchfNWGLRnkALoB1Hz7j09sdsyUFvBceYtHyUmyP2nw rjDet4Rn36nck7G3+ziVe19I2FZbxOT/ZXYvAOWkPE6dtOtffeJnu/FhK3XmO+H7FqNMcNVp7mV8 f9cwjW9+98dGO3QlS/8WOV9dHbHlPF+FOQwhn6u6YYx2UjA+sSkLzFlnTHX66sKZ8QrGKS4y1qnc +8IM4PKYLGgnMaCn5OnRb/w//7P2PvZrV1/WjU6MO50vdyvv1TLxzyr7Zs4CKouM/y/1s76jxQBd IuetnL+2eSzkfK9LSk3UJ8syyAEyTC/fAmmpTsbe9pnKXTpWDnEq9z6RAK7eUEkYp6MI4CYfrvKB +jd+YBL/63/3c+l72qf+8xXdeFp34UJ86m/9Lb1fx7/9t7VXd/eDZ3KTEUloAYZCzmdzHgs57+uS z1D1+mPW2Azhu2FSUuIzlTtjb3ePOfV88vg8yAQhQI9IPbc6scaP/dRrtfc5GRa1Cw79/M9nT7S2 l4vXXltrPWcef1orNXnLVTfR0o1BkvNazm+1BMU1420Zc0bpVUu+hoTw3TAZX9s1lTtjb3efGSpk kZ7b1KsByw/TgwcPWm9S7/n6x7T3vadeOLP2/VUfex9MZr6sMfLCoY98RgsjEsaBoTJvNuX8r0ud UVrKvrBE+G6BhG2mcu+v5HG6GTAuvfRSpqDGaK8JGZpTbcVKyrPkiZGQJ3nq1PPyPrjOoVDNUrL7 C2a+LPLCiy9pQWSVOligL9T+DXL+y3VQhzmjNP2plgjfgIM5KYc6RrAEDmbGw9DJtNHmqAXqdSDf V0k5ndr6LbPtrotZb3pBHfu7wpCiUger1sBS540xOPWnTzRy3kudt3odJjfrY0f4BgpIuYk5JbU5 S97Ro0dzIQToIykrkcmmJHCrE2Woi5RyyDnvuvmUp37qkKnrmptAvXne9UM/pM98uX3jEHvePN97 6qwWQqj1xhg88+3ntfNeroO61PePI0eOcHBjwjfgRR6VqbVrrlAipSmyyAe/dC5hYen6sn///sU5 ayu1Mvs++DzxkZFO1FGeZESndVBb7KWVPpbRi9TW7+0bCB/mKCfAGJjhe5VRT9QbeekzAsI3UIk8 QpPaV/kwLwoqLCxDWKTzsdx0Vu3rIP1d1PITGXo1NLmhSF7H/qTOW0K4MvOlT+dLwjfGqMnwrd7Y 76/Y52KoCN9ATdIJTVoCJZyYI6SwsPR1kQ9KaRGXKaJXcfzRq7Tyk9Bjf6utbdIKviCvSW399piJ k/CNMWoyfKs3wvL/IHwDjZHH8VIjLovUzVLSwNL1Reovk3O26X4LUuutlp/IpGMhWcO3kP9XA3jJ MKKEb4wR4btdhG8AQCtktBO1/OTrzz8UbNvO8C2lJrt26Z0vCxC+MUaE73YRvgEArZBxvm89+640 fMs44KFm9nWGbyGdLT07XxK+MUaE73YRvgEArXnyu1/RWr/vf+p3gmy3MHwLtfOltIQ7Ol+GCN9b 81kcJXX30SzI8cm2OYmns632tzeN4o3JNJ7Pt2Lo5puTYH8HX4TvdhG+AQCtuucb12sB/PyLj7a+ zdLwbXa+tP1M3H74nkWWjq8BQmrI8L01n8fTyfK1RdOtRo/bZHPe62tD//tH8awjNyeE73YRvgEA rZKRTtSp52UklLanni8N30JGO1EDuGWElzbD99ZsGk86FrraQPgu+ftPJp07Dwjf7SJ8AwBad/a5 +7TW74ef/Wyr2/MK31JqIuN9F3S+bDV8SylGQeuzVo7iaBVPf2b769NI/Zks8KoBNd1mGviW27Zt K/k9n/0ofJ1a+Lbs74Y7SOeeDEyiOJrknxZk+5ptS1uimf1YObbd5vHQ93M7cHfwJozw3S7CNwAg iDu/do029vdfvPRUa9vyCt+ipPNlq+E7FxSzEG5rLV7WBut14dYguPP9LGhnwTBrMZ4qZSfZOpKA ufi5RWD12w/f15mG741snVnA1sNnuv/Kdmaby9fiavlOjkeyr+rx8d22+jttHA/1d2QdXXwCQvhu F+EbABCEhG117G8J423xDt8XL+qdLy+5ROt8GaLDZb51dztgWoJzVqagfE0Ll3pwM+u69X8r/78Z OVtvtzz3o4g9fKs3Gvb68+zJQP61VSk7SX7Wd9u219zo8Uh+PrlJInyPDuEbABCMlJuo5SdSjtIG 7/AtZKIdtfX74MH0WyGHGlTD5mQycc9Eag3f9tIVNaSqLcna721GzpZbdZ/qdgytG75F2qpstOoX hW9rJ9Y64bul4+Havy51uiR8t4vwDQAIRjpaqlPPS0fMNqaerxS+hdn58vTpxZdDj/OdhsokfJcE urLwrbbUTqOsFdkavj1beqtaJXyn60hbh5c/4yw7KSi1aavlu+7f2LU01Sl1FYTvdhG+AQBByVCD auu3DEXYtMrh29b5cjuA3/32Q62F76RVV6srLqjDFhL+tH+Xhe9cXfmyZdVegmLUNWst5MX7UWSV spN8J8flz6Qt4osQPItnU3twzkJ7hfA9b/d45I4PZSejQ/gGAAQnk+2oAVwm42lS5fAtjhzRW7+3 l7t/9KcCDDXo6HRp/f5GpfAttNKNpM7YrAe3bCsNvh77Ufg6G6j5LtunrINlfrSTKIqqb7vF4+E+ DwjfY0H4BgAEJ+Un6tjfMg19k2N/1wrfx48HDd9AVxG+20X4BgCsxdeff0hr/f7i+dsaW3el8C2h e/vnzeBN+MZYEb7bRfgGAKzN3eeOaAH8W3/1RCPrrRS+z52L4337CN/ADsJ3uwjfAIC1kZFO1LG/ ZSSUJtQuO5FxvgnfGDnCd7sI3wCAtfqz79yjtX6f/tYfrbzOWuFbXLgQx/LzhG+MGOG7XYRvAMDa /cHjV2tTz//ly8+utL7a4Ttx6lQc795N+MYoEb7bRfgGAKyd1Hqr5Sd/+MQHV1rfyuFbXLwY3331 bxO+MTqE73YRvgEAnSCjnajlJ49e+ELtdTUSvuPwM1wCXUD4bhfhGwDQCTLO921fvVKbev6l73+v 1roI30B9hO92Eb4BAJ3x1AtntNbvP/7mx2uth/AN1Ef4bhfhGwDQKRK41QAugbwqwjdQH+G7XYRv AECnyNjf6tTzUopSder5voTvrfk8nk6W+xlNt9Z2zLfmszjaOV6yTDbnxtcn8XSm/n8z+zqLdrY5 mcbz+VbxvkWzkn2P4tl8fcdwSAjf7SJ8AwA65+xz92mt3w+dP17p93sTvmfTeGIJn2oozy0FQbWu +eZkuW4j4LYRvoteWxL6rT9X8LqT/Vd/H/URvttF+AYAdJIMN6iO/V1l6vm+hG9XaLS1iKdBvYVW cp/wqgfx+ttPW7uN9WxNI6XFPXv9k8mkvHXccRODegjf7SJ8AwA6SSbaUcf+lol4fPUhfBeVnFjD txpIzbKQ7dA5tZRwmOUkGxvudWZLForLWr6t6/cpIalwA5G2ynutt7mSmDEjfNe0f38cHz4cx+fO Ff4Y4RsA0FkPP/tZrfxEpqL30Y/w7Q6M9vCdD67W8LtTOqIF6+Rr08ja6uxugXeHb9s+uspX0vWl 2/evz/YL392onR8KwnftF7udrDeWy4EDy5lyLQjfAIDOko6Wxx+9Kg3fN51566JDZplehO+0jCQf RH1rvotaktOga4TWpOxDDdq1wrdl/WXlH22Fb/V1Eb5XR/iu/WKz8J0se/fG8XG9zwrhGwDQaVLr rbZ+3/ON60t/Z5jh2/ZzBa3nocJ3hU6hrpb3IoTv8HLh+0d/Kh8qWaotl1wSx0eOxPGFC4RvAED3 Pfj072oB/OvPP1T4822FbwklTaladlJ5HSXhW11vUy3f/q/Zf2QSyk7CM8P3vW/4CcJzU4u8N3GK AQC6TspP1LG/5f+Lxv5uKnx/+ew3tRAi/25K1Q6X9nUUBXilHnynBjsNskYrer2ab3uQVkctscn2 IfndWa423frzdLgMJnfe/50fJTSvuijlJ4RvAEAvPPndr2it39Ia7tJU+H7hxZfiN73jo2kI+cSn H2j0NdlKQEQT4XvxfWV4wqLylTrh273+8lZte8mK/hqyIQnLS1oYarBZcp4n57yc/3Id1DX6mm9L x0vCNwCgN6TeWw3g51981PpzTYVvcegjn9GCyJPPPNfY66lTuoE8Jtlpjpzf6g2nnP+rGGX43rWr cMhBwjcAoDdkpBMZ8SQJ3zISiq38pMnwLY/g1TBy+XtvXqklUJW1cFMuwTFcPzmv5fxWbzbPPP70 SuscVfiW95pjx+L44sXCHyN8AwB6Rcb6Vlu/ZSxwU5PhW9xxz8NaDew7P3B7Yy3gSckEHQVrHr+d 0hhavVcj57Oc1+p5Luf9qpjhMo/wDQDoHZntUp16XmbDVDUdvsXVN5zQgoksN9z++UY7YQKhyfkr 57F5bsv53gTCdx7hGwDQO3/x0lPa1PN3fu0a7ftthG95JH/tJz+XCylqOcp7rruDhaUXi1peYi5y nr/8yquNXDeE7zzCNwCglx46f1wrPzn73H3p99oI3wlpKXzbNbc6gwsLS18XOa+bfpJD+M4jfAMA ekk6Wt721Su1sb+TqefbDN8JmYBHHs0XtSCysHR9kfNXzuNVppAvQvjOI3wDAHrrqRfOaK3ff/zN jy++HiJ8m6TFkIWlT0sIhO88wjcAoNfuf+p3tAAuk/GsI3wDyCN85xG+AQC99tL3v6dNPX/r2XfF b/yv/yvCN9ABhO88wjcAoPcevfAFrfX7V//PnyV8Ax1A+M4jfAMABuEPn/hgGr4/+vAvxf/l3/8v CN/AmhG+8wjfAIBBkIl21LG/r/70PyF8A2tG+M4jfAMABuP0t/5IKz+59K0/SvgG1ojwnUf4BgAM yvFHr0rD9/X/8Rfjf/nrb+egAGtC+M4jfAMABuVbf/WE1vr9wc/+CgcFWBPCdx7hGwAwODLaiRrA ZTQUAOERvvMI3wCAwZFxvn/rcz+vTT0v44EDCIvwnUf4BgAMjsxw+eP/6O9ord8yEyaAsAjfeYRv AMDgJNPLX/Ghn9YC+PkXH+XgAAERvvMI3wCAwUnC9w+9dhpf/8V/mobv2756Zfz9v36FAwQEQvjO I3wDAAYnCd+y/OaH/7nW+v3Q+eONbOOFF1+Kv3z2m/Ed9zwcf+rOP2Fh6eUi56+cx3I+t4HwnUf4 BgAMjhq+ZZKdO792TRq+ZRbMv3jpqdrrPvP40/F7rrsj3vurH2ZhGdQi57Wc300ifOcRvgEAg2OG bwnb6tTzEsarkpbBD91yLyGNZfCLnOdNtYQTvvMI3wCAwTHDt5ByE7X85M++c4/3+l5+5dX4bdfc mgsp7/zA7fG1n/zc4vG9PLpnYenTIuetnL9yHpvntpzvct6vivCdR/gGAAyOLXxLR0t16vmbzrw1 fvHVC17re9+Nd+VCd9OP54F1kvPZDOESzFdF+M4jfAMABscWvoUMNai2ft/zjetL13Xnfae1QHL1 DSc4wBgsOb/V8/2BLz220voI33mEbwDA4LjCt5DJdtQA/uR3v1K4LrU18C1X3dTaqBBAF8j5Lee5 2glzFYTvPMI3AGBwisK3TDMv082rU8+7xv6Wmtc3veOjaRCRYdmAoZNa8OScl/N/FYTvPMI3AGBw isK3+PrzD2mt3w8+/bvW9UgdrPoInjpvjIF0xlTP+8eefLb2ugjfeYRvAMDglIVvcfe5I1oA/9Zf PZH/mQfPaCGkidEfgK575tvPa+e9XAd1Eb7zCN8AgMHxCd8y0ok69reMhGKWn5jhGxgDwne7CN8A gMHxCd9CxvpWW78ffvaz2vcJ3xgjwne7CN8AgMHxDd/iDx6/Wpt6/i9fzupb1xm+t+azONp5DRvR LPA2J/F0ttX+9qZRvDGZxvP5VozuIHy3i/ANABicKuFbar3V8pM/fOKD6ffWFb5n0Ua6/+kSIKSG DN9b83k8nSxfWzTdavS4TTbnvTtn1eOhL2FuhFSE73YRvgEAg1MlfIsvnr9NKz85+9x9ixbwD/+7 o8HD99ZsGk8W+x7FswG3CBO+Xcdj/X93wne7CN8AgMGpGr6lo+WtZ9+lTT0v/z30++8KH76lFKOg xVMrR3G0iqc/s/31aaT+TBZ41YCabnMy2Qn+y23btpX8ns9+FL5OLXxb9nfDHaRzTwYmURxZWo2z fXW0Kkcz+7FybDvM8SB8Dx3hGwAwOFXDtzA7X64tfOeCYhbCba3F881Jri7cGgR3vp8F7SwYZi3G U6XsJFtHEjAXP7cIrH774fs60/C9ka0zC9h6GE33X9nObHP5Wlwt38nxSPZVPT6+21Z/p+3jsWHs T2iE73YRvgEAg1O15tsc83ud4TuRb93dDpiW4JyWqahf08KlHt7Mum7938r/b0bO1tstz/0oYg/f 6o2Gvf48ezKQf21Vyk6Sn/Xdtu01N3k8rH/zjfWU0RC+20X4BgAMjm/4lnKTh84f1zpcdiV8J9Sw OZlMrOFswxm+7aUrakhVW5K139uMnC236j7V7RhaN3yLtFXZaNUvCt+uYFs5fLd0PGxmUbjOtirC d7sI3wCAwaladiKdK2WUky6Gb5GGyiR8l4SxsvCtttROo6wV2Rq+PVt6q1olfKfrSDunLn/GWXZS UGrTVst3E9KbDML3oBC+AQCDU6fmWzz53a/Et331yrWG7yRwaXXFBXXYQsKf9u+y8J2rL17WNttL UIy6Zq2FvHg/iqxSdpLv5Lj8GT2szuLZ1B6cs9BeIXzPWz4ei33Ktqe21FN20g9PveB3nAjfAIDB qRu+hZSiyEyXUoqylg6XSjC0drq0fn+jUvgWWulG0hnTrAe3bCsNvh77Ufg6G6j5LtunrINlvjNj FEXVt93m8XD8Ph0u++POr10T3/znv7YoZXvx1QvOnyN8AwAGZ5XwnZAPz//7zt9menmMDuG7Hgnf 6my5f/zNjy86dJsI3wCAwWkifIt1Ti8PrIsZvj9+182L1tw6y7/67X3xLxzcvVjk/+uupw+LOleA ukgof/TCF9LjS/gGAAwO4RuozwzfUn5lC5Us1RYJ51LSRvgGAAwO4Ruoj/DdziL14IRvAMAgEb6B +ig7abbs5A8ev5qyEwDAsBG+gfrocFmP2uFSlnu+cX18/sVHcz9H+AYADA7hG6iP8F2PhO+bzrw1 /uL52xYTd7kQvgEAg0P4BuojfNcjk3TJPAFlCN8AgMHZvXt3+oF/4MCB2ushfGOMCN/tInwDAAZn 3759jXzgE74xRk2G7z179jTyFGpICN8AgME5ePBg+oEvJSh1Eb4xRk2G7127dqXX4uHDhzm4MeEb ADBA73//+9MPfFnqWlf43prP4+lkue/RdGttx3FrPosj5ThONufG1yfxdKb+fzP7Oot2tjmZxvO5 fZ1bs2k8MfbLvu9RPJuv7xj2UVPh+8KFC9p1eOzYMQ5uTPgGAAzQLbfcon3onz9/vtZ61ha+k2Bp hE81lOeWgqBa13xzslx3NNP3r4XwXfTa1HBt3hBkS377yf7bwjncmgrfjzzyiPY3OnHiBAc3JnwD AAbo3LlzjbS4rSt8u0KjrUVcbQFuupXcJ7zqQbz+9tPWbmM9W9MoH76VGw35/oajBdx1E4NiTYXv I0eOpH+b6XRa+yZ4aAjfAIBBamKUhXWE76KSE2v4Vr6WKwvZDp1TSwmHq/XYtk5by3JZy7d1/UUl JMrPV72BKCo/aerGYGyaCt/qqEPSCRpLhG8AwCBJa7ca/qQ1vKr1hG93YLSH73xwtYbfndIRLVgn X0tbj/Vtulvg3eHbto+u8pV0fen2q9dnp+v2PF4o10T4Pn36tHb+HT9+nAO7g/ANABgk6ewlj7qT D/9Dhw5VXse9p85qIeSFF19qfb+zltx8EPWt+S5qSU6DrtESnZR9qEG7Vvi2rL+s/KNu+PYpuUle F+Hb33ee/5523st1UJWMr5+cmzLiycWLFzmwOwjfAIDB2r9/v1ZzKq1xVZgtgA986bHW97l6+Lb9 XEHreajwXaFTqKvl3e84FdekE76rk/NcPe/lOqji5MmT2t+9zo3vkBG+AQCDJaMtqK3fdWq/3/zu j6Uh5BOffqD1fa5adlJ5HSXhW11vUy3f/q/Zb2QSNeAXHwfKTur40C33puf8W666qdLvSgu3Wut9 ySWX0NHSQPgGAAyaOea3DENYxftuvCsNIm96x0fjM48/3er+Vu1waV9HUYBX6sF3arCzumm9Fb1e zbc9SJujlpiyfUh+d5arTV+sR2nx3nDUtfscB9h9+ew3tVbvaz/5uaDX2xgQvgEAgyYtcTLLpVp+ Io/FfT325LOL0J2EkcuuvHHxtTbZSkBEE+F78X1rgM2Xr9QJ3+71l7dq20tWjKEHi8K38RoYarAa Oa/l/E7OdXnqU6XkxBxff+/evRxUC8I3AGDw7r//fq38RP5fvubLHPVElhtu/3xrreB1SjeQxyQ7 fuQ8lvPZPMer9HGQ0UzU4C2dLKXsC3mEbwDAKMjsemY4OHXqlPfvf+rOP8mFk2R52zW3xu+57o7G lqyFe9nq2+S6x7JwDMsXOW9d57Sc777kSZJ5c1vl2hobwjcAYDTMx+KyyCx8vqSFsCiwNLkkJRNS XhJie0NbktIYafXmePgvcn77PtGRkq7Dhw9r11PVsq4xInwDAEbFFsClNrXKiAx33nd60XIoI0EQ 2Fj6vsh5fOgjn6k0mY6UlMh1Q/CujvANABgdeSQuQ6CZZSgyUkOdYdFkhAgWlj4uVcnkVXKdyPWi Xj8yvCClJn4I3wCAUZIQoU7Co7beyaQgjE0MZOR6kOtCre1OliuuuGJxPcEP4RsAMGrHjh3LteKp 5ShSE06LHsZIzntp5TbLS5JFhvCUUU5QDeEbADB60mp39OjRXCmKWZYiM2TKcvDgwUUoYWEZ0iIt 2Mk5bmvhVkM3k+fUR/gGAGCHjN4gIdzV0sfCMuZFQjmhe3WEbwAALKQ1XB6pSyu3OkMmC8tYFulE Kee/jJEvN6ZoBuEbAABPUgMrM2PKQpkCy9AWGSZQzm36OLSL8A0AAAAEQvgGAAAAAiF8AwAAAIEQ vgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4B AACAQAjfAAB0zNZ8Hk8nG/HGRhTP5lstbmcWRxuyne0lmgV6bck2J/F0thUPQfaa2v17zaKdv9Vk Gs/nwzh2Y0T4BgCgRVmQzodcV2hLQ5YRtHLrsizR1C+UadvYCBfqQobvOsd+tdfUfPgu+ptPNudc YD1E+AYAoEW28JQEZFtoU8PpZOIO1Op6fQN3+ruzaTwJ0FLbt2Nffzvthe/sJkm/WdmaRoTvniJ8 AwDQoiwATuIommgtzNbwvR2qklba+ebEWRKyUvhOtuFofdbKURyt4unPbH99qpVDZPulhsN0m5PJ TvBfbtu2reT3fPajqWNv3Zbrxie9edkwXpMevlff/+z3q/6N0V2EbwAAWqQGwOksC1MSMPMBUP3Z LSXk5UPySuE71yKcrd+2XttNgDVY7nw/C9pZ0ExacCebU6XsRD8e6c9tr8d3P5o59srxMF+D2eJs 1MnrQVx9gtHA/qf7MOwnFGND+AYAoEW5QK0FKiN8J0EubZ21tyLr663fKpqr+5btWoKzuV/L7btb Zc26bv3fyv9vRs7W4C3P/Wjk2E/t+5HdMMyL96voCcYq+0/4HiTCNwAALTIDoEhDbxRpoS1tGd0o 7wzZRPhO15WGvO2gOfHbh7KOk2pwVUtptN/bjNxlNco+1e0Y6n3s2wzfq+x/SXkQ+onwDQBAi2wB MFczrLXE+o1k0mT4FmnQnEy8AmJZ+FZDalITLvtpDd+eLd+tHfuS8K0d9xVavqvvf74sB/1H+AYA oEW2ACj0Vm53ABRZa+3Mst7q4TvZtlZnXVCHvdieMbpGafjO1ZWbHRv1bWl13loLefF+NHLsLeOd Zz9T0ImysOZ79f3P76usa5arT0e/EL4BAGiRKwDq4TSKo6hgdA1L7W8zQw06Ol1av79RKXwLLTgm HRnNenDLttLRTjz2o4ljr9Xbb+RvGNx/j+y1LW9gjKC+4v47t0cpSq8RvgEAAIBACN8AAABAIIRv AAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAA ACAQwjcAAC3bms/j6WQj3tjYiKPp1pr2YRZHG7IPk3g62yr4fhTP5lu11tG9497u/jax/r4dU6yO 8A0AQMu2ZtN4IgFrMo3nc8J3V15zF9ZP+B4fwjcAAC2bb04Wrd6Tzfna9oHw3c39JXyPD+EbAIAW lZWcZOErW5KQbvueuR5beLMFafPn0tb4ZJlMdv7tF76jaGLd56LXVdbyrx4rbYlm9nVvr28abTj3 w2d/1W1qvzuN0n02t5G8jtwxdfwti14X4Xt8CN8AALSoKFypYS0JfrMoCWVKYNsJn2kgtAbtKuFb CYmyLS2I+4TvbHtJq76+/fwNR/pzRpC2rT/5HXV79huO7Hv2/cj/3CzKv041aCc3B8nPTSb5/Z5t 2sJ30d+y6HURvseG8A0AQIuyYJsPtbbQV/a9NBTmWscrhO/N/Lrrlp3YWo5t+1637j15veWt/Zb9 KDw29pAu29GORXrDk39yUXZM/V4X4XtsCN8AALTIK3xbWoP7Er6t+6QE1o2KpSezyP57ZeG7+rHR f1dtmTf/LlmruvEkwnZMHS377tdF+B4bwjcAAC0qLDtZoeU7X8Kw/pbvdJ+m1VqBi15znZZvv2Oj /z3U1x9Fjpbu9EbKrPEubvkufl2E77EhfAMA0KKiDpdaTbJa5611xLO1wKqhWqkNl3CntTq3WfNd UENtqWVffH1734pGfDFDqrpfZTXfxftRHr6F3jq9XI+6z+4OlpZjqv4tC18X4XtsCN8AALTMLIdQ 5UYdUcsmLN8rLF9Rwt9ymwWjnXj8Tm5fC0YZcbcSbxSOiqKvPz8qSBRFhS3f5igm/iPBWJ5EKPtc VELjDOOOv2Xx6yJ8jw3hGwCAltUtw4DjeLY0PB/D/iEEwjcAAC3LWj4Jdc0cz3ZCclrWw00SWkT4 BgAggKQkwTbRDioey/Rmxl0iU3+d/I3QLsI3AAAAEAjhGwAAAAiE8A0AAAAEQvgGAAAAAiF8AwAA AIEQvgEACMxnKvfV1tuPIQ2X45/b9zUZfaRoUp4u/g2AMoRvAAACI3wvpdO5W8bVTsfcjmY7r82c JdIy06cx7Xzyuy7JNtoK+IAN4RsAgMBodd05Dul07PrNgm1SIvVryZTyZmhOw/Rk4hW+0+0zqQ4C InwDANCyLGQmLb2TnX/r4TvXcmsEQ7X1Vw2e2fT1k1yYta1TfrdsW87XYvs9Y2Ka9Ge21zctaN12 vh5LKNYC+dT2feWGJjkeZeGb6eSxBoRvAABapIXV7TCoB/EsfNtmWDRLLxY/lwbtLHgm5RuTzakW JtVtJ+F28bPR1Gtb+deilH4k5SDJ/pQEftd6bVO628pB9Nbw/LHaUgL3lnf4ZlZLhEf4BgCgRbaw bCs7sf7crKiF1wzY8m/je5Z1VtmWz2sRWfifG/tYHmqLX4+7FEUL2wXfK5PsO+EboRC+AQBoUeXw bVsKwq4eQh3h2wihVbZV9lrM/dFfn185h+v1aNs2A7a6DaMMhfCNLiN8AwDQolVavn3WOVXCozN8 e7R8130twgywVcO36/VoP2PphJmOlrLhLkEp3C5lJ1gDwjcAAC3yr/nO12cvvr4dJM1RPVzD7rlL OIzyjCjy3lbRaxFpzbb1tXiG71yNuG0YQcsIKK5jSYdLdBjhGwCAluXKPLZD4bLV1hjtxBwVxRKQ E1noVcfCzodJ2zoX5R0VtqW9FuvvuUZt8Q+16uux7UPx8IOO0V8YahAdRPgGAACjxCQ7WAfCNwAA GB1bSzoQAuEbAACMTlIaQ6s3QiN8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsA AAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAA CITwDQAAAARC+AYAAAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE 8A0AAAAEQvgGAAAAAiF8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPAN AAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAA AARC+AYAAAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE8A0AAAAE QvgGAAAAAiF8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4 BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAAAARC+AYA AAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEMj/D083vFQIMiS4AAAAAElFTkSu QmCC --_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_ Content-Type: application/octet-stream; name="oledata.mso" Content-Description: oledata.mso Content-Disposition: inline; filename="oledata.mso"; size=57107; creation-date="Mon, 10 Feb 2014 20:55:26 GMT"; modification-date="Mon, 10 Feb 2014 20:55:26 GMT" Content-ID: Content-Transfer-Encoding: base64 AOQAAHic7NZ1UJtxly/wAMFdihV3dwjuFIK7U9yKUyhSHAqUtri7U4q7u3txt1Lc3WGfd+/uzDv3 n73v7P1nZ/ab+UwykXOezPmdTH5PYG/kVBFvgv6viILgQC+vyCCEf3oO5j/8e7BAwOuvr/94+J/3 /8jr/+Z/VJ4B/5gfHDA7MAAe8I+ZIwKQAMgAFAAqAA2ADsAAYP6fIwDCBuAAcAF4gDcAfAABgBBA BCAGvAWQAEgBZAByAAWAEkAFoAbQAGgBdAB6AAOAEcAEYAawAFgBbAB2AAeAE8AF4AbwAHgBfAAI gB8gABAECAGEASL/frZBIDGAOEACIAmQAkgDZADvALIAOQAUIA9QACgClADKABWAKkANoA7QAGgC tADaAB2ALkAPoA8wABgCjADvAcYAE4ApwAxgDrAAWAKsANYAG4At4APADmAPcAA4ApwAzv+xe/+d qAOVnEBuwCxkgLpuIFeQF+hfCT5wYv6zFsx/9eYELLtcugmYf/69MAYmyANMjRvAA0ySE7hx/Av9 CUGwMP/8ff5fPgMLIFj9F5r8F/lX+///zn+rPxkMyDP9aNlSk1SvmcNkZRuE6AFkHozZxSrnnLRx Ak7aKO+ChYHtWiUNQoAFB4HpO8toRKZFRNrm5j/OP19eX1mJhP3yrV3zbpjZ4eCMrMq8TTWB++Mh A4Yl/vMCgw17AnFXBQ36HwX4rXb4e3reyfKibWyeXrwqNcH1PrlinPovvvqNb8IgAeuHAyIKgBWH z4b57V8IAiOAcAPgQXCVMPzA5pCByMVBFGAsmHAYGmDhiAJIxGGywaowP2F4gP0iDSDrBJmAOWCS YViA9XsbQNoJswF2hmmEEQa2jTyAnAKEBUaCCfH/ywcOYRBHo8CIBsnB5oOmgEIs4hgUmKogBth4 0DDoTQCTOPoZ0hlhNsZvkA1sLWgJqM22gSyOeYaXjckBIoT9DuoHrouxE80EoxKkC5sJUwqaAxqy bgh0YphgOoP4YdNB4yCCAOZO9A2MM5AnbCtoDbgC9g34TsyN162aZTgxts6maIT38/CeZacTd5fw iLA3WcfPn/0pprBQ8xT6mWJay/cNrHp1LpcHiHNylv9Of5eS9F+/L6AOBFPZPm79fPWAR4ZFuWi4 f7LOQnzZbiB2RlAM3COGw35d90HBOntZx9x+5HxevA2D7815RgPRRHvddOq5g/6YXGwpvlrDXyZt vcp2PFpnXj5n+Povtr9utz7nPb8avbSgRKOqIr26zD3zJZ2QZ8f47aydLr/c+hktDs8MrS2udX9R nO3uHp5JVxxbW12Bjq0Nj39RXJ0bHn0akMstLd+xOLF33DU7MrN0us1zeXngTySPMjfdDeDfqvj4 1KACej5M/3t6QZ4EEqegQMJCA6YB2w3aDEASp6FAwUI/9xA712H+EPGbw8Qk8bUNkyLM88XVD4+A EEM02y9rklJ8H7q03AQam1Ltme5a0cvq22pi1RNFwzM6iWp6Xd/uaPyezybEWhUoGQU2biY/vQB3 6VtOYTFXefKexn0cjoto69cy16SpHF7mty8L7hf3YvUPmMIgEl6M2Sr0nf5c96psjsXNrNU/xYes RCAfALEoFH04Oc4Qr1ELsSdzfe9m46Zl7du3YbIztKmafVBTiPqkOFzQWGpAXpu7VT3f9DmYeyxq SFVM+pBW2MS53OCT01nUwKDimftOe9HicKAeJJjE3q0xVhE2bF+mjGMt3eogv2fNkyROo6XwLj5N augWHsJ0JK6H/Rgvgx2GkF+SnPcF7Y+6QommRAnZWCQz3Qj4J9jl/qvirVk+JJz8MvawHcdXwrXc 591uSeIdhoDjuwF3c+MnOeWPPQ/RRbrHM/3VF3LRKc7B9JVujbb7+v5KB2qOTLKPcN4PuivilQqk Fj+6GgOKERBbd5QzfwVu68OFxo8R8ISVfFfILcE8KMGEwVQaD0FPb8+xFHSTP9V+Tzy+ucLqsXiz nrxpzev99ZpXv1/SqeWUh8UecT/JeTZr+Gvh+OxKagmCQfhSW+am1G2Bu5Y9vFh5l0jKENuGja1b AsYDlRxdHD2DwV0OZvoztMJJXZXUkBhb7ZnhvmDa74XQ/ncvFwuhvgsi/I+lxI3K7xQVequU4dj1 ItNxB1Lq4ucXa+WRTVocgW9Hvg/DDcFS5/M+96v1TX/KZJv7tXgc0twsc44/YJ71+xKX6luezFr9 W+tMu7vTjyCbcP9jlUyjpr9dsD2XdDO3zHJgBin6jwbW2omnDf631P5JpwVcLnowqaR7sibzg7I+ XklEDIX2xwWfahAdKRQF9JHFsIbeqLTZTRhA+Kww7CdS8XmFSW9/ebCfMUC9/b7H534lXgid8zA/ W7uvryfig+l4FmkZMA8zjB/N0IgTYpSnf8rJJjTi+ITBNzz4dViVtlVDH96GQwsGohbb57lueMCm 6amq4e+woUgqSJ3rGQiaGy7UL6VUDNuV0FbpDLELGNcqp2xlyWy2TRPo8ED4FqNkyNMn06tEHbKR 97vXLy35d5d8fOmGbvmE/X3rSkbbgjOim5y7b39SttaLBuV0JwuEfHwNBiOV8jLYusEy30nGRiJs 3+HvuILhJD37tqbuQQXly89ZkiRrFzaQgXm02LwcCYmhbkbHRGCGnj9fNrnQ0brsFrlSMddmmzvk rfyemurn3/kVBrk0foEoJcVLkouU0N2gIOiweJbG636fADGPsPqhRFWOdORg77PL4yAd11wZYVec jH9V820meEVURce4Dcdj455fMqTTSGCjUkHeWyKtYDSXwU0kugJ/vKx3PcqgNnvqe5KkcowwUiqX S0TlVLKh6vbo+kQlg5fwwWvuWxYDSeVSzA69+V03h9NQRGv/7rYzAY59BgX0UZcDr8BQYYNwNUxZ 466842FCWl3vx7+/Jx5oHKu1GtKW28sM84O6Cnq6H+wGRVbIZWTiiV7fwGNhKySflsgiRa/nXXCT YHQ0fbqzVg14gcfZM345rEBniqPTah7qzJEdFj0zOpZZhOW8IzdbIJCioqugxH/PC6WER1TqsGNP J5Nn1HcPaL8xeOVpxRb+rJHjgBClzZPyJa8kqFGI5/JOaU5ISB1fyNtFm2Anf2hcBKnp/viwz/cp fws9ehkPnkoE5tV0+e2tzZaeizafMgkBacneBOWexg/qmMcH9Az+zNNR3X7Xhj5bfOvqNabHYczm Wccj4RlmFUwKXzXRLLTm7DI+/Yu9eHQKL+JII3QhR0urKW0OEK3N+4ulk6qvu9Bzb3ZBuIU2ZtcQ sff6MPlqBEzET+FBlRaTxMJyZAofLOujGZl2xshmf+JVsRYzLYerKC1UvH0QQJbB4pR1t8/RTOkv 1G9/qArBaEVEa3FE3DNZTSuHu4iaGsUVyJsnIUxoz30ypHnItOpQqQyO31xQ5HPes7xAX+rkCrbg RoPF8dNLQIPx1RJVel7TDbcwIc9MyX4TdpBqK9Y2rF6BFbIReDmkRrKvfaqdcs/0rrIsQOKpuSro d3MTX0PUJ5+DTZ4328w/aI5pdKho6Pm9YjXV1QrT+AyrQf0XSymOmUVC6BZrMhDmpB1WU0Yp09mz qop1M067i0B4IY4Jz7SjaaiWPNVcoWTVla7O7LyV0WzLTskX4tSONzLiuo1od8qYy61NBC+VuR25 0XIIxEQV9RL9+aGKLNQ0Wejb/TfYRpA4BWSCimV6xXcHLo6KKw2HNaaEEmt/iUeKYqE5ybuK1OD7 OhIxmyjk7kxtp6hyRdVZxmV3eEpbFcEWZVcLFHW3r4jW9d5+pOoE69j06qy2ooK+xCoJto4xQnQ+ 1Imw2+sqBtFCZHA5Hl0lmb9O2xxdlvGTJWLrZ2hffeie2+Lu7iMILrvcDLc4145IasN3qTJLSGNN jBz9teXzCxuJ25tM4LhpodN/4k130iZixi7a5OVwFzAVEeKYOdbe5Iz81ZeNvGJLg2REyBhUyWEv qjLb0yP8aSn9fTyX5r6ahMlt38duHgqJrtLG5Su7NRJmPiM5kB02PrZRMmd70DdGnG64tBZvoJaq 7WHw/DPl8Ch1ueslWnO5ktDULfW5vtgA4+1uMCxZIW2j94cR/+GJwKXPxDDsVJlgyN33I+XpCBhr MzAXI01GVj6mgvJznT9VPnFmX80KLhjZc0O0zhfpS5m1JHyeS0Snr3v0eZ9Ekgv9ORXJcJsqUdDL 12ZYGg3fP0QxrEyYa20iQUprz6G3/smJ+Ck4ZeODWFjhhWLzC/7cdE+CxCR7UUsOY6YVf05QgjLx ZWSuHkT6tyrGbkBE15vsP2feTGOqMdBwDInZS62J721NKTGohB47dqGl+o02k2oryuHJb46j8BCq Lbcu2xA8/L3cd32NhpRL5vE6JptWiq6Oy3pWx7AfzHCf9ywQ2Y7dLc0alOmZk13Z5jCMvL0u+mwn jTn/60ZNe8h8pWUxdRqjrzRrvTAGy07ZlTBkdPyzma7gAn2+9kxovwO5cn1ONPGYjXdK8W+fFAvV P4Oi1u7rI6Z9MYiPlsPNOmdaRzEp1l9cUb34mGTe9duSOgt7zYT9oNrvI9wN6ibUEunzdwoXcVKu Ldi/UR3TJCWSXf1zeHfmTRfzSlG35ANXDNWfCdEJu4wXGezucrF67atkUYcaxscdQjJLywtCX9xq R8M2EL/iIMJONtGrk06SrytmhvbxKWXW948PPYh7iVdN68hqJ6VehN1sZfri+zZ2XLeI6Z00djw/ ORsnvHB2DUZvjxzuF4wxCxwlEAnhxESNo34dmDUvV9m2x4lo4O6lGBuWbDjXy+SiukRi18gWZDm5 Sl9gg3JMWm0m232S9lXC6Nu2Jxf41cJHn8r72cPntKTp2nHhGEXltq9E8sHtYTK00q3Fjj9+D7It OSxEVixqlly1pRFlMFk0jS6NXC684IZS6YvHr8JKgphWw3samx0xx66hkt2do1Pzd7PuMQYV69OA 63q+PdIblUtTIwfTjOhkkU2Kbw6XYYhpc1LeDCgU0VYRlUu9+07Xkk1DzbqapeN7mTEufvJiNho/ 7YQ8c79pmnYL+G7i1C4jZrYLbA5jrzpviODDM+ZDMXH3wxOZmcR1bYmJl9P7H0YcVojmszZVTc/d Fk/T7ekETRukiW7Y/LhnkUUcFZEL7JaECX9M4zsXG34WWOuqTSw4jfJA/RamUZgOtSsvDZ4Ztuvc k7J2WteglD+8LZOLpNhAP6T/RQ3GIYnaI8ZC9SV559I1KMNSdIbwJQwhOV4aSSDlalCM0AtvNtCc qTImkSdMT7u445NqNz/l1UcFN/GcWH5knewFH5/T6e13hdPP5VxYdsPvv0H5lX5159kqh8DVHjM/ 5y4cmz9bMcYsqIDdSRxYDT8qeiPC6QdLlF7P8L1fOpViWgsd9kCg3wMHDg1wNhL9HbFfTQ8zyC+1 6rqAU3fFgbfqJ9Fh/SqTMH0tbdVad3lNyUBI9fV4ATmw1NntPuVbQ38NiaTdsiG7Kuoqt3RZybeZ VMmW7MUghAmIL/SEuOigfZHqXbBr7OipXV6LiFTyvs/iQgSkgAgJwcbkz+zKUbNS6PQ9l3FRW4OO Zo1R1GP8aWVmaKJzwIG5+HHEFG2+0IHkQbJ41G+0JqsTH+LmCbqOAdb8cJJZyRDqWy1WHoLS7fkI 4fR3OcdIdTx7i7xwwTSy9IKykZ09KQnVhi3oDfizwUbXFnNTEUjDm3WWSoZjO4zIuoha7fF0ukz2 7i8fxqpr89/SxcOl6svmVvHN6dyb1WfBvUSalcPYfXMfHBAqqTTSuLNFXdHT+hDwI5GI+3GL7i1m UQN7qujm0MVAproPDrc66nMq83CKDEr7qP0SW+VNErLQVbYUgwi3A8pacJc+AWtRKCPfvC9T01i9 8DxrC7VQtbXbK2/Y5yOY+fDGmLXltQHuV8/LhN1gQVEzyjIDLUPZv8XZcF3yE3HqR5s4oeFsP0b9 GAszcr/Z3jFZyTC5IVQ5PTVXELKfG4fR2OO+q8GSmNWNQOErDmoTFQ10bCSuMyovQ6dobHK1G/z6 E8eI+LR8pGm2tl8fmu5CBbOLqulkft1Zyvf7jNBQNVHKajH/1sfwcDSbpRVruSPjBH95vSbGxIZn 19x8Q9gnHjS/b5Cwi3FM8yNQRYvlbUP4My+TdXCqUFazchRCksrym6ydsTNc+RT8BjyFJ/Nm9bkU jhQiuU/JuM4ExzsEUD1DWbz3tFHQUYrkYrnP5NtCnKPaq8PKfAYWVtM+jczEaF2Dwz9gtGhvHW8g 7+O+K9lXMN7kfSJVmOmJvQVDG+ddM9+G/TT4vpxeIpUJzrVnQlmxt8sSzsjqrqmzH6GP/XmRUWLe tUQjWinlkCz0xaNpzUVs3IXA0F1snM5I0DQGLNt0g3oQbxYv7KF41/lNlfHFZfxH0C1NKDPViDVt Z5maIBzLQXikQTXR+WIxd6NmGR8P61WTB2W+joD7JvxVpFwKBlN6MItnPoob87ys8FVCPf2JZP1p 9w9qS61HETOL7S8LH8JiE32/PurnqdKhZaWkKGY+cgkq2eNFtIQRPISLsC5tW17plYbjefjASGiO j8wG/Oa5SYkY/XLEHaxX5bQ9h6NwpXcYazuw4HPKHrLbIqHptLj8ne9tlkZUzxqVT15Ri6RR2I23 ybdxX2uZLDrqoAEZYrYdGnnBja7zi/q6dPfbthTJ+D2op6+2sMKanHxzm9SbdK2DM/DQUvWgl2vQ Mf6REPAvsfqa1uWj4aZ+175PiUoJW+PVAkJBedDIcISp4KTAfXkrHP/MLO6Pnz10rDZR7FEp0BpE Xr6WKw83mVzEcKOskR+40emGtcTY9BwXk5tc6CdpS6aDHvQY4iozF/R7i0Twyfr4rb+jZAwoAsXO RrEc5KTR1+21d3W/8IiMhLi+NV+WFC/YUKMjtWHjikiMUHajmt3GxCBXcrn9Sr8oq9RbwvIl5JAu Wp3qU1HvT12Sa7J2yrjqa6N4SUqJ2H3kuIlymZR68V9z4hr6UkifuIkZtPbEceQpv7IFJVngrCXI zN2Ih7J7U9tsRIVPSjWX8KiviufxUr/D49/kim0zOLbX4ivqIIhUEOqwMJQVQpgL+KNzd/TGb7pX nsQgZKyTqCb8i3XC9455YXKve/zPPH516qGTUq+cNwSz4kLFPE4/Nxc8X250mmnTcaKnjSUo9+SM etKyre5iordrsHRCY+XmYq524lmXUVlM6BA1+/gv9r3Pmwa1MVfIE/lTxBtUaFhkvynXrhYkZzXY 52r4iaehUAvfJ1JXh12Ab9Ov7H9FpKg943yDyMlBHhiMGb2syWo/n49Z/z1EOJKIPPlF+hFj3FY+ 4heNmEdvZEjvxYHq1zciELOwVlA9y3s2kXj6qZJbDR6nMIW/HaoazXwPFhvI519wewJ8ZppU0TKv 0C/X32HUFMvyk3oZQX47filUauu7b93SYx01LnU+/vM9o03EiMAH64KWE+/EIYLZOuJgHpaKN4yd 3/LWqIe2++2dNHTVSFlUYulXWgWnQ+Z1X1V0ViMLxG0nvtpolUUyJbG9MIOoMoeX5KTLIb2+cEnp fZfjx5b9KqU3T92KnGq+RE7nYzZZka+kXtcfoRXuuaqyZ5lOIeglITpi9DGB8S5WuFWxAyK0dgH4 qUF5jbTu+T2p/G2ute+CJLTjkFsTCfN4vnfb3kjuLbL9zcwnCH7fyCnWl4GINicsX/Tmicy7heXt gQTbQiURtugVy7tnzpgG6G/VWck3PfG3JT02Y/a++mFSqoLka/EmNCND0enrMvkrPXArAjLShZ6P g91Mm9+97TQ8GNlWPwqXbsqQN9PyZFDzZzLzO8dkWdKytSomrDUh5brVKpOMVw3Iv3DGR1VF7vWm nHPJ19TGdND3ZhKalsFA+Yymri28oEMfeXonwiToPMgswHpQB3ZePVy7M+tWxFLTHfSNcfMZd+GQ kmE7wrqlqO6RDr9mARQvSJVLS0QHva8popi7HRWzxnmuaYdUsSS4tgq92OOEkkdag3CubDuOWzWo quh2iJjUxSnxQL7F1lirPlqbLbKA/eyFc2ZaQ332rFgDmuGE8YsOPJBCESY5VyrPI3Vk/g5L+jUI QaXzigffyLzlqoFYuV1ZfU4uOsCi7UcSyV+M3Q9cRc4BFgTlwoaEo9ZBTpOxvYwDIVjNDKR00beR Pg/G3NU2vB902+snr85xqPSToY6m1rlV9iGcfX6vUo8dE1PW9LgqazAGrdFiHcUXE3rNsVVFbSUj HaXrT6Vm1o+7ETLOK5/z2fiiZ9Q24Pa6HYdR41XtKdxb2XwRMszq0RoULbUrWxJtUR79DgPG1li3 xkOzb2mtDgVvFUnj75hGrbNS0SGbB3Rc7UEQH+df4BKRuptiNSGceKHktNMCF0k+95atDJ29z6yu 2O5S22vn+yOmx6o/51UtkN7jjdvyiVYTX3aE5+pMxuLp0uwJ0Gs/HezWM5s0oRJzFgyeT2dTD7H9 cWOa+6l0SUzFMKp/aVE1Z/Qla3uxoarluWfkzRdinRcik8NHXr4e9sDKGg9OD+3XY8G5Ct4OvdGI 12OzxDlNyNptXykydI7KCcm8H4kZt9u0u2fbi1dYunI59wkymlbT2sNO8uvR9FrHkwHdifLz+ojP AZ/+q88nX5SiADBzSaRZiyh49mF7afjRPCTI7w/NcZ7FaKYyKTy7XuVGsXr7fiFx2SmSNVeXzmt4 sFuj6PY+Hy5cpKHIzaLWE8wpJLrc6Vtb+fEqRutxBWNS5BStCGn2qIo50ZaK0OfnXTZzHTxmpuQ5 pS026S+0yckbuC3CY4ceMXrNH85KdHTEnoxpkR+NuaChignIoTkUFDybfn7kR7fQi5arnzMk9T1m iP7ZwhJFwkxeRKOzqtmajnwyaskMeT6otpMQwjb/oIbvDFGBK3FOF4N1YnhvBHTDjurUQAzloU/U Th/jaHcs5Dm5VMD7tEOpl7rmUNRdG0b6JmlOsepUOwkKNZ326GGqDN2O0lsCkqJutkJRNgUmTuUI aMKEcbUtm3tJj9Gg61/o5j6ZzFp7LisS33TVY3JfvXij1OQPTfuLKgJ5vE+0SyVqOTY96ROtbqDb sQ1PXQhBHyIl7IiJtwVKyHuaQ817ystw0cds0QUw0nQzYijXQoLPYPJlZFR1IIVpXNJZ4B5ZqG1Y ifhpH/z82/Vj0LyMdo34PG8sTWTYVGGjTsBXT6EMyJn0PSh1PjaAZa1iIYrkfK5U2C5AptAsMbIj JVS2q4zujxmSIMRZiJ16cYVWr2Ajw1Hrw1SkKWJN4EQcX+BopJ2fmMontY7lief5NIM1Wqdie46F wXaf1O/OkxJCJWaNfOWRPvFWvVLnPqrvg78QVm/DkTd4f1lStJq6r5FJwqIcSNnL3ukVvXoAx+g1 cd1OGhbcia7AuaMOwVEhF+6P2gklHnoENXjMr8bgT3yRnfgmPVB/BldHATW396r6Xo6Ot/cR/VOz TxMmZaw2/dY3u8G/w3BcZCnObh/IwKa5bR1l+Zpf273+zB65DrzviGecr2MM+gjPlSMWsL7tekTn YjbdWqcKvcS/mBhl/DYgbYpeHev/bgTxR9JM44WnVGHpjRf0dPtpnkG7/yhP6OpI2LaCFQ8ee+Zr 0hF/zCYOQd5u+zWUXNw9b0lZBZVt6/HToMhOJmTBosHflsoNd6bmss5WpHb6/Ti1YZmL9fcqK0fu WuwEUgwtzuNhXs/McnPi3uf+Tdu8uosqT9CDpC7Eg76e4sIhYhnXaVAl1AZcQmAp0T8PmSKWNFr/ nr2j5hSlEBxx6QahJ8POlreJq3HZAU/EvIgJgQvFZinPXmgfg1+FMYT9h/h1t9/GxoFur3pe2TCG +8fZdpRfccKytDoiMUVqyEtbhjrPBhpOdfoGThRx0m42mpbPg5t/WbJRcmjJuF1criYfyeyrceyb 0QpyP1OL+baYrZw3dt0K/tj/qLFBKAemRmOU/nmWHV65VIMSOyYw9XlG1WVD6VPCfSuWpylPZptV fWlugx4lJP3wl6T8/E8i+Gc6s4gT5ZwP+dxpPNQzS5234PEDLU6WW57ApWR3s7aYSd15S9mr2Edf WY373QM2ByXfu3x2psG5BqbDoPyamnl3ZsMWT81gthKmszIRYzhtjRLF0NpBAq8IB2TcsQrcJtHZ jaicjAu5pQpO3xmo4GIZcWxpDekVPTR024KHKIKn2jlems0xQs44Fzpy9thKa1igoKpjKcgr286g bv8obqDaYeX/48k/zsnQf8jncWKr896DxE/T5Yk0LAt3pmPrLC/ilJ0ojCMqs/GDDRISOD7rteTc yeWuQSEBocyyyJYvusLy57p06nZiLusx8vz7HC2IqxCK2dvq9ynOXLy0Il4BLi6I9soeHxzMtNSr qla4MWWp0kask/TIY7U0a6sK3jCOIhAIYaM7TjIk1wsjHm8MOBJ8xrjfJnyXHn/HmMOagJoB71MO QdX6KTvP14S+b3IWHyEy14VSY5mFwDxUqfFBOOGcSdZA3g5OiG831PRUDb9ygnZOczlaXbb0xFvm xFdaVyCj/6CgYLq0z+TCrbdjdnJRV+nkUVn3m4b7H9LruKSmXDbJKgM7ToZBjm1N7BTSK7MPEnpU AWMz3AxSRBWRlAmhajNjGBwLkqyjEbnTzKxwEmEZjDfq3Vo3XfSnmaVUNkdYmlCh+qZtl48Pm0Vt Ud41z910XZsO7+LrZLObsX3ekOh7Xqb/kiIQURRfjdzv44SY1z0GyTixp441koJDWTGPVq1Tg2Lb TDLtdwYCh99z7jlPOoXoG4cKDe/7ZNwll0+MGpabOedHGggyWtIqzlD/4O/9sWiDpZEI2StgWCTc oi9OJPSBmLyiFV9PzmSeYfQsated+Lg5CRl73gaVQYMmFRobmGoeJ7Ps301YVJj0GdGrhcMaqail xJaN7MaehTw31dDgRVIqUhuhcnxa25bDs9FnpgwdXuD75VHDPY+Kf6HmmaikWiRNlTx5D+lCMwm0 6MuC9CI6XR6UthyiW9hYuf8IXOsdJdgpXJ8dsEpCOjLoGNvKC2HdxOxfkR3q+cnjnc2UV6Xhc4XW pKmD+ZwYU6lDHlV8t0bKeSnfmmfxQlmnPSaabqmy00arPksW1VlZCq5ADrwKPX/LZmDGK3ItLSt8 TUPXi/m7xLUda51p3/vUo+YbL/sn+38DBiD537pwJbC94UmJkQzH3PO7hYSto6SbesdeU8QJDINO V8aGsJWSWR3AJgLuS6846nuV5IV1R4ePtqbO6okx3UrTB89dokc3rqY/zWuLHtzcS6+4jo/nJxD2 Oq7HytxVL7fI5XuAe+X9hO53GrCEwjQ0dRPkPVtBH73y0Ad9i8nBbyMkUSVZjzcO0PPD6kLUuIYc ZyOqBLDGztfvfE/TI72qRZypCQJEmGv9iStl/PB9wp65PJXBHB5ISuEX147a38Jh3cn1YWF1eAOz mz2Txu7y8RT1W+Fa++7eKbH7hwF0iUumyJsvVCQx+c9mLgVfNNAblnFagj7kad5+vb+tyLkUjVWr 3zmw+5J0XG6ftwMq3sScn1fklNy4Rz3n4smxbnaUHHw2DY8VY2x/3G34h1cjZesr3SZAa6dD/hOt /cfqVaWWvv0SG9g3p+HByHzcClMuV0pM2mpRUXQi19sdK0zKdXOEB982Y6aj8S7rPlFfkJ2YODl3 mxrm083VqnNc3AdRvW2wZnBUNDb0sKAjs1RkeK/uazwd968Rvtbk5I4YpkNIHLVzUjqW3XGkN+Z0 z3xC5m3pMYzAFD3QjMl1KMSyUvSDr/mMqenX9bo8Yqm/bSPT7lwJGn2asWqx6x901NIZ9Xk37pNC pSvFotMwIk9uA1KhS4nvkKt/jNfgRNqQiAXJ5nXhpuCkL9EoFp1Vw1S45QFL+Yo7eKoAP+ZRgDNe mmUiJgxMXg0oSzotn19XnphmiJ9WSpmufLwtK1m92nJNQz22TiePmy5l2udZ19kaVNd6rye7r3G8 Q7OCh8jBFkhHvCIAdlSvglapi5wqIN+LzYskZmqZ+PUjrxbKJXZkMbhM6bwjc/3Jh+0GJX5u+tXi cgFw9wwjjjCCBluperJh6v9wb1ZBdYTpul64u7sElyALd3d394W7WyBocGfh7m4LCUFDcA8OQYO7 B+dkZs6uOrVr6szNvtoXXd3/V337vE9Vv18TrGvBKy3Ubo3jLrAmxWzS1b9VPrJfQfMtWI0u8Mcu VV8GPCyE8ZVKTO1mYysjlsZLAr4gzKg2afAxnn4jYhDKsFRgP/0cKcRPOsfiL5ZChW2DbWxJhSQr QLSMAVhB8KbhqgihkRYaJA32C6k9HqCqRZXPQd1uLb/0ol6LHGFVLmIcxJIniqdKX+QY0dbSj7pC 5RGv80bxRCrmyOMPdwN9+CzRqGAAao8NtiUoxlvHfJ0KYkg+8Y6qC5rPddjZNgfPS5NRhhBFE546 KDBJ/Pm8RMYPCMq3Dgy+9Z483AhUXk4Z97zYfZXcbrGiF3iYUvcJdfH+Dge2coCxleiLiffpGjW2 QMp5RyDFy6STeVqFhowyMPtnrNG4KjEUvB+1ddYHEHmexXoEWz2Lb62UqDc4tLMJBrFfh6m4CL2B uMEEklWc46M0hiz8X42rB6wo5qrr1FY0xq+M+EiE3/XbkmIk+J19oOfykCzHKN65Geoq/9zTJ3c5 z7TT7jeGHs0avhzhyQp8/EA2MBJnzSHOO/7yBsfWzxFHcm4C6E4ldpKUBTccePuvj2vSbrot3Rs3 gAqeg6bzYUuSLxL9ndfueK/xqq+hmwW1WlUTe0WFhd/4Q63vsAw3u7e01xdv72KuHYw2dFYlt4OQ /YlPirCdS49LI2cOMCPMnTsGev8toUhxGRaKfwm9Qv7X/5P/P0I5/wXomfNfQF9F7S7MQL1zNEli 0Z9jNJYLWqXDRD7n8NHUWNq0jZrNlfYs3vN9+gsokrEhXf+Wqkjuye+AaWF+73eLPE0tbCrgFDzY Z98gqjFqmMgQvfbb4LxIe5JW5mCmuwz8YqTcicXDm3EvIm286DaaKeNfG0f6mpUp4BX9HmGg5Qfb dFGi9tAa7er11+gJNPVtAgQrVMa9BFUSgNYLN4MiN34pVlhfd2aZ6JW0KUPVaimDs6wjHGdiPs0g /7Vx5gqbpkYOdPXeH1MWq1AppIa/eHaW8MdjDfCjsnBKI0F7z2QC4eToxPBRxKPQQXuy6hOxWew3 zmNZYvq1bsePYM3gyoEJ5jB2X1cTZVMeOT4jemqKezdEq8K7vtB8p1s8uu2kWryY6v5DPy4FF58f MkdWspA5FgCRI0GEN4G2tMu4HfeelqfvWnW1Gqqm6NWhOPVQkYpxkLaJpyaPWac1mmlppYWJnfVJ x3HJdkl0Rl8VlWIdm1/XbMTmwDrqTpICty6JAipVEg86FOlHMdFBg+XwFR8PTO/6oTQzzCDlfOIE O3xhykGsaGBEfZOWFGUq6gv8P8jE5aqIpGHJNw8R7ZVYvNvG1Iks/UtmU/HlplQbCbUDdxHRXzL5 46miF90g1hxRxeZvsHESMJisR+DOD0SLzdyw4wSouizETNs/WezG+AqrPLDdHmQZGf/hTPa/zqSe /PF26LQ+DDNTEUir1elz/VZ0qd+MQ5a7W7p6T+Jkai5tgriGCd222tEf/Chdu+Xzhp6faGcRMmrf lFOwuhzJk1Hy8gFqfGnqdcDJy9gH2/OsRvH/oZCeTJTwUbyCl/wdYo8TW6SVvmeVzaob+qv+9h6Q FwzCd3Gq5OR14mId9jBPvXmxWZFgIt6DrCNlnyvxLyX8ab8ilCZbK5CKrhY31dXrQ1ZOVDmUqwCV zrFzVugrzUwy9QYPKrrmUuk+k5IWA/zpuYciVVhMp89uO1M9WP8viaZPf0mE/y8S26/TO93hV8iq VyuGTSnyyYMLxFqs52pVNC8rVU32+6QGuT86K7Yc9Inj3HLxSMKRst5toBRNUxGX8Fej//u+J43P NEEeAQB4IP/PJP5rQ0t/MmGNB7OH4FAQ8bhJzXElhZbkCv5NGcWRR6bLD2BQvDT2M01BfeocH879 hPlW75Z1dXi0SGyzGCg5GnxF/a0q5yEpVjl69+F34MB24O2cDa+ieV3HWKqWt9Mf+fW2jriffMm6 xs93e8tITsxLSkNKpSk+Z4b5a9NTPa/7douj0oFTznMShmaS+2SLrQQGNnkGrIn4gaPX9HZDtLeT mq1WxOQL2qw6p6zLJjEGJSYuC2CWZG9+U2GrIIECeiyKcvWmXQ2SDzEo5VDBPXLNXc1g4R8G5b7o 1rb3H2mO1Zn1mhwMpacWMD+XfDkF6vlz4TXRrmB3suGwdnDjyU9UMU9/xDvgk6vPr3HMVsad7NBT Tkv/YTU9AXEAyfLHkdOihsk4uTxpg6K9nPft/e7TvPpwFpWX4L87X+HQNaH3zupYmcjktM/u7IU0 zVp4mnnWPUGJNb6pbwkAmZ9c+dEChrHO/bWtGcKqDuw88ww5I7x2rievi2O1QahLcfstEWUuwEu7 UryvraT2T6O0C2m5vwzMjQVL8J7M131Lt3lOTAY27xQxYdEwEAp9jNgqlyajzrRJ5vRlN2/nHvC7 BcJcLCK8pOornnRcr3kewr0A/IGA9tBt8PZPP+EI1pZ5mH4iWKXROBGSKJrONk/7K77ZRRSwQz2L 8mxqyWgFQALmpkz+428kzdOFfJAn+UkfW5ggU/gM18uvaY0WCzuDiQkXngRxLZMJVHXMFUxvvHYM +gkneOcaq1qiSFY55G9xrZ8/FqcRorzAJ/CosJOE4LvsVFwPiw8l0TVhf4RNaLU6zvVWobZcfpu3 2kFeDh0JM0aFj0GR8/nhPnEgBt0zobm891sK0b+PdBhBQp+ZrrOtp38CgEqnkcMbYmoqWRYeFRbd zSrYBwJRZNOKQGAmh+CrDxAOiU5uL6lHsF08wtrP/CGTKhhsoSxX/iRdJ+xCwn1RzbCnLlDoJFRO sXMwcQyKfXVoWzIfwvMCUqj+cerH3+pzyD/Ml0yj3XKFIZzNPyz/x+M9/haYQu1ctJtQJi2tuuaG fJZiu+PLzbVH3oOJ1w5G1v6iVGMUmwaW5OSs0NAohQOD+3nhkLUF+gF23tu+2dBYeteXeEZ+7BMc pkIe7vF+oL+m9mRRz5DF44E/TAwkmYJvoGfJQ2jTJ8+kgYxvUn38JiB/0x4DvncZtE44oOHVvPt7 t1rtBVTktHv2ezAL6suebsn+orhWx0Y5MQyD7V7HXaZpE1BFsxam/fEqoX+aFJmI+rAilPEhIqYk Mc22ry+MX6Be1iBdVk5Bn2DQve2AoHpPPED7+3ZqKVyUDvunGW4trNQxPpOHzjsdQcIIwp6wvqtj 54GjAJM1oufu/IO7VS9MxpPLSXUpBbE/y5Wf3s+nLzZ6n0+CE1YKLQ4vNoNfDxI3a42rbMzvlIkB sxnFGCh3rENK9svpc9YjzuViKAGc7Sv3RTtUdSd++b0V2KF9N8IEpQzV4eyur9YdH7Ap/WqMRA+O fn6XWdIR4hwNqZvyiCfkkUQE0tVKBkBdKJi9UWv7tNEGpfktlVsQaGAKq5U5G9p/s2mbKxmkhOsH lGGmYi2vRKEj/aHplqi4KZWyCqf3LxH4ArDzw4TqiU+AEr+JUQp1LLwIk62G0/idMlme1FYDbWwH zG/xWNFd8hTkUC07Tya2AMDrIC19aD6Fn0eZ+eoaBmS0gk1gr5YdscMn2iiR10KmJDjuboVeJZ89 uHltSi8fb7GdW8sJIx/Si6ET4C22dzBaEWQW0zHeSLK0Hrx1Xicd4FzEcOCuWJnANEFqSAmwCqAf NSUYt8rqkY8zlF/bZM3th5uhu31MWEQIJv4KBPZUTBc7KCYlJdlBFOq3NSTLNe1XFrl1fVOlFkA/ tlRKSTOluXAGPkfvJryLJQLBHslb6yR8puU46eUe9sPRPz1Hw0YifqhmFQtxK3K6tEHofK8lJ+2H zuN2bvhPE8YUB7+ydOsVnjUrc4hXnJMix9a/vl7Hf+A653elXjvZmvCUejSRTcv45umRlpknZ9iY clN66ca2Edw9W68xxyyG/qsvPlexqFlFBGEOp8Pj8/ZEgEKZC0HuYGNeDY77p6mXL7UL9m1GSxHj BFtVexFOlSAFinRdl3iBLhSqFoud0ONyuDA0Wu23AK2d73x9R+VbT7mPsZkNzbhwpV8d+su/brOP G5i6bXnJ+mVFWlZ2BFmp4NwjWUNgso4VrbkUHPSgKEZsOHwiS+oCdfZ5WU6U3Z+6Hh2fp9KoD3E0 iac+7XKT0tSpKvhf95TS/4U533NRHkOPqtIGx3uwTvlKxmUJulKYFF22aNNz1bLhyPesf+QII/KT zSn8axEFerf6ck9v6MvY02KVrM04VkKnZeMb94L5KUWr75wNxow4Ag/sC+im650b7WcvsSklmkjp fUno0EsDsvLLHzyHHLlKApaAr8XhSO+8A9wItlC+6SEiHKCZRUyI+qvlp3u2f+vh6/KJ4/S/HuZk +28e/q/G5L93JacGLs47MrjvJlU+jb8S8VDeMBispJdn6tPW43lWYFDvAc7wa60ICm3VEJ9DNP/Y tk3/NGH5zQAgD10Ii3pUmpQcVpzNhtB01+YzRYIJm813vcuuqLlSG4MGg/L+VPb4HaufQFFjdBKn OQYaRWq6n+F/JhxMMhsSe9/PGU7wqf2HkUc9YHxppDPuJqrS9NtXWL4zFjTtaGdfwS4O2YlYYpPf yAPHVlz6AuiyvWv2eG1YVJS6RTdBwQLkw1TBqZE3RKqlFike/TS5vZlD+uru497b4L0uAA8k4Exu 2LX3UkLqQTi7cjox0PHHLHbpvL3+/hXWyU/hR7HdodDofP5sPeubh8pow896ia4eycb7ub8Z9F/S bAhW/BIwtp8H/dCFQsrsaBzhr6XhIYWjhxxQnIO+Ts+luz86x91EBnBCfFH5qAp94wsao70eNYiL slF1W7ZvB+BXXf07Qzr1ewD1Ot24LmXOns8C3n5543rIzrko+Nd2TNQzeNhY62pOMIzWNna+2oTy yD4y6pU1oa4KQ77Bgdo83Lte8BopIzpzVdJ8+hqzBDSb1zPpWkZsgLIPs8shJ4JnXo8Qp2+/fwso jDYbVcBh+ILxSljYdlWF8oj4DrP4MWgZoQ1z8TSSwTThPQJyi+njqVydMuwyl2iZYYP9b3bZwTxo VzyM/tbD7sa+7aUIAlV2u3fps6sxuGG4WujejTSwIsLANP48WiiHk2mQQMJd9Dzz1V5xEsG1gasG CiDRS7z2EgoBGxUtnz5elcDsEsiPmRsiOcNEk4hAjd6AmkUsFFNWdJZvBvgDYFFXSLGSZvHDzmvJ /dTVrx8bZaU5BpukGQMxzstVyFPLOFm1+iCGsUCHm1Sl/EylAAq5LwxN9lWsMZxjWmrpTrgQ+lQn 0dqRQR0ySGQhTiy/FFxoUXQr1xDDPQhN+6FVm2KPedTyl2QGm28mXTLVQ2gs2XJqwnrY6x7XlM+B ypgrxvmAZ/740dQXn3Sec9RhdnKXXXRzqwa6MzDda+ToHUAc2q9SXha7a9nmslEprtUOJw6Xjj3z F9DkIQEhmFdprY20Apkw4UK/7c8tawCrSVIVWD2E+oeEnu2YklLfMwrOAbWIjGjCDmSme9soOYaP eEhiBqY8oIZL7qO2N81vqeofDJc6RZCxLAa9+YfPTjW8s9AP2EJRxCeNERfU4xSxUc3lm4beM/Z5 /uK/J6PXXDrybbifXlVmXFU+LZ18y98kQn37XKggLwmbTfebiGIo1W9KdEL78M37MswyKXe3aR1i kORucD7m0Kd+qffMjd7AlWCebRFknOhrNYPBncixiwx72OABHiCBRFf2hWfN19Pt6LUZ7mvlOJWu X5lA4tPsluZaUl6PS02Pd+H0RHg3pm1KSLLlpy6KspGkaRs3SnNLH/5cb/Yc8PswHyj6bFVT+/pX 6/O71uz5hM7xCFyKz7gagtf53NZVLA/vnuvXLiC5YEP+S2huNqgzscQAit7Xu/FN0cDX62nyLh48 5mrwF/MVKkTptwQQ/Pw7JpB2/hoTOsDaE65k9scQP0PUHrbMLF6cHqHEHBTDbWFuiBe35izfHqqW mP0oqw1liAbQhB9GXXLyYQ91+VTrxyjervgDiPi31kst3RgWHcv8GL/l0pFRT3xhUjeHZNFi268+ J8GetZBmSCxr7ItTqYNf44r7H2LWXUVmA+MqpzI4fe1AL+SOdPxdzdlj3793Gt1Ze4zWdHwrg9mn dpqWIN4kb2mSwDB810rbqqNGuiuvHvH4thu0npmcmgeDtNyNfl+0juZRDZwIeJOPVdJqhdhqn1QT bd0EaOe+Ug0JwwiN05IYi1nLnaH8MKyuh7WxGZVHz0bosPD5OJsoxhmhAwMBTB/IIwpjrsuPf8c5 zTTnZRDC8NqQ0w3twty/PbZ9I19NSktY6CL2VPl8gTfdFPHVIQZZKclLOLksTKONLzJSe/rF7V5R Ug4WilPI2zIE2IqJz4v/HZqgrazlRCNCh4qLwjnad+i6Jf+owxuBDZ9+615MK969eGKKwvCNUmFh qiOknz1igjzVnrY8iBxoTqzPMnCUNGkB9QpEcGTMbe7acnU15o3fh8ksOsp/vBs3VQjiJtWGBKGS pjrx0cWz/r0E3Wg8Gpu0NPTgPuM9fUNm/nYmvgLzUV9XY5qkRtTFHNROMb5/H4UHXWqc0fK9+vRs sa95Tau0C7XRmQT8aovunmhGJUHM0g4Pdq7u0Wrk0cMXWJeNtg6ARcH6aebH3HgKJkiqrvu1hdJc +/7WfQZXAKODmDQ01mC+p/+Rv5sgeqH8Fnoui95FLyoJnrkyZAGJBbkDofHcXvAibe5iFoVagrj2 HpklvbyBNoxtBEXEcFwinEsvj1jvrE1V+XsYSJj276AwyqQmscWZqUKooRpUSTqNV9oZWfseVcTU zy2/0q22t1qCa92qoMN/YqM/Cu5NWQlmvf212/LVn0XQGOHRkXE5FxCMeEOYl3hQLpYTS1Pj1M6Y IWg7Ax4Lby4LgxcfWdVAg623TyfnslWERyciu6NCh15NuXsycXX9Of+jgXPS3x0p+uCYwvxBdfO6 /Xz4r87/R9o3/v+V7ZstXn1BJCwAAMH8z98Y/tnLT+itue/IYH5S1X4zV/CzTg4PFwMtf19WIe9q c7gK6qNEk2ktUZSBCVEusw9mfsx9TREW/gnwzjWw+GYUBMWRcT5XoToN4fPrHaU1RNG2AXG4d/nU D0glp9np/IrPVW0nyAsZsJ+MTRtvxvxgw2x/8PpwUKBS3QE+ot0EM0+alVRairiDDXTd2g3pFZNv noz1o6E9YjX2jH5XdJ6Ux7xDrX09ffobmvtCzLnevQLWwV/1rKL5mFO1PyKvE6pLuKO93HHW2DvU CQwZlEmhAa3/fJLzN6RaNaDpRcoXmGDRckD1myJsogdmNYceEGZGh+cCDRjSsupqDGlh65gXe6vt ddYZWo7sP5XogVOSvVvmnOhXQfs2ISDfQ5HlIBvWK98WtceH8GGzMCcZ9JS2MlXHnaZlWzBX2GgQ l76JaDOPfr5oc6cDGaB/ivHamBvrVZB0M9Ijx44xsz22Wn+s6a5ZSWSplgGLPmIzPMOoro4jJmtC V3FRrWFU61t9Flfg8l3r9jz0OgfWY9D0CZFAaN8ZxjpCqZT6LgKhlVT80smzMy4x/SJ2Lld5jZ6L yrinYtrUVfzEFbU+WK2qnEwI3Jp/VCeVf9UFJsfk+HihJoPNtOXGhE/BoRVMxO+KVOCR+hAeBvUR dNK2Hu252Y7Y7IeqcAn1IUVTOKb4xi7Sf+JOCxld1snTXyhd/zrrKCWaa+4UpqFVbUIt6hhOprk+ HsNSA/cITTd3i8ygvPaSML8/NH4DUyLr8eI27KIc11k+gDeF3kJfARfmhlFOK3byJjVN7FSQgcR2 FflAPvTyi7NoKJ/StWP6LwKpw84NSnvgHO4KR2gmLw8FjtTUQhnjTK2c28+ZD3uePZ3f3eyTSEdg ZS2AxhmcimycjHZ1/MqDWkxt+9jHazNY4Z7WEc4y1H08CmLX3rHKTBinZvVXVnTe1cCfd/KdaD8p 4z5De1JALZF0URt9lzOH8XPB8DksmkiMWAuW7ghviiA53fbvHvmAOzyrmEwE1RVKjGgVyyvUJ3iJ kLbb/iVDrM33OaCrRxTQ7YLFFuJ4JYPgW1LoE/i1u5z874s+jcOKZokN7Us/FCkNuwZgul7Z/XPu ZChzUh8KY9l9RIqGqdq//VLWU72AOiwGsop9akDwHROmWA54i3Nwu8jnzTj2uHjUKmkVb4Hsuptf PO8blMgsz0hjAAeM5sqzzr97M7WpAturu2MnMQZOoMkE7zaCO4N2Ow/M5/kF0ejyKFG7p6w44wS6 b4IwVUIbRXNV3t1XebikKwXGB6W92zV2/MvINFYS56CShlrJn42nBwNiCE4fEXCbr5uN9WxbPNTB 869k9+ZQ3AzTk9MSNXTivQ0doQg5JRRcoKGbZH5/fZkncDJRJ2N/vc7jCxRb+Z/gj2y+GJFHslUc r2wCIxlpDV+Wsg8Dxa7zZPL67l6m7DBRBQm2rbBhU4vWPMLyAh1iugCd7zWrLqbvb3trS8EmYi3l Ic4bX67k2KZkYjQ+bS3creY6PzQA/CW+xBYhv6OLcUI8e8Mdl4NJhjb/bYgZaqCwYf0NsQGs/xxi /1yyOtVbd9/hwe25UNoU/20S8Brm2IezTEVza807insPhWuIfj4GZkaCXjua6NF55numEU5hlUBk nHHNyvkxUiByFHggO9z50MFEZKBBhWKClrsVdkFpUCbEXP0l5AbE4xaAnhKjRWTeVQxjo1x24/Zw o0rgRa1/H137KEG1VWklAT9lVCVwJZQ1ZSe/i2Ayh7yxZ5Qm1a96tQUKFYL2Ge2a+WPZQCO9B7kZ 5Ljxyydg7N45Ki5Nt5eDBUn1v+11VZaBahLNa+DSxSytRTdTDJbM6vx32//0Co5s/cCWgbZBLK/Q BBfFpLGzB+zaTjDDce2n19qEaqBVg3tj/A02kYC/rf3o1ZLtIr3Lf7eyGWQ+6kOhknflHWGAo2lq jNIGUFI+Y9tyu/aZO7wS0CWH1+Mq5PTf2nHlbZ73l9+cCNtOfwQILrMg99STxJpk4xh4WEdY4MKR 1BAzhFQV+D5pF8eE5a2+DHXdWtuNQiaze/JLdLyVF3ayM2QwYjMKq7AU6z76tS1Gbg4EA+Ww6Ra0 6oi4Q/va5KF3LxF2baRkuet+sWlGHWvEE9Fi3tX52vNZSz/hMSbY6jDcZslJw2kMfaxiZBMjg5uy Y7RLX8cSD1ozX7xPhtWJVF4j+275YftEwrs2yYmrSFBGQ+CAJUw53CVVOyjMkZLFhxKaSqgWw2RW Z7wVB8R3LNGTrYZisbk0LWNK4rp8cWv2S1zg1BVX5rXDktQ2Kw4Qn1NHF9BdvmStiJ8JoZKX8WBt 2AhedsCHc2oHXBKe9+841cIB2loQTlwsWQGND7Q8vm0IKABHT0QHqM/xGOZ/Z+uSen8HF5iL0IA1 0XAngMEJTx7EUomnXwkWNQfiZ+l9hMg5SlsA0k0V/6aY3SdMVVTBtacdSWis4Q3bPdqMc2hzI0E6 7Yy9A3uPZIrILep/0zE6UrLOwXjdfeoak9tav/1e7SCDw6d6Zu6649akuRT3PqFexBzvtywCvF9o JfyzgUKSi3gRwerH5pgjc9jdSDbbKN3WaIwlXeDlUI77/l69yNWfFUruVeECRPfv7sv7iXtwCVci Kvt2O1B/YSpr/OcYO9GIVDpEkPjum/OBwNAsoqxbsNDbuJ3gDaqStrQ8/eCAxMxaxNt+yAenCpig FUNJ56wg9X8uKLSw9qkecDhKt+T+WY6u86HLPeEJ+paTcKv+qPO+q8CF/mQpDltrFnACM3nHKCLQ QG1cM5KGRyTNG3sdJJvxQNrZ1wpQu0jf73sMjOHKuUR76djsPj+6JPMxPkUoCoh228yTKsEaKunZ vLqiCyxr6wpdzyNuFe15fx1PvHjPpbJWNrerR9xSN6XJVLPaAVa5ZJQHhNXgRFU0EVVvN8N6zs7Q R+03ZrANBP/bPCn94T3qAgcApJD85zzh/lfxsp5SrIPZo6q9EUK9VP+Z0j7emX8qM2clq+pQpA8r 4YP+FiafQLZW9X1ryvAKvbzPAAsg9N+A+sua+HBsXQxvzMPV7HrFc4mqx40bUcRqaIU+5U69cxC7 Z/xw/mXYQ1lNMDmGA6vxOE3sJ/yYTJ87vOnbxO6C4E55Af1D0cb0TEU0vp3agc4npbFSzQabjThZ lmdKbPKBYM1kGaXv07dl5xWneB0ljc5EMi3kTZSLsSdzTEuxR1yXD3mX+1iJIJWU6yT5RtEcOPny 5RQmR/kxYGFRTbtySg1sV3qDRRdpb0zF6EWnzJYnVIVyN8JbQMnMkgV+f3RIFDYYPivqqICFqCL3 A53JSzZdyS5/GQo5wXQV/oOcmlHlUqwoMuFrHBQ8wl3euCkuzglLhd38N3OyqMi20+NGW+aX8Fi9 L2xl+3v03ZP6LveegJPJc4zCk2N4s/6n8sYN+fPZHkGwuw3pSJLD/moN6djWT4TtT6MQvc8Fh0Hn +X861KwOgT/pgXWIwhp4HS+qMV++22BqIoONNpCDIxJUt3JUmlUyR5ONIhphXbsQlQ0Ai1ePt+1C kLK5LScidJVm9ExoikY9qgGBLbezG8RjypSwJGBlKvV8My8izEUsXcTQq5h9gR6dX7V8jEQk/C/A t/AyFga/U9GWtBAswwlCtMUQwbDYMQq+CZggodN4r2W3yQLJ/assxE+NfZ0/kM2EvOR0R2hbzWTx oUtaU1PafkuEaJpkqwxwTMJnQ0ZV1hrRWuB2QvlXHSHrdCuo5iPRI69CtFpS88gOLPfW0PMWKZpg 3QY9R1aLI5gFacxntS3fKJ+CCQrxwZEkIQLI6XS984rtkdRX/TE0AQhlALLEnjatjmUBXtUMOntL k7lTDo++WsSC41kLtXa/vYveZKQDD5ZRNDhpjUqsPnSRcbatFn/F9SOrOx5kEq0O1NoX7qMXawRX Z1jsdQa/t/11kVpXfG11htrmjlYQ03CXyXaNdrX8d4/DaFIspNQIp9TWF2eks9Vzdn1alw+XFLvD UXF7Sp3DsGpZ7Ae2vZfiiBz3lnoNOS69iEJjpw1LLj4nWBFVRIdRyVctKH8rlDSDY9zzDHwSKDtE 7DQcviMmhUf2gYiJbX4j1b5EhR+EBPiioDSmEEkLGWICmKVLpTWW0jjUQgN0Fj4R/R/uvjMoiqZt d5GcMwgIq+QkQaKIrAgSJUmOKyIZJMsCCys5SJAskgRckCSSUZC0BEEUkAwP7C6oZJglrrAsHz7v +c7581S97znfvzNVXd3T09VTV99XX3NPz3T3c+sPfzLNZcH9f6JYvr+jOd6/o+t/R/uXTApB/bma /tsLaSbqk3Td8eI2ocSisZzkNpFHUNrfUfGUNIG5RRvLZCc4SZ3qRk4j4nCSHNu+2TdxHp9VdutC tZd8j+OXfpQu5pUFencsFKb3rz63WQKvLnLR/AUOyLm7YO125V6+zc9h7pkmXtSlgBLWW9PVeVKi 6GbLzY0ZB/qTn55101M854MOtZXy28Z1WrXjvxtapJ3fZLrqz9VHeAs4z0TQO3UuntudNgvIFe7u wJ7yVHl2xQk0wZXaePLBzdCA7JZF2aFWxRKDLZlRzpYO6L4QHVNra5lLZ4XKRzCyfcewC/PD5aEu xA0BibWWN8w5vyE5I7PD2/o02PPYs2XlZXNE1/Y09/HYr0Pvijk+OuL082vVjO+Gry6jMM5FexUf JtPPtutBXvfXphtcpwxIy4HyT3Muz8Q++8894RaO/f02XJTsm9WXCcNjlk257DH1XUj0iJJWcUXN uLPAdwtmrtjI0ebBEPm5RFoD/qX8ViCH8i1j3K8Uv2GxEuuKOnf5hZ1w2olgzPRDLa+pJ97t9jwq Z53exwtaqPcz6/klq7JWwR7TEacno9LoTmJYZAHyZhCxhZIBl82ke+9lxKOhiShFJCBMd+PpnQoW 2DG5n/oaRdSVDXubXcg/Ds8P2kyBay68v+T/wPv7+yW+xsref16HKQJd9QmVdZR3NTGdTFyDxikM eiWf5gcoWt6qKjnC4sLj96z2r11c+SG4zucOuglLYf/0jOk2+n4w4ixI33I3OPGqrUOWX04q/Wah O1MRhfXlCiOnlYm9d0ryOmLW3DfSkXCvrRD3jmICccF8J5e/w/XUS4D64Rvk6ICWoPPO8akzEy4m e7ehoAJAq0iwCGNdcZOMtEfk71nHWw0mtkUkDVNCw/2GTrw+pZJGZJLnx1Q0XBJre8jyDarl5+DR RGBp6sAIdb+d+iowFM6w9Mvv/V9cmnnstm2OXKyAqlXCizeSkTz7yi/yozKl65M/J/+EMTib/voS FdBk2Irg+M1fzOmxjnrq8EJZ8y1379oMYtJlw5XGxXcc0ULQFZBFtEplDLHvX+N/rKR41S+MEHNv ZPWWbtSGi28Hj2aaq1f02lFyENQHJKLsRXNzVCIt4ung9I6kk5hyPYODeTldzpJrz2rGGy584o7l DjmjLX2cmgCcL12cwFLi0b5hxM7oDa16uRHNx+8YIrDAd8mnJ0CFLCdvtHR5rEQfK9wzq/xukz7O gzWFLN9s7IN08Ix12+CLdxieG4Pfrw4/q5Sw64GbDMf+RftZzs4nllyE/76quhj1Q5J9jU4iVetw nRMpnsH2XdMqZZiOPyvl3RE4FRm8+0HPe5aQ+dOmZ3r3f9z3pQCa9f1vsPoBeZ+TAZmcH6QSQtIJ NFcmrxfQjSPnNdT35Asao7AlhumynCPxhT3B2400pL9Wfr5hDPwexDVCTgvLSmRicHRKeG0VGGVr AhIfe+ZPIuXZ2yQQ5TlXtGqmOzE1jiFplhT8gtSEyZ5SS+yYKwy4U32Pyn05PPWL5MC0VgXbB9Ix 2bVqpPTGftfiNzeexI0l2UW5gm+/Vffo6GH2eWxyj/gcGGtYpsBc00nRToNNdze+75O6dZWjh4TJ xOPOKpkv1dQCw5/kMRWVB4jSK+iuZiXJJ9Y7aVUjzb5cJh7dWGamcSkjPYG4hAekqYYg+0HPPDbN m3W6ix6UU/P1faGq7KkkN35YxpIecpOxxig9emTvmZAhOKWRlTZrxzlsX4v/SF7gLfwNZHNvSiL1 ess1fg1WG/3mRK2TYpfSSYwdZUhmnFUKdz+D2UQJMs6K3uDuC+66P4mPT19fK0sVehM5ExklD6gw vaBwoDwZ7968o8YNk66mZEq8w3ozWSrJYlvkChu9AiYrhbriK9uKm9BHxwylrISnJZolBN34mirq UmIBOz8SEcow0eiqITXJqCD2DmtNVixCVPQelffhrQsOMKi4vaFs4aPCG/Kpp1a/UCzor3GvozST tOlrbeIrMeh+IwC/15ZOYfF7c/2ZZFXtz74dW2FVhPXBZYQyTWnggohdYWG7JGruqMn0beSO5a1+ Gw7zKOL8+0tPx/Z/SZCu2vpPemuq8qbHJmgY8ikObVjb/SUFox09BoUrytcdjLfG/LoD/RKovbTN tH5rP3SyaWtJAVm2VChX+ECFN480k2/NtnRVrGCntuaMuI2GdCJO60i/VQ043F5BCXWyGGs8F1V7 T/CrnqRfigQVu2xYMPjcvirlFiqvTnfG4bz3j6OWk29167YvpI6X5d9LnfK/Ruu++C9rsS1WiJ+P IWu4JkOjhmVi6wtTBp+S/yLlrqzPcr/Nr0AnmF31u/ZHwC99fx99+ihHCsewdHoqv5OD8KKF71On BuKfX+WaZ7gKRHfK0fc2yqRlbIU8hhegDykoKgW/8AvvJaclX69LPl658ErFo/Q0j73y6wRJUmto Zj8nICWjIrponIoaNuwdADqi7S/nYUGCZPGpyZAaabD4SY576FmWUN54jXR7zWjuF8EfSiFteiHC nhkZtMI9RHHDJL1GdvvZpAzLO2UW4FeCreSwfOmIYh+60oc/uZ8YO9EVxcsxpycjfZ1eubJc/ryq OfB4mKZJw7HqkYN/6prXmaf1SFLFg+vhVpBswcQXVSUyJ1/B9PfPRkAUnGdlP0dfJZLnO+el1lmB mK/lp5MkLiyLSD4iQeuwTCuhzhZlIlQj6VcWWNc6l0CSs940N6U90jqDBr/vjLCKKZfcqvMQjUYe h+Ar+a0ZIkpPm8OwKJvMklEdaN8bhi7NKgrL88rlElx2UqViICf14GFJi5myJFpxsezlbPnN95Xe TMl0yKKpq/N8MyP3rirNhDT1J0hheFgGG2S+lRhzBhXcE3L1l7j6VZLJU73nam+fXGDGM/6H6n25 XT21G6PpJMKRBrTbeAbGm3GbHIyaL8mZKPHPkFGOAns1x34UKS+HKzF0azzFP2DiGQBr+k2sCf8Q pYWuAwu7kpvte7q5C4kz2ZMMfSSkUTY/8pKGo/sbE3Rbzm56jhjx7VpCvD0gaPV5xU7zYczhRxod /rdQe8HFTJ/2zufU/S7K2eG5D2gSVE53upvFsu5uRywaD29/ZAgSDDwy92w2nXpDEJ1QtIAazF3q Rk5NeraLU3jXUICm1SKD5q3oQTUBl55PtTSqk4I2i1AeoIefAv5kIhiqSZ7xFvzJiF99r4AxY+zR u0TX7hLibFRSXpVTxRBatcMzpQqUtJrFhqnzjMJeujIzw7/eowydsuUcG115s/XtHffypaN2uHnv waZHR3RsCHV4g+oQg9OOwdTIuIfioFkr8j452UAnn7k0t4uy+p1eR7a++5L0yqTPuis1q0riMsqk XKqWTeC46bRyniCv3OnwTvBvypWvuLjJA4frvoLOPz+pPBK0Jqvg7dCc4KimVGar8mqRT+FbY/um 2XdXpLRDwSxUK3j51tiEQIoXPm6yx15XpJPUW/X7eFzavNrhRxYGxOvmVz4P6Y03bnHBuoPfDNIX O9N3d+QCvO4tv/Z5FVqkWnd1ZnjUBDcLXpAi0pqg+yHvzhvgBMgv0sAWNYO3pBR8AV2Id/7NLIsy Q4xZOu6rntmiGeg1plojWnyT34OE14PHfAWqjGLsxq4zQqpXsKTfoOU/83/Vbh4/eVeoO+pnP59/ Py5itPPwSvBy25KvytmC27cT5jbxzCy00Gh1BuTdmwcv97UfjrE1N1+xDffoJb0WdETKdl99O2Th JnZ966+fN4taFjJ7++eO5gmSztYia2nsEo7xLhZjchVYff+DFmZckKYLf6JyiBXyeVkbzIeZE4YF TYpoBLikOrC8sv/d++PKSSupJLoSHXDf4/Adr+tse4AI62AencFC4NOftiWrXFbxh091pyLO9kal oV2EUwqF6hhkxDooF596N7tUFPJ+2a82TqYjKzL0VZUteUdcZNvVQEZ1hjMbV8I/z3tuH+Q+L78E AvVS/HutVPrXCgDjT/410QDxvmNVnppMlNmYnCZs3UZ+nrHN4ArLVL3cgsysfGVXc7hh1+MZBvfW d5kqKZy+T3Zud64WeLoGtlQrz91A6osNyKtSizryZ1uLTTuFBnwCDMXGKTQp7GgUy8PK1+d+bOeb 8HoW2Xc7PKFTpytxujzR+1LlKLyQo+ZSOL+nMGAvZU5OAZ6aH2WDa20lnRZeXTtlz4ri25jy3HAu yhW7lbte/qhX/mqSn8xsl9SwTavboeeYR798b9sG2vbGKffckj9TcFabfHP/HR2Rz6r2uGSqtzIy QVyKbzc9+1/aJ26HmddtIP0/5C4g+Z1dPBkVJiEdym8+aEe6twHF2XW2ggnBH6qEBRJMLjXwmAZ6 +CDqqR61yAl6R62byl9/5/DZ4Plv2rmIdpKnQFul85TMSaZhBTKAIS5dKD6LPcP1fjqQ/tCUPMH/ 2sQtgxjNYYvEOPfQD95+18PbTe1faJ2MYDDh6qyRq2yHGv4lAptsDUNPxqc9sxbW3Z6a5m3XCrfi d6OYArwtXEbzJmi41AvKoqez6tRdmcj2l7pvFWslch6GluQKoiJnCo/LHFgOT1BzWzze+Xerymtm S+182NrnL1+hTGDnTnZ6RhlHvesSG27pMsCFiVSZnZCnrM8LJMh0V9KXMdM8eRHj2W8t2iAkisfT jYiTyx4lB9o+afOC/26/tThdGJtFcfv3VPE3WcJQigfdSRNJ7K0mvuYlxThirvbW2yTNWn4JB5dk uydVC64fA9NKaJeSqM5K5Q2DKz7jBpToTlA9hMnUXS/MPfVZXLmJ/AHHJ8HE0seXA6PX/ODNzlLv 2xGF8/Gnu7t8O4grji6La4qcQlLb9zZ27r5TuxPe3G9KLxtx07fIRcpspXXZ11IVaZV8tCD3m/qf SE7R6JQ2fUFyNqp/T3LFfyK5oDH/az2xLST5Bcl9/8ym2RpRpFM02PDxLp6QnmvObLKf0S3M4fTd CkvbvXk8y1fMqxd3ZFZ1F6A+MlJNFjXStAG2ydB20gWmyVnCqkL3fVV6tKuAuYOzdj92sRyHjLJZ d7LLdvceRwXUVn8OMs+YyHjLamLC4Jn3QmgcEGt9Ij7E2S2Vt7DfEWmbEbUiDO0Ugj62Th+jTd/S Gw6i5xcT4N6wDDGp5KgNpbURqrx0Of8sTPfEisTW3k3LsoBXtqHEnzFTrejS6WPUgz5datYZYZo5 mcbSKk/dSi7cmba1d1VzE/WXM5tSfgWQAf/T/FjhkQh/qujIU/7wBf70tRdD/irCzG6RDKx012+9 gurwM992y5rMHJrwyqhzSDTY+y0x/qSdxOyC6o7mchdUr0OabmIgDVUa1G8ckn4YXpN6VlECndDP OeUY8VUEzFOLqNF9U88t0hQdIsstJMOVOdfHmbpiEbd0+csPtMBczVF35gQv+eJJfnPJdpb/9WHu WZ3+baesZ7s8uIPAgaQfDO6RbjZugfeyylmsObvFQJ9l35aV3KQX/Ln+SmdvnbwBq80/y5X0RCLG 8ToWHbvVeteByWD8VXrMryiksXodrYEpfVZXb/1VSdRDTd9En0RbdwNSov4K3bdov2OlOqWDjhDl QKlv0bPUvWPByzD5wJN9daYBdeXLX13QfhNrbG83St88f9SeGdg8gfeuraJ/+Go8IJxxhwQC26DP emT8cdtw7KnrtRi//n3iQfuaUbnz4uvRW/yO8S3a2yHrmCuB1Tqz4g2O9/TG/S2XOseE1u5ywlxB J+buWx/WZjs7lS7Tr1YMdDaWsMIiRm8yRqU3Uq0oUy2nzxxHaZ+Kowo0gs43LnoFGHzRK55irMPq J6UZ6L42PgazC9fpNM8v5DMuPQImRgzNgRPF413ThB436P76P/+v93//bV/h/6Nv+zT/a2nma6BE CZaCv7fhevavHdMe+zgZ+/v4BkgHugV5P3ri6O4l5eHr7Ho+e44BMelp6WqBSEhIQA//7Bx2vgDS +HP2Pzr+VPI/rYPkvBvETAXqJgGRkvCDLjGTkDKTnPf9WdCHhPxfBf57KWqSS6Rk5BSUVNQ0tBcF mv9snUVKeomMlJyc7OKNiST84jqIjJmc5ZqsOgWriSMlvx/bjcj0EiqBu/U97A/GAUG5R/5R1DQc nJe5uIWERUTFxOUVFJWUb6poaN7T0tbR1TM1M7ewtLK2cXrs7OLq5u4REBj0NBgWEhodExsXn5CY lJGZlZ2T+zLvVWnZG2R5xdvKqobGpuaW1rYPH3tRff0Dg5+Hhr9PTE5Nz8zOzWOXV378/LW6tr6B 29s/ODw6xv8++YPrD87/Pv4RF/MFrktkZKRklH9wkVwK/lOAmYz8miwFi7oJpaMfK/+NSCq2u+kl 9T3UAnIPAPZH/uM0HILyWCHcH2h/I/vPgEX9PyH738D+D655EB0pyYXxSJlBEBCRKFqaBPqPQl1v HgTzAUotpSYT8RVBIw9mgIvh6Ae3SQGlFct+2i/tjPNKRrZdJLAVTHxchMgmURbvVL0EQXHgnSqk Y+oiePpL4cY4cF9a0jmIVsEobnv56y27DsCwEYtmxC+YAVM+0WAACp1rX95NIogB8Rp4U5znMuOg gSfmHBSpJu0RAT4r3g7c5SWI5aAGZvikWdyhjJ3X4e4+c+XnoGUq4Fch5vSTw649hKFDrhTf8O2k P4LLDr8ToOq7osGszWxEb5NipZcjO+QorqdXIKuaLTdszktt9sPcSRdY8lOZiPYt0aDXZrUwRq3s nbRV1xnCPKaAw1KsLW08rOberQC9VF6Es02tg6Ez1XDINPQup/tk32RdbFSOCGkaMu4MXdpFr+p4 DiI/OMvoBG9AmtiWRADLfi4CD6CEuZ27LVsOK0NxnoOoD3lNl1t7aj1m7qox4qRRo/FEfnw2FsyD f4MnHtu1tAOLu9FNCE7Yrd4Ihkm4yPJuaqcsXpozpUMJuRQucKqO6NHvuAW4Yme22nHxKCgV3ARH i72oH9g1wedxNAZU62Lpw7DouF2CAkA8xf4cTeyQVL257PklocNyhTHJgRywTHBp+RgLpzyrV0rc nTAfO6g1tLVvPjucSJvCKXvxXdNV1osT4Uwb2etQ4MZlPECqtBHy5VH9ZiZ6VuITmWaTrpLOD5h/ GOodyhzWm30/LryvBpYe3reZEnu7OGm2R9gU72umHULxxiebFhRwrk+xE/bg985B0VkQR3Q8sPnx JaA9wMjk5kDzEV+olPLkIMXnKLRzhvUOPhiTEtCfE0wkBxzScDPWONfUIDQ72sqNyDfZISr/idQY T/vWUxh11Nh2VqxqypeGhTCdRZ9qnYN6zNX44NTPidSoOiv8jesBPQjABMFLuA1URDUzXoal9RHJ cD7xkmpCKGBvH9U1F8E4rnYZrt2C006Jy8WRK+QXU8Fy+85BdAfBDcBSa8X6ktKkqmkwto5+8yf4 KMHRw+Tsh2z23n1FPpN5c3waT+KXPR3DoyMItB8ra1ap19oYw07T7KmXfVkl1iIDNV0XXxsa9H4W PsruUJD5Kw4sjDIecAkKNNC7rColQu9QIZAZWD2exTalAz30SBJ97XiPzZjkHwJlIRwKgPB1QO5y Wu9ENeJhWiKUocMbQ/ouPDIIuuW4Aqb3iOBVaT2ytZ+VQp4VnpUdjb5XOMxYCoG4Kj3t1bgRYeJe DGh7M/Z23rhoORjP0bNJgjSwgunMBqrvT0dwriMoiDx4IxSarQvLhmDswT1Y7Xe4gtfqoulksYYM 0LNifbrtSbdOoL1UWx2kjsBKn4hGS2fuMu+KG6TmHMRGEEGsoOMgzB30SI9GN5XiFFXK5QuCr3/8 2dx3lMutcA5KIEDeuh2F1nA+rTpWbHSf4Uxfuuf3JE1VmmaIpinpNdEAn0mk/nBqB6vQmtgKrMOL QpLVGLRF+qvTEpVCIaiXXe6eU8Bo7LuO29jbPDp4XSyvccSsGgPg74Zg8JJHMMEgvfTeQBgKStlx D+vD3JoMDz9V8iwGH3wSWVErjpXysKqxhxlnZFlom5slY0WXVzXYX2GzabIkDNmqHnRjGlW/sFsk l0HpU8yneXipzKwDKmvNubMaTvyrOSokjxkh/n5F9trM8UO4G33ikyXiLSO4EBdSMqSeSb9jDneQ qFY5d8ujsp9EpnNQlCrxewQjrityt0PpQgSEcT69ddEqDO24Cmtc2tbmqQKcDUe5tY8B8w3h0gZP wMm70s0+rDDto5ROfGEVftOgcfzX93edMnANXF1f8fP5nJIaj5OBwpU0hrkNm9TIsM2TOgKr9FFK 5op2LPGGGwQw3k38+LSkhKCKjweWzkFGU/CbONMH+cbvP6X1q1h2o1kVjhJPDfAPBvscRPFi2EVb LaUTy/5F2mV0b3FSMZMgPhoX0NdFG7iboCYH7NQDu3IYaQLLOegoGR9waofXPnqL7zqFoeHez/Wn m4svw6qx3l2956BkNVIgtXIlXBt7DuqTjpueX40LPO1aoBzsZGmMmuglyo/Lwyj7oaQELxwkXl4a 5KbCiWLkJChOHI7yVCRJRAyhAf2u+dwj97PXRDaC3hQEUw5mh4cDrNgYCFct41Y2ZVQHAkmQxinU 9W2z3puAq8znlK2g5/WXtw+bli5Nyet0mCDXW+bDYNJ3p3yCwm9hjqM7afG21lOE2wh96vjnX3yp hx4CXC5BuVhcYJXlc5Rxr/nAoGTJA7tJ3OzHuU/iE9XRgxZHbTXlsLYHdbZ0ld+QV1wT6r7kPWKX Cp3demqa1uf4c4ulb6ZPn9YSvPXo9/tZLzVbW/qYImnpikM4hbsqnfhESUIRmHb7tvKF9CgSBfH5 R5xnhV2P0cngFp8L452DOIgk+IYvg6tHLTjLuLonRCEYarCIM3r5CpoBbomo8IQwETQQZ0hMuE9/ EcfkeIf+ihE3olffExM0TtCZOSri7wyD5nVciCZZ9Nm7w0935yWM8OJGaQfFlGsnx6jbnr1F9PHY 1UHtMcL1AKCwxhVwqC+HOaCPFurxDgpo+pa0knUbSDwa+xrPjkCucxRdx52DukfBhNAkcKrMydY5 CDBiXIAanGUdGs2dg3Qv6JuCP+4rZoUbnVrjJ1bszkFN0olpg4ucfWCGCDr88ERfwBycDXhS/Jo4 YYlg6TBFwm9NHfLKdlCXw4pXBvKxiqnf+wnmpfj4u+NSqpzLqRznICK1+qmxG4TusCvyHERxDsKU IXjUOPE8UHzAMo8tglN9GZJiU5fYQY6zX8AuFWM/OXWrkEGvNH0yQnUxvpl40uXGCzUDlGLUJPCc KBvhrhVwrMUSJzDVmQeUaXs8hVW93JgqXTMfFTGSGZkS+8hEnO5xvqkVdM9/7EjedzhHwXLIzUlG tkIvpMVE/UHM+8uvlIfNuQPXvkijBvTMbnw06cHUsyZXG+ZYNf61ct3u+6vKxD6VWVWzxsGYfr1a XWfrHAHG1Gw6exorSaNOowtL/MA3X6gbXqS4FzELXd7dXsRVDxKlgYiS11C43lktJ0qFrYunU5SR AtZqedHcUSNGOCVL/IeKNZuc9OU1NbDC0aflEKKgp01FfAdXWAUqpNyTeLUJ5xrXZQyHeNbMrqkI 5SY0e3qH9XG80sr3fLfZYmN5xF7UXLMwh+KoqLZxK34yBanfbuaZLNqjlzg1MiGOJj1uOg1CZx4l Qki9IJiU4mbn3F5oPJSy7OL2pQTNeuA4miiB3+0nXm8b76DF7S0xJkFpVJ2BnQs2KCIaj5NUaWuJ f/Hx47WRBBWgz6ag1SYoPrbzAAEg/t/K2rzB3jofeCoIymgP18kfvLB4+OkitpCHyIxmgCFQ5yD3 U9cjjkSkG9pzL2L0qG7rC22YdNNZ8dfiz/uENKWh/fK9Vq/9xwsdB1VTEjVfmO0nkFCel1i/Zrcq 3wg0K1SiRPKpeFpDBbcytzJcw/rxezzC6Urge9/+L/TcZu8z4OMV3JC5LPcHb9cdfS9v8edXbceV achlychL3DTLthvolGOoeGna/4jdpo3uttXDwiCLd/yxvB9FSxtULiWJioCKYFwYFtgBqWDxQ+rb lYoZ3k0Zlt5rGbYtJ4KUK8EpCEwLpNGyF02LH7TH52G6eNZU0p4doGNU0hLgEOeVrrlhXgNB/Fy5 Z6cYUJTrXQ6/g8cC6L6j1hY1mrF3Cre1H+BE4uA3sWAO2OKTTgoCG067fze15QH8Zua3C181Ch8x wieAv+hkrRhO1Cg5Prf/pKu/+DJBHh9WttmKYIqghz0YvYPrSiIEXxSngt8BihMlg4r5zspXByA0 V3Hfnp81Aqju7zD0imLJchj4snsA/Ma4Kg8GzA3XGmtDx6IBX84tDjXhfkDkPt4dJ4H9VRzwFu6C 43teC4Pq4NWXGeNfcV5YKfZjcDTcD2e6jOj7MhrXxXwYLoCFA3awlYEiCZxRlDTY4gL+KSMZvhSR vMSFD8JJmzfgQwIm8blEBtKzLCKPW9cVBehzBG2EMkxxH6M9gI4rJiWYYr2FIljx7YMGy5DnRLF8 TeDxBEGlBV+CJGh9l2xa5BOegbsvp+j3MhOup5k1znTywmXxeTinZcu4w2IaW8nm09A59h/1wKB5 qkqhqHS1vlL3L65YukapnoGKT4fmdAMKez9FB5Q/tn0stqzc2sRWcNX0nNLcfHPYE25R4L8xUU0c 29v6Qh6b6pfW/708W8wypuFl1WzCZKoAdSxqWcwyRUevk0u/IZdIW3J6fQ3cnN26BV2pIyWYf4+Q 84Q2d0AaoLHoHlQ3mKVDIKR2kzNCthUYTYHbIrAXj6jETq713Ipe/uu2vWqqQOpzHMXMKUITJx0H l1uBxO5/xfGBvX3wEpCtby3o1sOh8c5rg2ACa/yyUrQaFyH4Q0c7/hbSLbSlfqXs4Sutakwal8c5 iPPgHHRpARZs9OpE34djA8KmagQM+5DbrYeOqEk2jKPvf6CdxM8QaVwBpR50y5PMUxrUBS8Sl6Tw c9WMVEyqskq95N/l+3Dm5bk1X8Nq3Ygi+HZsXaKNRSwWTeupyCf0CeeNRk0CiMTvtwN6LxT3HMRH 0AUQyQRm7C7VGbILU64C7t12XQZHEq8SR04QKXAxALrC+Awuh9s5tcb1Z/+KxUAoNl+1JquJwrSX v8ZlhgBoqxac83EskZwg+ensv7gy76gmsv/9Z9dVpCu9CNkVEaUFVEQxklUWUZDeQcgii5QsRpYW NCQuLUjLZ0VBkbIKGCkh0lcIBAiBVUSQKqAkk1ioZkYxzpLCL37//P0x58yZOefOvXPf7+d5Pec+ sKMq/rupUwdcW0JjAOnh4KnL1klCHfuTx10J5kcW96M08/r5oB7x6WThHvPnIDX7U937Y7lTeNUz R1r9y/zoFHouG8BN8383MtA+GPHpKjZspvGCbVAZVGuWxQ5gX2o/BJ8hlGNFRw8mWDvqxWncl03m 0Sz3XdGKjbwCh0zH+AIrq5oGr57PJ9vAWDUy7x8kQhIFnPQcqtwLm0Cf+8ONu9qmmU7grH8MSQsu 9oDpvDcYT4h2g9W2oVxhxv9jBFgnu4NmbPV8x8OQx58CHFZteZP0F3hvuLNSB7Iv3CBITOmEbjZa YQuhsJ/E6bWC7fnCws0qNiu/C5UlMYMMeazr+yct0f7io7hF+38wbTrd0gpQ4OtJiYeEZyHphgGp +OTDZoHUl22sC2H+PNL9CB0IyNPdSfh+E/E4TIkHqBOMTGz7dspwmJkIC9EKe3cs92rIE7Gck1lt ChSmWVQDgeIGeebKtAj5QFTn4Pr2ZByu0GWga8d9fD2B3ReuDx2t4vv+zYlNBs5JTmEyH3ZDRwvT rtHdvlZcVVJXL8Rpu14u1H/3uC4T/2qmQ/tlcE0c//hv08QhG/raOyWtunfTDZ17HPdqRTp/8ivt HJjOUWNGBE8/f217syDBXLPO8oKNX6SHWqHBnQtdyTbPsNpEok0hMx7T+KyGSOHpcrBwOGYHaQ8x TNa/hcjCynTUs9fQcnrY+VVEE3FFLguZVc1kHDk6Fon/1EEeHhPFl0i2EI/OJ65OeQdZzIW9WQhs 514zUptNCQh8iY+aB5y1fHd5O2sh/r/ruw8sXUtrO2w2RjOp2zNXAbBbrAbFQylHudrbQu7DsQmp wKjrIhIp7O2ZtCyW7Vreh92N755qE0cZpCwLGwWqCchPo6BJPxvwLLLDaxBSZUpccbJsXN4anspz BNJkX1WLcE1RzulH5BiqMHdhlazDDBZU5VWeBBkczA8Elqh+Gu3NR+aSNOBMwZgiHM1n3JBZSH6G SvIFN4i2kImX3OIHz8n0CLj+TfxHR1bNMrb967ovhAFog8qEduzcpOhIKfCGlksy4v77iRApBwYz AXdnjJwN1z467l/eL0fbczzqn1wV9Cm5t4SrgylPjKuBNzi++mA3VQ/OPOPwDbcpV28ZLyeLL5M4 XfHPZ3RZ7bNrrIjUaJPQ18FhxHTYG5eIs3TBnbJrW7QsCtpXUEg3fNCyO+NBZ39Es6dWM8HScW/H 3oIlP9Kz2+fdT0xU34l4VA+TQu5cbZMWxRZl0sJvLU8n36o/k3j/tF8zZ5bNPDQgsPChnQ5fuO1R Y/P5chvob/5PYEHdzHufPiAtyqB86kH9wL0s26A7MzICSZsQOYhV+siKbrAyEYnkxtcQAqN4peu+ qdACx1hjnMUrxIDB+cqYQrJiqKu7ibO0jBlFIxQPyA6DZtlMZaDQMVSKOk8BaNfRSJ5VwIz7CY7x IdibL88/RK62nXp9r57kwkuimThc7qYiKvR1fbd8z9zgfHBy0EF4w461g/TiipzBD5J57Yv6oGd2 zTRvqm1U42TKhFCeT/JkBoQMlCIB701lX718A8BkklXRqvWquk4QN5ep30CMDEvlp+ZiQjFAF/ki ZhONn8NuITQ0AbMthN0UmZ0kGyRvELgtLNk+swFPGa4h7rhHFKXm0cRIwkpZzdKjMcUb9dJi9m93 nD0rG83s9caBtfu+HtjuOkpDeJUVMcXxoYU5LNmx1z860DDrVoO/aHpPwpHYxWpO9LGnc77lWj8F dO66NE53VTrSACRogXb30Trq2yhsEoLQDaDWZvknXdhdM6WQpkzpIFCI7zc+Cb0ZZktD5TCaYSFf te9DJujSJ49m1+TdqNzo+N2SzzkxehBallO2Ng4KBWR/8Y+H8TshJKdbiIyV6U4ssEtI+lOkj7CJ 2I24HbZokui2TUgsxIlhBAveh7X7gHDuxb7H8uHPkvsD29yEmivGe6bRlpuOrRjKXun/8ElWhmdA WTFw79WGxalHqwbZjYuomcYHT9pbO9PayS+R8OWqV1QZ1VAUKG+OLFiuDKPJSPANphkpNbZfY8g9 TREs3kKUrTQ6Bt4FahW9R5qhW5fqn/kMXDRzmNY5dQN4NDXoX3Hcf9DjeIC9pvHV1nJa4SA/0aEo rQilfaMxYJhnu6vcXGCT6JvtcE56MSOpzvfF4/82a89Metd6BJfoZAf7ZniJ/Oq8CiLP5BhrEatl xsFihy3Ey+NS1hYC8mWBflxZ5lUM8K6qlSHVrFrYQmwhtE/Ii8p9C7Fkz5DPO2dZmiu/h1hRZMlZ z6wqyaz3FkJ1UiyvvJcC0jN5AvhflSLmv6ZqMerwFuJ+CmYLoWiLlDBG04EvEnXpDgADPqRuIfan uUjQbFFM/ocptIn48pJOpvRyA58F79eVaHUPOGg3o890lsl/yBbitwoT55bYtxbbW95wB2YDfZxi L5s+KTtQtcLNQhqSNIgkMCkcA9tCynI50EDv3cz+SHVkAIUeFkDtaldo49VOit0q6s2KoxF0lGpR 4zCW82X15ImwCbOIHbW0+ecpgXdCZPJlNsd/ea6Tgm0XrvWkpSaaO8XjcJAYcOaMDk7YBAEZO5lB n0YsmpX+GmpcG9z+QxmIX/A9O06OXlcIk5dDPtG+9fFLZgRowQYJXFFGlZNidAT0WRQI0gsmJe7g V+o85+bCYBlrQIg410j0hy34hc7WyXglQmu/SKbbPL0hRBA+89VK6Z9nBvhXXrOC2LPsz9ziBe86 t7IZFqqtII2efC18NvCNoc+gF2N0DedDH7mMj/LRPo6/lvjHuXlRSq8oemma6Ayd4FOGsHlbCD2J r9hO9lxmCo6xr7FySEhwiAWtCrg3JDboVMx1FDNRdYjGw+RgVB2RbxaXDVA3SD/BFLZI19ESwtxA +9c9BcgUR23Wt3ocQAkqsEMvFwiB6/OSLLC0UOLGwxvIOyy4nazILbTgkPbKf0KZ7F/u9g2Mxkn6 w/uJQBDpCImDAV3Vs21wJUfnb+mm6B4inF7llzTz103OT1mhkqJnmP+h2hZeoYTrH2eMC5q1lyJ4 fFp4u4PNH115t4OHdv/Rgr993GLOPr74qlp70MvagLbJhFqP5N8eFBcXHnvy1PlocYrH0zbGtPF/ WwiVVPFZd/FCFWwuXOduH2QxK43MAKpEc8esa070f7X55zumybwKg/e0eNrQu5vPVF1CZ1BAx+7h tPoVXWXT18MSW9a6tjzpX/zWB+Br+dosWZshyS8l56T3ZDqwMsClkvauGttJa78sMLYTUBxj297S IGkvOVaYY3Dm4aLhuLC9lOo3Uw2vAsgc2fbJJp2Rpz2zlxvbUMpLR0f319XdCzXE1VH4tH4qfJCy ZgalcuQk5nQfjpQpbYcUBA/bQXJflW47Rl02toXo2EKslwpY2YdeEeYFHL67BfCVwyjEtNmvTZKh HwiJHmD6IiO1qYoSrv+SGBydfpGl0kRMPV55LKmgJTUMqIzIL0y2RKeZXmf3ewSVO8bmUVpuX3hR 1qAHtFx40ZN2elXZTd0jiBXxpdGcfqsywoA0B9gsjsxdbHhiGRX7h0//zMiVLx/8nb7DRMX91xvm WnbPo+e8UxFy4ZqKU+23TlfBi53JE0Es/BZCYo8B3VCykgp5hW0h2gKlpvmib6rBTtxC/NCyhViO nX2LLcDwarmgh9yvN6nr2+1v8KS90SC+j3tdhG0busunqpC4yLb91fXEANiOHrLk0i8zhdNAuUhi O1KziHh+sUD85o95ITu1V+2lJIwnVIRPeINV+b0O8DCPGX4UXCxN25gdVC/itgxfT0JtIwBoWzEJ Huur0iB9LzGBvwL66IPiRNl0QPgJsrok6CXpIKHHym5sp+SUtIGocD/mKYDZRrSYljg3eaCT0+vD LrxWVXYGZdXp2t3cZYO03+q7LHSp/gHmegcH0uJ3ulZa115YyUaf9EdPOA7Vur4+XjFBM2CWfx5Z GbJPrF3f628rr9ZWdoSRwzGXons5h5jcaRM3E4b5BqDS69uw04t/Ia9Neiv6gM/zGL+bXv5hmBZr cgS3KLCs8i497JtzYS4v0KOd870yXaabSNrkfnOzqY07yb91Uv0o51mlMsXy2YDdcediY8qyUloG S2/gLnd+f0olIokFFG4hYhibbrrr37Yg54NMMWoLMTHJYKPU5MNGbiF4ZV2LrTWhYTBGphRYS0gd wmh9QWWx1L4syd/9TToE6TD4o/hfJh33LcbJfmTC8QAWPiBrhU4MkBQNSgek+J8niN58dcXQoBWD pvvVp5KOdJRJk4TR0FeJVoNMcQRslcdCCD8YZiIfH0iB4wVjWVwVIlae1+D4sYJwUzj/IYHL/1r0 hbstVkedh9wun9fPEjc+GXZpOwysuwwaMAZLJwVwcFMwOxlAUcLtIS4nzAQLp9WY2zyDNNgDRSjk cX7zK8uWgoDQ04cqI+4AV2CmsZprcHkY2vmqXiPGypx5szBk6vG0lq2mX3ZIx2G1Boc2m4QipHLB 0PTN4YByk6y+wEqkfvjhnO+96jzVQyqCppLenTDXu9EwkB3r9OWeTI8rkktoTTOJK5/2ZTKvBCu1 csAApVuI35E75VXJ7SODPmNFxpgZOmviJ/DD+knQRHQUorDprjj84kLsZnbn2oIYTXqG3GW5IT19 fgGne9QYg/vSFvN2wj17yvor1lHiWsoLZFMXyKLfpAVN7cIi3c3hdSvwK/9DUVJ+ptxwTeWSmhFK dB/fC7vXOHamp6PYx9DBj2BXQd/mLaUj/0i86ZJLIC3XcHBHOsYJROaubfQk+k30Tt0TOYNhBYfD CPZ86roTgNF00qJWE3JWRa3SGtnehdirGfdxJ7qp2yWhcK1A3pGyHzMW3zqh56NvoA82xM6+HJop TZmY90xQadL6NH/r0UzOYf21ZnVNA7u4qKlqV0/FIk7UPyWvDyvd1oqJfBzEtHMx8C09qfjpdNzs yQ5bvwZ3AGypQEasR3ga+vjmDQI28OYe5qtjvsUNmRxgdeCLiXFIs88t7CFqoPgoMbFYwPrTrtDz AviMoM7Hsll74GrAbIhM+Qunyj+B3SbxAf1mRhqXy1xueNx9IHciT8D9mstUkroRQX2QWr3UWfb1 OjEUKAwMHEfb08NWwo0mejMYTxmwqctgWCBfTJIrufaXhdATRtH81PXD8i86TzceeXfz5NFhf4gr 0dgmU0zlvwmY9cwLNr154tgXq0trA4x9N3dx3t08F/aGFYwraT84Tg/IdjO/FedXe6Ri9uTxY65j 9e89xuod6vwK45JWBj5qRyj9Lz740wtz766ltenZnx/kWRwa6PWR0rcQUSg10qycNv15Qh1ChpXy KRgPcYEPQ+LuWMl3oID/i+P+UuD11bcdxnr3TsHNQJUBvPeFlZPXtNXlfdD2D1nJPdGn3TTTAV3w a36xE5RK6aU/uF3qaExbGOCDQZsa3dJFFIrzcvjXlYXYa3sCjAvDz9X51j19GqBJO3jaKZWWW/OF ljcQaWMn32eMzZMcnQ5lXVfx8EJEgnZdYv9QrSPpqm/22aEEyV44Qa7W5dLmXr3lsvdU4JuPcnpM PKpCXl4C20uooGC4oYaQOtBrPNW+nnoWHIDtB1ntCnmyPctnDAFQyHbInh0QbicenEC7gYK++ReF /DHVVRkGpkGa/JLWTTKPcd1AmImJZSGJiZ1QYIY100yA/xO5U6Z2DqgGZ4ORupeT1bOM90KizvsE 2lCVkVBmFpcvGFHogIv5OEOyehxGpdHO3ZEf88UUKpwcrVuIw3h6+5/r0lqaqP3oe9+jwvxKCE3p OLGl3pxhJ+2uzbhVN3mbHHvAnxySH8Ti5rUF7CXcnWZWWlc3hDl3Jb1ejM8Z27c88VDgkVEZm8m+ WH8m6+AZWovf/tqcW0sjwOjFVZmS798rm7c2d1DEakS/cY+6tKPU2lVjc/grqBBIdcYtzCVJMT6z jUxDsevcaL0TramCthgn6t2TMfFedO1NuKrahHLQEbfnNBgSX4OTyfwmeUeTYTcOygBV5oiQzRkr Ql3njo4kJVzcQhj1astG6Ee+58fqm/ZQPW6vWVlbh8yfmGmbtO6FH/xv7M8qER+qzE0lnpIPQiJx Mer33UePLPNQ11n6WTYmrkPkVtJzTFv0ME5cPj/wNR8XGZ38yOFOo8Zoe37ukaeRePhg6RqdhkDH sdqoA3cD31XJdHXXzoljiAcneXfM//vLhY8xIm4blxysP9P6TyvV66Xduu+5nh4LHC1O9+ZTAxa3 XXV0tKeCOZuaumt+fuGXz68vvB7ZoyMCB2vflsXWRhUdqP45+O1ft3efuvTj9zHx+xZS3AIWn6ZG FkQdPMA57up+xjbvsk9xyjnThvilm9M9uyVTBE+RSJrfu5d4QcqS7YTdRA9gMz55D2lKDmB+nq9e jPWRVTe4uQaqwzccrSV6U6xoIbzPpZ+R/zhmXmFhu4gO0C/1Eb3A+HcNP2sOpvTugUt3lO6g4Xhj +h1U6S6CaAE70asHzy8A7bWjpXmNRHV+jEQ5GugxHJjPXu/M5Y8zWIBh/i/j6GA+6gcY5cWk+uuQ f50guvO5inDcJ55zLJ2Q7zRp+mRqnVyJ15DESKlcUYW03ZLp1ES0gtSHjQJlSrXiH4lnYHs+Dq82 RxgbDMHIsyaF3PpVsnvSF17nh6nz9/9VvWpD0OwPKOEqMC/1mvf0QOqUDfKucIkZlFK+b9oOSen6 0lQoVZF490LZVLZ6blcpOzdeiE6P5qF0sQS1xWuXWO1dUDaL0q4oQanMJEQJ4z/M3OTs66BaJRrq FZdq51ggrw+BItOI5vFBtmruixgBpqW5rfKwqq/4hOWj5aF2c2izyc67zuBOqk+t/uQtILDMNs7t DedKldaV96nFTT8Bz2cp7yp5fzQO7yvVfPtK0rr9XtTEaCJaJVHl0DAQa8k+uCnS1cwavHjlJYOS fOVV+YnihjM1unxhPzWPC4YtcLVhX4Cbz5LTRlavBhwfK4fZ0kAuUk4j6sYSA5gBhfrDzSKq7hvC yghfPQtzCXmD9T3xu9/xazwwpTQ2FhwDpKwconpaavq1aD4+v4PvHVUnUC/kghcKkd7Sv9tZ38n+ RSozPfHXQOORYVYr/jrak0E0KHZrhrmNIUteqH5sLgkzycJhtuEcbODk+JPT8vRoZ4hRkDiBpUNV ehz+CFZFEglv561b9EcP6SRVJMqUnYBjvZaS06C0NMvxEOzCmafkfvHMZKnK9hOcACfJOZCVfYS1 lo7pt+8g6UxIIsQarwjYcCidmocnRtZL9sE9EG7YgT79YeDemMoq2YCECJP4dUw66kruM+DPMrVL MJkvVCU6gYx+vNzU27Qp1C8W14Q6EkXIuFZ8hGgB40HNMzN2W4jvnNL+XnJ4cRsiCfg0ajJemRDq BjWWlPV8HVK9+iyezEk1eC7qPTjJtPubYOK3VOdKaDz/6elMiUav2T29zwqux8yDXJmnoSM64W/B 8QGAVjxygmZ/uknz1W/Uveyx3QHKivmbwlEfupLegfd+y34crwEnhcwi1WdB5R6H9K2IpsGC22ah q8cY6zFRvjlmmkqv5yoN7TmNWlqQXloExsvxR0K3TCnpiJyti4EqNjI7gGQ7I5Oz9VTvjwQFDhWg 6spLvGoP0hmu5SMLjPXHP7ZtIfLJKsTgBozoTSkbQ+ky7jEravdUiBXNz0F29KrcHRWMZyQVUDgs h6xjLVbRZ6eSha9YIuJUI9ET8vR5PMNEmlIH8GrLSGWZetBylUZ8En5XsMRlksWrcUTNShIE8dEh k716K1c7/sdV/r3t3zZ6anDGs3jzT8fjk1AzrIUA8sI2mVZWGXntVA1hv1Dwkc4XKrrQVli7iZ61 hOg+kj449BeJ6C1Qrtod51CaySRfS8Dz001+vgf03tuRycPswtmuOtpP2v24qDPZaIcygCOfyfQI QlEfS/qg3Qg1TFZztCG4APtZkOMWwneieLikqpWcSzxYI7F9Ii1jGqUmPCDgONgfJO6NBMZ57E7Z SwOPzohoM86dH6HoPN+hze6lzzB1wODMHZmSdbPvkF9eUBRlOHCwK77L74On5t13d8uv6NkF+Faa bUPGonszC1YuXnly2fBw/5iuy7xXidk5EvDrVK1DyyDvSlDUgeH542i1bYal6df01/6u4yVM0zz0 JL+HDLgYUesyBqU+Hcb+dahiSTo0KVOuAKg7YYioKjYijVVpO+5dqkTD7n/Dpo6zPC4Fo8aMBYVe 0GJXlY5s38P2RtJrY1Mo5Tbf6ERfSZlz022wIRgkFeOBhhEx1iiI6AX3pF2rJ+qCpcvYvHbPwo6q drP+e0h1GM83rgV1fWFfiDQrT/61ryWK2JxwIzjXDk8JoQ7Iaf8g3yrxvPR+U/Lkw1jsrg0jO5JR zObs9WeEknmywfLT1B13GwnkZfODAxduWAc9Hda/w58s+4P4JEdzheV7tdbSeMdlwvPe8uKGHM7Y 3Zm60xVKWtFzjrfjar+cV9NuiulmqpkGBjU8s3bTzc+KzB728/EajCjuOTZbF9Bz1poej6fTWns6 Mj5NvDfLeD+zovfRqumnv1yfqoCuDK3mszUNw3tbDt3U25WAfaG7ni2Olj1blMeVDF95ZDnHuhTm Jii9Hg2PPpQYyB8yiAdAbl/VzhW8oOqGvKrfMAq2EHH47yUHJpinwM99M7KfIHs26/vYcI02cPFu NYE65BBIYRpWE3w98mQfglvHN0YaRvDLKv/7bt91xL6bVxB7bp7jIRzKJDtgNqTQJzOXf0Ru/v2x xMNAg3/zLNMUHJMpAXTCn0UVRtehAAoUgJmP5Eezq3I3nadiMgcXNSFKBtOZFhpjbHHjo5WdPhPT EDvTeci6ADi6yTEP0h+v871JKGcrKO2+ebvej5Y5Gvdi9+0n2p6RHrX+7k89kpb9yk0OTDwSzFKe JaokNd/NUVdGn9E1HTG/+Dmk7Z07U01duyxKP14l7OqFlZaBEduhXx8fGhwqf+TNEVxJsvCouHDJ wI60Tp7/LCqD84aQcwsyRQgq9mop/Z7NV1+PEgi/kz3Fql1+fj3tdxnSCaoWVU4G7PqlNDNUemfj 4S9JRZPrnW7JeBy8hQCwiG8x0W5sniz6B74N6Qq+9o0hJPrgmET7nki3GZaKbYjmsH8d4QUql6XR XpXFAs+8Iu3BXVVYVxaI13WHDLA5TFPg3phyWHhQLEuNaZqYzmeoEnJXdq9eVS/a6FbP2UJMxZP8 iKZwrD2HkcsCA1E7g1agGIM3LIkWWXQNGsu2a7hnNtWYNGYosZDvBUE+IwvHA7DOZ//JyCct97xf 3ocomW1HZ9rEuFXl7nWz9ZKOUpH9IU6q2t30IO9hHs6/1Moh6LldyM1W4mNaiEY5Xevtutabm/EL v8yxC7JWAFs/3hOar3r4rsKJ9+XLrraB8aYpE92x1nSTDSrfpeABnCjXStYu2oSw/V+0Io+lBT+L 1z0/J61t4AAACCD33+lq4tBit0nJ2Btpt5ebZmzse2JVTNlJrjXuk4IMaRHFozsJoj4Mq8/hhmVq cBrIHjS2GWfaQZj+cEewpJbH0maxuytQv0DMrm+yHaOMmUsFvuY0Jm0hdGAGIKSsM3GAuhHRBz5Z 4yJoSPfkp3I8c2wJZvwK1vUtxM8fmc7i2PCQ18tfua2staq6ubDQ0eg07dn1BCgsPlk5WBBjbfJk 8pKUgueHXvvn7gxO/zI+cve/4+iv5irU0HMzmN/Tt7lOHrFSFsVI/9oI03SeXGurMDwzQcZV5YWk 3K5ZDkluS7lKuvswVkR+XHC0xCA9u8Zmfi44hK3dTm/z7v8hgWPwiLrGTIZGL7ZsNPwaM943FCRp ShiIDDCdplNvN0/RAqV3XZT3WAV73HYJnu01JgTuCUaT9Nnb9MaHzvg13yl7tZmvQH3P+fUdpdpT NaOmUidpybXSZOFiVF7BhcZq50m6Uvkr8mA8WaYWAx8HxziLBt0wV3xA8itMBp34ObV4POg53LsH ImeRDhDPQu8LG1dl34MfsiXuDKIlSK+Hffu6PBoS+VW7V74mvCFGz7Qrh20bOLqFmEu5uoXIY4Y+ ILj2vpWyMLwmko40GxNThZCNzX/NkBnEpbJ2Y6I9CzBGG6jdxLPwGz4qS2csGWwYQGqg/YgY20ye 5yBe5RWcsoJHhMRU7oUutQusTMLBL7MFGxZSdeBDYRv9MKe00lhcKtMQLiTKCoX/dwQxBHduIcat XCSm3I4PUkPu/x1BFEL4LcTfIR2yscE/fr1ZiR07HcSgj76/m9y8Uf+Wuj3bJ2OI0RAw8MFH9roi RMOvWUugUgcse/nbau/XW9k9GGnuUWn90LjtypgChbCHGK5Etxyo3N+z6qI6eoPNf7yrJNTB38Rg 6nbcna5jjwL90kvjQaSgJBv68AtEzkUfV7sz75JDjEdlJ0mjT0NH7/KF6gSG6xOwNAudDAi1lwze 3/xr/sJy2YccZvyD1zVxTT8+Eft5XeDO0Zvup370/2R9t172qsw8fLia9JzVYn2zrKg2nR6n+JA0 s4XQ+l1jCxE0vd/eoZJ+tYP1uOD0qs/UZf0mFOODRljY8/OdGk9/sgrBgqWkhaoNPLmFJdtvz2HJ /oyri/pyIeYAWmvPlTvmyeWtxJbLD81LNLLRl/auav5QYqZr8Cp3wEaeH+tpO0/v8g7y4vxxOoGB 9k8TE8/f944izGP+qdzfCI6LEu7b6bqomvtVfPBx73/i37B/xW0lz+KdPBSy4sc27Vnfjtc0Dflc eUO1u9jnbiHipaf1f78IHxZbwiFu/9Z0UAfrxJ7EQKh1Sd3hzmQQVmFE/CPBAKV1tPy59eyp4qFw Haq/rbLZ7EbtnUUnzNz05nSfqZyDY99NtEwIS/Tq3OdOzNveqqy3xTvhmyaWPXW4zl/2xHUvMSzR FxmLPt6hHSU0AUqiIRAIOfhskq60mniSh32VL6qS1h7JHzOUcUJG/x8tXxrWVLKtHRsnQIzMk5BW QWWMMsgUkqOoNCAgICAgRESGgIgoSJBIVIYwp1sZFCRpRGQmIqMIRAiBVhoRAkRQCElEZtlRiVsy 3Xju/fU9fX58z3Pvz117qNpVtd71vqtq1UBetxy2iQ9/izN6vGQFA04SQf3xnBnlMWMp2x+eWpuF 5j7mbcltLQ2vCzy3mLxzrNNw43pXxYkQTtRQkM41lxGqhxTRn6EiKBvH1/4dpyRo/ztOyTCm2EuB NVpoM9oNxUqdmwFw79iLF9QRpJqYSd2E3L3wnSlGv1+Lo2zG9+yjzt5HajI+r+H+3CsIHHryYAcT eVbxxxsB5Jyc6Ghd43gwWjuH4trm1mqk6KNQayVXEG7dSqr+0hLPuADkz7nIp1dY5C8GLzCK3Rad VbiaehO5gfY+8y9hwCSs2Ve0N+G/g9i5/xPELvRV4KLfc/m/A7kDt0PcQT13ocpeMZNO3SXtoC63 DRYdDbgPJaMUMFMfbqS4c6KW0enoNlhfrSDQziXpt+73VWAhs5cEbU6/bkvJtagdYBjHoxlZRvkL cj9c+G3gbcFxrEyvBCJXwo8CjINseDE5SDshAnDM8cQTWMCzYKCyd+iC/dWv/WKLkhPPpcCDiNiI 8zdpKMLsJu1lIg/4+0cs4sIYnSZcCUTxVRmo3YfyGXGeEesmXC/P7rkQDm0KIqmrOyp7yfp27Qi1 9ezlKDWXyo2r+N9zhfpjM/xH61P7g8u8Vk/XZvZO0EbpjMXVp/GRNNUTqPiJ8i163LhkRZy1dHTq xe+KNsLaybskkNkCdMvmjqJ0y3p1mq8vaSewbUBHac2/K9olyF1p+QrWfYAq0yySYx1tAdpSOh25 6B3TOBT4nFfuOBFtyUqdkWciXNnuWaxdlkQIFvo54Cd9qSRIIFHoLNTO5AMRCmzq5NeX5CbUHaRx IDiEDycTW21NM3l2/jwlDPJXAC59FvPqyXiyPC7WNqiYWLusq/EWpw0M9s+oEc8CD20DyX0P9oN3 qDuSwUf5KmVycrxa/wIDw4Kok26WtYP7++belJefrJCLzB5gpl9ZcPV+aDRSeSztxqHT1QoXFoaV bXzTvO9UZ1XYBD/1Dib0efU62vV88r7y7XB7sYYEEh441+4/qbPjDDAevANp1m2kmjbge2Ys+QSs hd6WkemeSm1irqJ4GPLcnQ0W22Sghwp97WJ2swzhIDgVydrcLJg+cmSrE/ybef3NRx804+5bOmlp 7Eex9UVtuPMojhPQxseDBsF7+vyL+tAZ4kMgnXP/9iW1bvAmIIH0zkCAv+2Uo359BjKrSjJ3/IGa VNIjcZdrjF6Lhwe8maoPOaJVQ4+Xp3vPPx0NLDMYpX9SISc6HPZaPbiM75JAAsAQ+Per8J1mmxf9 z54bzGpCCDK/FnujyIrO6ag9s8I4764pa9KOUoXQVYNx3EPyXtgtlC7CRwbnKmpM3ktXrlL33/Yy hsBS6N4Bhi1mnH8fg3N6jAsGK0M0FARlT3Dezx5sV9D7esiz1UQCCWZN5iVVtUC1hHZk7pFqlcG4 DqKUlaF0xG/v6XPMnHSmKyj9eCWQdWr0cVuhRWG/iS7NrXl0yrrIubUxT8MTVbfw5Jlx9Qtmr6O2 /mW/sPioT/fSWvnX/o7kVDqhfarbn6wnXCjKenjT1ToU5+CbbjBkPVHWo7GbcgsAK0y0+9nt5jJ/ nB5w0o8Y1nTr5DTn3H0rHBT93hxDCNoBUiWQLRFJqwd6klUBx1RUNFXe0S4Qs6GbyY7ZgT2JB/UT hMq+njzE1cSn7zG2VoTwrEnK+rv3K1OXqmUC0bXbsxv2RcAAlx+TT5pEGc32NyY8g3TCaXjABZUj NnrbohpCbl4k7QPWVp7XLNygN7Ven1nsyJ1uztEw/vv1y0TUxrDUI/V41JE/NU9QZxupgNvwzsjW +fstCvJ9rCaKUDGBJv51tOHe41b/7szqJa3AbwpfhsMTECZf/orik7opW6xDQWufVN5Y4T5Ff8Kz lyFqvyiedT7rdNKrVbejaqqv6qi/7pAX44HziHD4UHXG0OEWZIutdU3z4rHO2k8WkWGqlYhA3Kka //jDKnPqhvnzPuVXS2o96yqNnD+jCyQQQAp/PWb4BSkwfb2LboZKIMeiYf9UeMPxp4g3GFiplRIi Jx7xFhVDUYxCycTFyGFY8pelLDKz24ZAK+9F7Wpxzw7SbwOepJQJzQEyQejaIIzhpdqqNSViorlk XT/h3mw2LOXi3c/MADA7piqCtKdp1OzfiUPnRZlCTTZLFnyyNpBsP95M1MBy3QG1op0EwI7rysx8 PG7ZfskxbS1ubdM0qDQwMANnCBNqlpEwYJ62vRsGhtA3mHTirqhCPmqHBV79SRHHJRfqnzhn20h7 XXjArnq3m1k3+igN6T4V8rQAM9rHVvK7yc2gPR+t9s+/W2BsfwlpiAmu9az3Kkw8V2YIlO6uMaOx g3Pr1fMtuKnVhNqsygz0KklkmB/hy79KMKv2Sbuxq+uGKoaWJ4Gkxohl70kgJ9UlkId3RX/iN5Qj /qkwajouBjyYsFLB+dGNXKTuFO85hzvOQ61Qeepsx15KnlgBWEtfXzXvY0ERMbx7AQA/ja2z70wL r4WYWnf5Y1sHTyWkr9x5DP4RmP6cy0ErLDX2cGHQJaQ2gb4eAxonrChXYgd78dBLuEQegR50hJc7 9xpD0gLCV4oEfthy75a3K+l537utxle/Ue7cw4dh5bTxuxYSJsTw9uDyKK2w6piaBSvbhuIiqyvK wxhGNaHcS7nUqza73F05rRIhPkTaJ+9ZoAXQPTxfHkAY0SYqMrH3Z1IPjRtw9D08Ii/l+cy7K/qo PKtm9I7VOipbhyJe594wK7W9f+Nh+8BgpjfmTRaNynrTGbjdqyDmSoUEsp0lVD4gzoFLIDb6gn9J IN/2j/xTITMYeC+WmxTICENS2HMDvZQcXVMwRZ1+38JArA2TFb9hNb9pFpvbCov98hgOWYOzK8+m I4t3kmsnQeLADSR9PFkbe8TecQC2q054eFYE82Ua34RKzfg0cbKWk7AyzRvkV4jInd4HVhUBJj9p QnwAG8LZDiYlsmO2zdA57ik5FJ62y7MJsT1Inh2mvYvGoZ4UMRn0G2t5FiiZqKDdZ9enZehaT0oS Kz8EeZ+bf+eoathifQflkX7kiRnqvXk+8HbwsMUhv5RaN5tLNUdnY9tzkFBVdd1LSLgioXfMg+JT apNvNlw3LOsO3UGq4315SdtcVnii7kyT7dniHwlPi5jPI+uSYdtyKKn52nl705VV/e+VIuz9HGiO Uic5e19RUZ+1Yl8eMfGXg2sNNkUsG8irpfmbZEF/xFQtT31faXmysBH47OHWF2Pw1eiRrPR8tdO4 fWL5PezFb6x3yvwyURnyF8yELhxYy5ZAzqOmzPkJvH7C7FHMzUqQxobS3VNIZgzkTvAFDTa5YyP+ C04P/INjb+fB0GuRmn40mQaD4Tw70wb1b7tPrsmANVAdrFGP2Kp1pNORPRijAQbQxIZtwPecuMRO e86qHHTX4pHiTn+rrDh5wl2uA0+3SIfzbrkY8fkrpvihuo/nC8QO94/oVc2biY+lWCQ1n9mqhBvR fa2+Wtt63UHjv231WlfnWgughG795HdqxSpqv+Ja32LUWo/4dMQppmWNTk3MbPfYm7nrSuxOrYbQ Is75Je4C98uH+O3BM6jdjSM07qNGS8yZc/kHrY+pPnXOM9yVP2Ek71O/TV/WhbyEQHF2wxVid8rA 0Appf2OTrAd5ZxGCLUVsbgopmqZZamiNGJZ39o7yqVh/Nds42v+xvaNRauud8/JFYfl/8jSczQgr c8nJ4mFPR4DBHxN1ITVB0nGGJXlqGwfey5r6yr46Y9aLCJ2Ngk8m8ONE+cJEdYJORrb3c/AaFzXJ OlXS33qk3rSMXRuTObOpeyK4hSEMYT+giIz4HrydlD8xM+aiYlxMDWtpxl5Usq5gTruu1d9o0aZF zeuWjQJmAoU7wcxriYfMltraSBqMNZwMZzXISTfageNLI++eft1Ij710cR2Vi29a65FApmC0qZj0 bjjWDKo8teBfszyjPmHcgt+FdezvlmPSm/kmHCgEdxzwqWezYFgZdIlrR9fo5XjqVmzRsfHLzdEO HiMNl+dG17WXXYgwmew8O1lHZQ3bq8X5UR73PEkw5ZNXy7NoZzB6S8GNKktvq7ifnzPuZcdiuj8b sjc+wMmfNPXPHT/c/HS0DA3/u4pRYIyMvRdmHWlT6FjKxoxdrkDsj7/HAWwalEoDfCoJdEZaRG9d +HaBiSqwTWjnzo+XQB7lCvASCOcddbaaKtJUwdOapdwNvXGQJZW+YpNssVyJBDLyR2D4MAw/gob8 h9uO//yxTd9F/78V/QuGZwSOWmD0Qo+fCE+4LpeRJW9ufniT97/07/8O2XzvNnrTf3jRzR3cH75S e2VZPcsUFYnP3NA2E1FfSiDaPzduoNtYA5R03V9T9g0xhIFAOddx1Zw7nN5tNvKZw4qqiug2Ap40 PY70UZ7GbKQVDOVOD3X+uUOUup13+YUgFpc88tdzMF5wKnmyCK+YrLQc+/sEyRiA0lCT4Xw/UT4x 51siVpCQjgjgwicH6RsSSMp6+5lF8X4gV0zgRO/knn5rmQv37BJBagrV1Gy9cwuLKib9MR1hJZjo 4ErMhNrbyXfvzk72FvILfXwKF3W66ivqO2N7oqM3x9I2H37ssfdRTXbc/2xtxlUIAoSqIIXH+CmG Oi2BSk4qVe4xMD+AJ5CQYErtUQ45h6RS0odXQBjpPr/GgW+mXQPgHLR0qmpHXgWz+De1Dn7Lpmbc sErdnxSbxFUw77+hkDZ/G+HW8APgtb0IUL9DGy8df/rtsHWHNe6kaVSiV49HtZe6j+L3ebecMmiy xzYh4vjEs/LU/gsGDMHZrHeXTC6d2K1v9aw2p9ZZw980aCVyIqWo48F6tCp4AuDypWN+5zPW6BTT 4sXa1CAfzdusVjyRjZkFhSE1UUH2zchdI+smSd6FiWuX8aFoeeHJ0fU1RYyt761OeU4ELpyH4kb3 fU/WB5t4DjRprz+D0/CpM8qCchpajoohbhW/Ryl2W2EJ9FbkHlFRAzUMvhWU/w0oINBj8pDGYAGH lXfjQGacYChkQKqR4zUuUcPI6UeUsJe16/dOCWb5pY9Bcp+Ucn4u59rEGM8zjDutDlfrnrL0Hwqu 9in36fLzeVGolm9mHBSrHqRS7uFV0sde+MiosOmtRwyqbq86Uy57JjbjYcTN6BMuiut+VQYe2Wdq Kas5+30NRkq93bwNOk33KT7svVJpKSq9U7ectOOEs0rkzeUTieF8Kh2962GEWGMEseX8vIwnr2sJ zA7a7riDpASUbmCctW0c23kcV82XZLe/Lm4TGr4wCfhOQvBgmTjcisqrykjm4GPQ69e5Mil0OtD+ WLQ1LYuEKg5wrHFHr1bf1v9Y//x9v3iCzol7/SUnMI7f9+ncD1MFy7ryg5yqsSFKVJLN6GtD9pJV aKC+gSm+bqxavJZeaymBoIxY8s4iL+9feVatb6wxRyUQZB5zHZVF2tHYVeLUOHaA59Ylo/HpLUIz JIHT5TNxbtaxeqD8RHx02S833Dny9YZvzxe2e5xBNYuNwOxcOG0KSluWNZc6RY1AogqYe+bhLwg4 O3vBwi7coCgPg7uWNPfXGfcn7Y65IuVTo81daq91rE4yLlmU2k5ef/8OU3idr+azLHoXHR2Stb1o cp/Hqu+CeHjo8I1Pms1VjCS22Q2jLbLH/F+XXorHXGiSfQ2fzjuwydegJCtm8sSL43zrLHJ/X7tj PcL45l2M6IF3SbVfy7Pqk2fDJjqryWnqSIWnY8i94mndvcwG0zWE38/1gmUJZPMaI3r9/oGSk8S+ CdJeMERacmc8pjOAkyvjXqizdUk8NexR0nPdNrewNPiClBrCCBe6sySQvmLTeo6O4/cgqhnSHvSi kTch4Th/qaUqH51oWZu04tcBayn1qIih8KNPmTHr8FsodbHKAp+kC8AHbh4HfWw6pRLRhge7HUfd iU3qZyl+a85C30buB10AJmfLen/prChkQNccgLaBvmx4NiKGLYLTg36RWleqeETXELjeEllE0mUK jUIEUCyFtlFY/LG+cwOdwRbdXU+biD7W0DcG8x470H7wYntn+8NXRkk/LgcWBh+CyqaV7t48d/9C 0w7vcy79HENuLefKg8sKF4w4Ie7amX2cEEeTCuf6S2c+TB88nRPperRf4xhhjKda81bKUHecsJW7 XOB8ubb+xIRntT+25tucx5tS59M5P5Zca6JdCg5+xbkLwnEx0kZeFBqDS8XwVX2BFhbKoRCRBti1 Xl1Z3hrd3oV/Q0RGXLt2pAxgSnUmSC6LFBuQB4r7yTw0p6Wth7JFypvEh1OcwBA2LKv7COBLYPrx kCnsM29xezirvkd5sCmpF5AC/WY8kJdmlYYIF+xdwjfjCS1w2UW+2Bb4XCTYGtCWijsMcNmXi7jR Ab0x3BLWlHkvTLZTNpHtvh1b3kdWRO4GE46OrKOVgrAwjriJB2evfk5jk1UW8Uor3/AjLsPvbFpQ atja/g3qqq/g2HL3fl7DHbE6T6rhM3DbBIrYOzoONKaW84Ltkz90i+qTB4qmTpaGckyUjOxh9EbM dTWHfq2wgrJ34J9L/I6d2aoE0itpkxvAw1K7I1r64RJqXGpwXiQjcuZUPvnZvFDZdU287xztlyla LHewX5TqOpA9nzWpNGOAO7q/TO/K3t6cfacfFaKhtSFPhy1eJ+o1Wn4ZX7805FWWTXGQdT5EPy0e jqs97b1wpn+83tWrjxmvpuR6rHT3CdO5nLv1afUi8v02VEjakBflVhdui+Z4qVV69e5zkY6Kbpb7 5CxilervVKzfMM81xTC9bdApEkiLlVCpqA/1zHHVUnBV/KZ420v7mFn19Hj3XVgCP5uHplFTu7cD 58QWYIoA6Te5rDYxY1TSpwW/00zUkU5I84YMpA44cG6CgjBCFHWotbBhWq23r4U36O6k9cOAU3Cp bFZB7sZ8hz1F9xIzjqCUk+WTh7vtwATe5zV+oqhAvBcL9QBDefNBo0JLoPb4i/FmlCKWwkHdqRvO tlBAHWPEDWuBB2haW1vws6sXvrPnWNlxxHQSfBxh9I18izpbSlIGvWeru7WEcJDN28am0kqI6u+F R9uBbbe6IfgeOwRstlqYFF6H0d3bzOucUQW+r9hVRniC3cw+ra1pDe/BghVtv5SzIxa5bkbjXYxL 84T7aFCf2Qsm/zol9GeITUEJ5DhYGZX4eIacidQGlaXD+wMYIMLfH2Pq804SQ+uxbTRW45EHlKiN I6WcB3i2Yctby0GRgwORfsgPvCdALF9X8+WLnvXMGoYAlkth1k7sPej9Z2s8/VJrT/e8fXnh6Y9p YwW/0HOj2Bowx+Lq6/gDjkvWp1pLDdcb8QGU7QCDkldRyI1w2OKvscj+as2OZGAPBtdciAoB7ud0 PLG9O+BXFbxwwefImT+5vtq5haYaCbstteCLJah3JXwzRqcdm7wdI4E8Q63Qg9nwLZFTl6mzLPlJ 4WbQO4rNko3qsPycWx2xwUyP+w1xsDgspRZjSyTgUFWYjryCaExiSFJZBNOn6QTyQaiejj5xhSI4 tIiXF4YDDq6ih8kyGNYW8b6lqTddPHm2ArEXSpggywsTG7B5SxPf+2yZOcJNMewFoQEnNyCw82nj i4l4nWtO3Z3jpnWrl+FPSAHYQBsoGE7Nxn+7iWpxFCuhGmESyNEhGDCMV5NAFjbwkUShHv4CSpxS /AZrbOl+qSYMK1vn3nY2zdbvYVcHHYFodG47ck5EmdBPozlTUVat2MidleblLkXYC0ZefEPNZFN5 hZXkhjLE5puE8fF4h3fvtbqKGs8+dC5/NbgysbeDYFjrVbLAUsCG00jywOeUWQlkGxZ/HCCndpqU L3brAANpQsuKsxFBOsA84VuUddwq7NjbOFfTGeapUYubRu5tbY2MuCHkxMzr/jfbo6PPZ23/Q52X zf99vHnVQbydLoFsiW1s6shL6trGbhOqUdzG/3QQDBoNkmHJzBt9u15XbtaMW/V8PacR6hf20u6P cfxxFJvUbayrJ3pOjczch0DggSwx/fSPDOzFr/X4END0wofnaLMZbPipz1lnP8px2cQcW/zL4Zxi WIYEEjJ8K+gAdbxbdWkjjAjQ+AO876nflok/zzz5fjuekiHWGUNEz+LVhN5FPoQTnaCAF36S55uH sOJkR9lJIOpgW49YV0o3hafB0nKMz3XSLnflK/NnJZCVv2UaeBaxY0uf7iNOYvzl1YfTX/bnIXNx F+ezygkTeUaa6X2cGheSCqByeP3J+G+e3jahhvk1wct1RrTgK801p2u18u7Elvufjdf0yNOtP3uS pDOSU/O1/aDHpys5xd+TB0RVe5+DXhQslN8+sicshb3Zn5DWbT358lli8fDKNFd+2hatFeW++7de jmB24kVlBFn9UlhpaDFULgKl2Kxz0DGBK+sn7nUpSTQZ/WzDvjv6m88nu8cFutOr05trbU/VhUT4 m+n5OagcdEg3vOaBfucXWWjVEVaJia7CTOVW0NPLgpM2JxxJaPX9vatrumK6+TXwIeBcj97vw5ur eIPKnZfr6o5K+8SK/TzZNnkErY2fLSWrdjoiWwQ2yT0d7nf2ISExu5bgCYJTIJ7rRkJcAwg9VI2L TiYxwqPAAP8qGCzKnoVrYuXE373fiq0ixQeAT9U8R/cS2o04rQN5uIz+s8aj19ErD2rmLy+NXbNV 4W6bfq+TUql2d67CreGXq7jxxg5xk3+L6YHZU2YP73F0IfdoR6++Gvu7Xduy37vPK+Fc87ibCgcR iH19jQ9+CJPJPvTt0WLoB7N85DJvQKiSIpZlAwNBzwFKH/k9g38ITOJko0ABwMpDRaJui5WZ9YkD G25ECvYT7XQKCZV0uZMptULoBamH98OPuqDOQ4WniJNMCYRkGYU7xEMTCalxPySQi7DJAH4yIIG8 zG5CiLd28tTptZRb17sNRgoTo1eE3mwyQQKRx4fDsotvFqVbfrzdgoJ+WLYtzKxDLyT4B5VdK3vn kmhSQP5TAukNFFzGj3SJf2ZS3WdJLX9jS+0iKSArOzb/6ZW70c6q5rs7Sn9zsrN+U3rqTLgsffGg 2+F8/0gni1FhV0iVxUOf/bEY69caxpfYeuueqVxC7MOLLTmPPlwsxjQzEOViXfp/r2g9Lkx+CQMf wJooEggiEsVeQQMu8A2n8JVNEkjmHz9zwr72/0z3Sn3B/yCBlCeJCiQQ3uFuKRf4Ju8hgcgmrD6X QE5+FxhJJW8ILkAKUGrlAjvFn/uMYWDcIOoHZfjrysD6FOqVlBz37kiQQMx1Pf5DT8IAPhzULxLp NfEhUqL5l6gU/4PrW/uPfVH1H5okKpVaPfk+VGgbShYy53/wg/9v6qbx37mT3Cfn+Wgs89MfJqhL 8Ky70x0AASD+33Dj1pHA5D61I8/Omd3Zk/eJ/2bb7zVD8TGamN/Fb/rww39vE+uYDYujvgoFhzZW YR+lg8DeKsWZB0RP0IvHmsUP5KqLldxvszSTVYRhwFqRCus9Sy55D+jI2Z895/7iryKBV69Wf2PI 3FBLZ+VX/quWVrUeig9l2NV9FtazNnV9oD8ICVDvmFDD0O+hbGpGPHHbMK/kZUdQSigvgY2m/4ZD PcI+6lWIoSer20a39ePTNsREjvtW7BtpS+ZzP7egIEI34HJTeQDI6C2+3qBLO/ZdApk056aXCU4k D4s3gbUNC0eSVXnpf84YA4S+GHlM2zX0IkkDpAC1/WL9n2eR0Yq9V0cdkhIeL6CVOpU59UYu7WMm q/EGcQKX8LG6lbVcevO5Aoxbzpzb48Rw7cBA6ZTND9U80f5GOdszdXZOtqf/9L1s12/HrlRvsUZG DIaHSafs2CPpM2oPQzX1D76yfmWwv2gk3+NE2Nn/Nyfat0/35/6oiz/PmxHGcxS86N1HpNc4cZ/u YZ7P87jvU6zMTm/BQdxWHjTDMnsSohQUWfyGMqs95Hi64wokKfvFg4rzW+etVfkilU3ANqFtwr9X pH9jiG6heAo/wzHiBAs8rfJnKsi3XNQ7GQlkF+tn0Gf+Gho/8i8Y5J/vOf7jhyy//69Wgg5bQO3s 3MRGy7zHmQOVdzqN2CiCj789k/BNApHB+h5lIKzY9lYOnU7cjtG4YehC4YRWUEmw2fS5mNbG1rbs uC/tpz//nWRoGL79TOriWGqkV7XmsQobuptyKiOnzPqV9Wuz7EgPzJMSV4u+0buxd91MLBhOT4qb XO21ok6ScnXDAa4ntY3gDehS401YGTh5k/rfu5/btEulGq4JlSo8NS/zd+GXN1Pzv42HvmJx7OUD QuXljwV8+WVyoHeNCAO80FPf3e/KR7Emy/kioLWct9PmgIsPD7WyyCH+e/1NF5WTrK5kA8N0jyi7 SDGWjpddLEudouQk62B0Ya3Yoj7fdDQzJoP/dUF5EaX87a/QwvmekekAkDQ6Za63Qb0Fn9HEHZVz 0GDF32T/MKnvdH88cG8fsqQKU9jj1mITcxcV8pjRQiGiAJ/fPrqY+DqNU2PgBCe9q8bqU9crKtH4 HsOfiVNZCwu9AVFSwoJxfvb0rnyG3q+E3L9Qhwm0sdrUgStz/l/S4aZpWg/CzCotI4myb5Y+3v9h 4Ly+fP6wdUzNBW//Z9VZ9UWdbntOkmwVk+d/4cmx3fQGee/qjJuMd26tOGUaXZiErx1EsC8xFdDG b75kXpg2/EJDMPXoYTYI3tNKL8W0UneKh0dD1SvpqD8T3+Po4MWyVIHdQpBSB2mA7s9ccQSITsD4 KiVzDnAdJ1GrcdsBEYmYEM09iDDgPhfqx0ZXucZY6O4n9OgeLjpWoHyG2Dvza5TH42lxslBDVCT9 x1axDg+dhjDnur/Xnt12ixpeD/15tiDCrPgAbdprAA9Dmi1SleKMiOosbEmfP5E+PLU8y+ojaws9 iH2jkUGqDMQJDlQb7JjgBjDiMHMAMVWsNK0ETwZFJcadXjVSDdKtBh54eaNxBGmIDeF7v01W7EGY vd9fNkvOEW8BA2NmFVxOje17Hkp0nxDCuKK9SXYC++PH+AmFO4v+6FN9Cd5zEhFRs5VipWzOcB8s jdV6pPYRSOT0l3Hsk06AKJ45B0nhiFBscTHrHR8N7fwv1s4sqon82/dpaUUmwxwBSVQUkLFRBsWY tKAgIKDMg4BKI4SggIBEjImCEOa0A9IyRQRkMiCTCAQCBJJWlHmQ0BKSNCIinSoVqJYQbjwP996z 1lnr/3Iefmv9XmolVbWHz7dq710HJbYQC5AGTICWQowtgxLPgUICpY+2FaP5kSwXJcbxmXfWZndD LuB3lgsoqQX1luKOjg2+TFEWZmTH3EuzMiIz0qybLY5Mbnu4bafTYY6GRwnqUP+Hg+de5jnXqckc cIT7EMKy/v28t8v7np1q6QHBouC5KdHquWU45ZXFffYgo8yIEBbwQhaeUnp2CH7As+TCVtvnq3cr A9mopk2YGCG3guIq9GF3kCOHphd+neoyIMo2htxpv9IgOFocyl/oieYGnm0ZphOPxxN1Be7v1ti2 rZkkbYJzr8KyHt+65Qk00L3dPP4VIxrsmOOwO8mc/Gsk2e94gWwPCjKsTI83l4lEKmw8ZWjNYTPu irdCjnz3jPYP6S/WkOoTkoOQ+0mooproACJSiSpCWgpPhaFVQcBzMOgpzK4Z92ccaeBgHyQgHCYt l47zlzqUVLU2YeYrm7B3MhIFkB+CIOAF1B4sZLjACuSllxiM01fIOe1kDlmajFUZicDTN5EBm7Bb dWInvih5E7bdBBu+5H6nS334CbCQIiJiS88ZsIoR3i2toHmmKP6V2EZQr9aa9S1kHDsTItXENRJz aNA0ZO5hQ1jsY9T0mmDqlqWLP/MKnFu/ao39UXzdwZrdN/oNmxHyDtWUyKpH4rA6Yx62dbdDow36 Ot4flNp0GCc1n4OVn5sg+tN5+365V7kS5RlpZXSx9iJ+JHlVtDVQ9uGCf0eZs6pHahQT4YmpZn1b /Ho8tGa+jYRskfMciGmx0OmxazlHkvcs+qVW1l7JXcPqMEvNXiPjz4Mfp7Ku+hX4ieX/rF7wrjnp 3X+hWtBEvIT0/rprsk6T/DOUuCpljhSKJT381KSIeWXolm3eagPo7jFF2uOPD5i63cL8yZ9o4HpI 4JbP520hWgLWhVI8mwYo6fGuSYOXA/l1ndWEMm+o8rp+JZlP9xg482L8fMGNzrhp8U3AWKJQiLhD vF4q1t9oYIZPMy4YUDFqToBQINt/1H1bkL9Bb44sJ+mfFtDxNOjLGtpKYn3f5UNTFwfy/S2xSgNC XSyby0tu0ZV5M4K2AMb4BtnfsqjZJLONIxvFltHZBQ4pQg40+mQqYEKyLzKJQ7EkMKLN+47qKrAS MTuBB4iCS1mCrE4Ei5u3kEZjr3YdGhcbI+ufRHx/htQZj6/oGmZYWWC0RiR3Kt1oEyXbIp3L7nyJ mvX65L5kzLU37q7/zAgtqjFqPuBcdKGA71WMDg5VDDt3omZALSOhra0iO22vZ2qUyYLilFlzSOOD PZ6odHeE3S/Br3zmM69fO2hRBEBHzn5vcQsOoP5NTefJkXFwFckkqonWT9tOjBsmHlu3Fdv86CHO MRcsdGegjwiWXPECzU7BkGLkQyQS/C3YeJSYCE+zikAffWZA0Wb1kkwBJWB4VAkfNMJwszI9Hs9f 6VT34ryvlMeZBVxpcq2LvJcAajR4ruaFJbVcj/QtMqxpKmBdKLPfSln1Q1sjU02XRYMVPMuJnS3X HucpHjOxPHKg1jMlz/aXYpydxUM9FaOXz07UCPCTdM958rRI4sxbHpOm/bN81MZF7LsPjDKJXOUm TH8J1PnRAy6Rl1JivetGo7Eaf6qfuQvyFGzCljMS52jTNGE0BytHqF+ljiYEoThSaYG2X7dalKi+ bAOmPnPWbcS/gBiKCsRctyMaghofqvlMbSIW1M96dg5XgmQO72E2FbqmBL6ciLLKwZ4GyJDBEMc9 UxveHY3yWyQ30JYNhC64TdjlHzUdL5rMGvg0dQlntT2hpEyAhQ4YLIcIdEN7Ey0InFU6UFI3uxvQ rK8JISD6862TgqZSo9He/LeXvnZ36YOVyeHAWnbC9Nuvp60UoxuKTV4NPoSbVGLD7n9YmatUbJXV 6vcuvV3tTGx0OxhTdO/eg0BGQIj33RjN64/mH8RCUYlbx1iCpVD8SNoFgSPlupuFZ8lR1bml+el6 9bmvivvKC+5VZvaOVL8ebzsSEL3qnPnvIYm2jRC+sRO7HL4JS6V+lsqTkcpzzAxypCi7C1XY+ycT cKdxP/wDVyZ0nALeL48HiD7fr9XPCq+umM4PbE/pwTZvwnLM5poa8ATJ2HX68cfQte3z+ut9DxFK YXjy30Po7rGsosUPDZkt8yZZaKeg8rpNWFOzL973yeSq08wsi+Db7/d6mMWPLdoa3HnSRt5L7As0 DJIGi2reOmCX8ub3b3eqqn0tNeGrw+tXMg3rz4vn/tNkYTuZLc9+8ti++9bxn88nw39W6ZFNNv5a uWrsnibZAf2oUty6CwqZW6KqvKK/k0zOwkGDDGarx/4xvfE67AXzd0mTLBZJMf7N/QikLBRu3htk Hd3cMaQ0W1P9svQn7MmlL0Nzbo+qWtkiyGgoi3g0LO6mgPej3N6uS5eQf7yxMX0ggW6PEqvWS+Tq o+sJ/qEnEguwahFXZ3HDbA1xjt9iwJOTpoOFV1r4CzHF288OxgBFoJYd3YduFBtXm/n6UxV6SNZN xc3b6HWxtt8b08NfXtdhZVIqjH6v8KD/a+HU46jx8zzaxrLoYmHeaXQbqcFp/7Ny4faJSo1wo/Hq ky0I4+8cNoSd+0OFaDdRvlF+YSNZCNHR11zrXoFd2OllzB5X1emejRJuEwF0zNiX7WfV+i6Hb2TC heut6dt+wUKjjhsXmZswK/2uxxupy6ZYPpV5qV4lKzBhirRbrAyFgMbs9hp77RBCIYesgtYqg8bY JQcm6/JOcHObBCi1pfa6+uqQIHQrApHY5LQvO4B5pEvKgz2nmVHkFKw2OgFYd5VKjSTSCKrFIPXv jYoWVGqJMhjdaz69IMzvpf1MUOBfowEiT1CJmYO2B204BeE5C9B84nXBjJTKJxghc9RUsgJGcVHP t30MrQHKCAYrnwS6CrAv6QWeA6DHQFjG4F9V2FC50bcGDtnzuwbMXh9gq5fe7rsZYGXhn6tlzx1f VcfFva7bK1/w4e+yWyUHc9C/RYThLoYczTn9c6RX6pfP1/A2Hs1gfKg3SylfYCbU8GkJdys2OlR8 Ip+xCWPfwy5pbML+rbYk/9+tVR9hRiK/dT2M4CkliRAlMquLGPUdldm1t76XmW0rKY5et4NEPRLY pJULdgdU6AoO3hVGU0KaUOli92qxaYM0g1ne2Ao+4G1DsQrq+4vjfKBEobuyWHu4S4XoDmU9lWoT JXJ0NJciaO0OchEa/uiNFV+FrARURclYyE6SWhBRFfoRt84RNmEclBxGB5LldBkA1H7yDjMa31R1 jfUwRH3lLaIXqTua4MSwEbor4LiDDTdLPwbQqIpcsxZCZbFRXK3c5ND90s/vfZo4hmy12rseq3cf HPzXaITynfPA+0HEjYASlopH8x5bgkno48Ww3MbyxbHXIa2VHhUaJpXT7UUP4rggRWTxu9e8D/pI Abvw2eLxwRIN5xj/3GAwAAWWU7/3kyWRrv9vR4wDzSXyfKlPygPmWZg9i9pksaqMQApi9amYbeCO jmqnskhsyyYs8zeoU5h1Gcseg+K6sVtWeFvJPceIJ/k5F03dlnoLLp4jtPavzeqMPg7RXLRe8+Fe ftUkmfxubCe9TvdJE74Fran3+2jAaV6OZCewlim2EqAQ0+9LoWUBVnWGC8X1dllN8LoLXqSUSl7l a8ve6TKDqMEAPTd/bllBgMhhaAAc75GVjhvLgUIUhRF6c45HKbEueLRsa9HvVkH811FW26PecOFq gfMLG7X8Ea+2g9M3L3rH+tkOVypiW4qqB5QysoN1ECn0YNx81wQ/VN7fG8ypMfK3r7z0PL5heWr1 jz83vB0Vgh/Mm/g2ZIcb2Ln63ll0lBpbzj7ypDQmf/XAeZPnMtxepzMBl22X9nh7kV6dfvMmRuPX V/vuwWCqTt01NtgXzGVPIRYy2IR187hNLF4jrQ91C6tL2kcY6tbsQm/kk/YTFaGl9eNED8A8rZ60 ZxZKZH/Xpd0iaePIcoyziMwWuCIuLnJWHszvzyDtEJsBwERzTrTgYSs/R+HtQUndwVpjY8Ow8955 t4xeO8g/P/Kz8qnd2So9dQWP8pwP9Y1V+0o9SP9C+gCejT7uVm9moEDpuWj0ZTBXvuLI6N/s0Wwj u7LsBfmi1jsXjsy7yDk3ltp6fWmzV0tmfVB/+iXgwfhzqABqV6+rEZQeHr/a4/2g1NBgu9v9h02x VOM5P6JS9JxI6TgwaC5vD0hMka+xsqw5r1E9ID5gy4ltJSXa1F8VnujnPt+q6VJx+7e9sF+3XOz6 0XgkTcyv2sUO0rTzI/YnN5CXxshRmSvw6RruzClQtPyIf9loVukoi4TYqPq2Tt4Rce2sI77i4++E slWfjT8wewlpugdfa5wyEUyi44TumoQayWEV1ZvRfbb0r+aFiXswIVIClWLJ/QQoRwon/5VfpBA7 9VQyrSEUHrix68STSqPM+I8X9Y5swlRYGnYl+sgxn+KT2q+ttC8fqbb8PPKJX3PD+cAX9g612pNs 7JY8+aZSM1eNx/OuL/Xvn8VZFg8xPz55XPJpcrzb7Mrl5bcTvQEzch9y1WIT9nY4XobdzR98eTf0 7r2da6c+5Xqf8tG755Hta1n+JK/u71HnfwZ8n9LLO1pDr42+nxkvyTR8+j8NBv9vKwRGGkSBxyVc MnBGRLHlfNevAOMEiG4ml9e7RbR2EN+lMoW9hJKqk8YXjHjXGc+zLUBl5iYs7Bx+E3bpa51lYL1W BJn7dJbXpw1rW5cwZIWVn1f4vJxq/uVr5uoEDp/cT6WoLiHI8l2WRJvxy5a8XZD8UgjVjRoy1v+C HvqM4M7u2g46rlqnE0OBMQGKQvSeg2u4lBLIHhNErH4nn6aItzWUNVhXtDX4HL5ugot6bYVSEMMg 1zmqiv9DVMQII3AuWuZjlzJIpiTsbOoa8wUWMr4FBdpPfL4kFxtajVvzyVfhWJplSWk3FxsVMvMd zkX4D2N2kN4it0EtgEt3wFAO2koIORQKNuC+zVP3BTc3YSwqbDFOfH5UHCSYyYH33YvID5aHRgRY RQJ5NQiqxsF73ZXx2lPpDH+AG4TqfQtuIyOkMYqJg2sRsjylkCFOlFpKFXSX/inOpHXWGhr58YJ6 knETxIbEZ+x1Ye4kMO1/DDGBFE5NWe3Ltbx9RcpWshGaSzglxl4O0d2SwRMftRfmr0lVWhYKKt+E ITZh394sjdZ8ETuEonufmqPcrHCXiO8M52ImcCZu58u0vcN8nmKMGrvjfKrt3iVZGaSvatysMIqh U/pi+i8uhgHdY6wL+20J2S9i2QNa6ZW+n95t9Z25IHQr0RyftPUoXS6s9VGudPYqMloPJhB7QM// qq3a6p359QyUAtyXyFEFpcCN7q7dLcBaBkOmhrh7o5Zxfd1e7PQwWvPj/dkg4rGxhKE0WhMtjXEE mTGHmPx2OdTDmqmOQQUR3WewyZh90AI/9y5OiNW6KZRmuOp1V2hp9SfIdP3MNOkNU4UZRs0OUW/h wd+JT0JOoM1qnBTg1gOghdWrI3VEJ4GujvcU8biU3+EtkP36r0S/tH9c1Rybx5YtFVBbIgt25Alz sAJURvxHhhU/J9qt4wsPukbhmIukPKKJBZ0k5puwxUfS+7BjGJrfkNL7Xo7kAFYqIzYO2WYfQzc+ 1FFyeGGuk17rqJF/MfLi/ofDd5YclXLqs9/EjGa+LVjVKjIa7b3qleCjoJRa6a6Y39J3w9XIizOA QJ/4BXL2Ckvp54em5Zp5ZhuNsxzSFHSS2qLmwMNa1YLij+u7rkgdy6vSQbkMFbuRzsTDubJCMlUc NxeSg4FTnFqHV8yzv0DRAR0bj7AR1GmXvrVZDUC2j7mDcKi7ZN8kRotInCKGXbUMyeD61NOXSpRA WQoRX7cYvG9YbLHRKGSR9H98zwGVRn46ATX8j6eI5XNRu5hS1vvZbxPWb/CjuP9p+IkD83d7zxu6 IHKLo8xULoA7K/PPeLIncvd2nhJE2q+frfLyMjrLcopzHf/eTj/SnhceNfYG05BT+/mXzIcG6kt8 YEknPabHI09bmeDsWSKfYHQ2JzIhcjTP4RNbw9u2ie6hWu+7WpIplv4kJYJ4VbIJE6uEbsLUaVK1 JnlUjAKW4bkhPKkfmJAF98XS4Dp2qGx6nvYNQZW64DXUJqykhDk2+i/I+6Z0ZxPWy+WJu2+Sgfwe prz4JKi3KgTXctHGUsc+N7p3o/zbago72GRYfKTa73gpdGj11Ea++KjAJ4js11Kgc9OYhTQG1rKa i88XljeNJtD1gl+0fzGjm3sfdocMOL1D2wnMVX+A2YdNR+1A29AjsQiMPmk0RIdojM0h7qn4ZLta DFCEicvm4A3BVDdVkTLVvJhwVBfeI72ijPAffSckteFyzclZHeBp1hPohtvYt7dHTzeP0X+Tqk5H 0LO/CznapUsa4yElSMLAHIaK07218YgZRpsedJ9GzZlnxv+5Mx1tBSqc7IRGwK8CVCb6J5PLe5d4 ilEkfSiRP5UjfMkYEd/gU9UJdqtLvV8kuU/2RTSwa9Izq9IzNVTUt3p7n9lSc2tLFQwGk9nCQHMM /ozbFXY6KOq+Ed0jhjWWF+UWlFybXvP8XZJfhDfdIz7sgFe1vMUD0YGrr15WO+2bjW/8bHL+/Tlr zQr/cXpA+Xv5q1cqksbolhWGcU4OnvPZFbjD/db3R65TxQfgybxvp0jSiMT/ie8u8ZoIpN1i/vxP wQiPj2V9RLJXlexmXbG9SWb5u9te/HXxa/lY1DLy01+apvvzxlzDDhlZTn6xjM1bqTEeylcA3giE GN0/KxF4tr9DiGGH5cQYq/nzKL7JiX62bABQ8p97nnONEGmKw0fwRwf+CUqW6sL4JXnDJ7f+08Ic 32gmh/28US/RIbh3u4BqXlBgNWQgCM4Bw1mYgyOWsfTI7+Y5RD0+U3OaoOM3tlw+GY+PjeVTEUtc g+wTiKEqXNJrQqzYphbXqn2pNdEEtUNsIjVWG0inl4ZCb5XGoCComC/i2gQD7tlEBWGnMUtq3ORw ampB2v05rIpYH/KtIqKgcDJgHPBSm5oj0Tw3Q7gyxh/sFBa+xfdjVUREX6HozuwW0CElbs6PgX2y qO3+0WbZEwjloHTECvyhHcRjYI0YCyKzhH6M41I8axvfc98egYSD+XfOgxgarrLHfHUonShTBdWx BNg7lkf/bX5v7vWj21oHv4w/kZpbG/4vr5bcY4293GZFNz4HVIrVv7KRyrY/hrEoiS1ahsl85Y1a dBg/w8rYVNYNEKWLvav8oB/PWLQENwMDmUXYLEbQnEiVQAmakFjhMMdA74q1PmoOcydRZS56CxEz bGDapYNIpzubbwP9u7StGkxrgJjKPDtjm3j9edu4Hq/vXarGSnbeu/iOWql0X8TtahcFv79r7VKP OF1UP7jrtFryQyQdEzWki7jr3Gkl55WLSTPXyXqwEPiuPWEhmeOQi3yBTGjB4ushfRRHROXpSIzE OEhlPc7mc3gd0f35Bu1bjmMfeTs2vH8cYxmpjeoxV+dCBWsskhm0VCWOHBNfqCIc6sdeuqk/wx9i rYek0pRMn4kSAut1oUOCXHodnptW7SJYE6uyhLy+aFhEsPIwc+4JWfubbmAvV3SbEf0YKuyHg01s 30XhjMWzaeK58SsJnQarZYBBXyeCRVNn2ErdnkeJJ6eFqGF0CPlzYXd46guQq7BYfl1A9MUozUs0 yT27pf8bCymse4q1QPgyvVZ8YkKCxmHlmlGUYMwkQw0ccGZAx0rFu6FCwVBGMGLk8WgzdUZVJ0vX uhsqgMsvqkgGAzZhn+lxFYvtuvVZFR3jXaaRJXsgau23YBmpYYaTuME7N0o2YZej7yB/4HAjMRHK EIq4ZBZT6Zt5yiZMK4EqB4lOTJF/y6JthaxZvdofOoBeuJJkpD0xs64lWkMXw+tTda8k2gERhX1n yFcICxJNs5ZaiOUJ+lpe+BxzJQdtWf58Jy5227bs2gNDGrQPhGyrcwP7CQVNeY7aGrixPgfCq4H9 +c+rgOGKs2Op+KsJFnFFnwwdf6ErUnSCTrItr57WV32qo1RoD3ezTq51eGGwNeiCnvuRWkrfeJrB zGj/xQsoMuS9voMYB9CZy2AF8dzGC9Ju8XWgdZlyieveK9pG6Oht54j1UI25t2OBAV8ojswX/RSw JHU9RthNgetecQiu/b3YtQryWPDrGuF5gLqzHYKNxD6kxXiXvTTvJf8qGU3aRisj+M5xxOplAmwv jzKLcld+t0hSbQGo7OVjfwMTH25XQlKdoDjZQk3hvTDvkWvZQJ0CzClirbmOoZ2frO8RY0Yt62U+ JtX3RGejZMShtdB6P9JqRcSFS+RY6w6k4dk90FY+U1nClVgPSxSJFhAKaO2mIZYtXd2FuVlCMhcu ME+2cnVY6CNZtr0AsJz6nyB3/rxU/upaotQMqHWmkv1EX2nOii9W/dpNMgH2cyhmCWRNKJpNhfZV LleATb0BNsk/ZuFViM9DN8shHTYyOi1hXwNUCJp9ZWMUG6HL/Lv8ARESZ5vPMZfBJZZggFbOuiiD rNZ8zJHtDl5TuKwNv6Otx3NJAISnO1KedB5eP/e6wnw1894rg/t2ZUUfHa1eN77hqNwd7r2oEewr /+5Zl9cholWUq+0ff7kpIHKqc+guKIcKtI+6ajHaVB70i4yR4gaufJRusi20KAxCf9VYSfqDjDPc 8LXqHn0Nnu0dz1WQyyhLeRi0HLMSe7Zn4+S61DPQXUdJb7Bw6ZHuadLbyIyOzkI1+6ZJLAn23V1y kGsomU8P7LnGa/wnY24Tducq0aStFTpTUN+PyrCJUfLiVEDFSJ1lZPxk8x8rN5PI6oQOrylGSM1G /vp+sRx5umyVDJEBNxfs7RceBP0Zv1aCVLzBbxus4qGThz6Rdk8kPO2SZvAeNpQDXmBYVEeaVknR V3MWhcQ79knM2qbQXp4utlOrrtSeEAXyXMEmrNlAyiM4chp2F2kvaTbYCroPLPArb5OUI66FNNEn KaAoEFDfhCl3aUF4donuZJfZNJ6HIkehuMb9PshfwL+Q1l0Un/Ho+oS3pMvm7mOXGS6CkJ14hUSB Tv07o6U8/0GrJbfGvChXZz/t4ZhO5zYyHO0G12P7VAkHlhsIUcHGaofZnv0uMw7+xUnQQOWdQ3sd AKOEk7axbdu2nYaNbdu2bdvGiZMTnJg9se02dhon33fv5v6IO88sZvHu55nVTJtw/yty4mmVv2xJ eXYoAucnLRl4PRLH86nVPJ49KjWkqMpx82iVeA+JKOShdsQHOf8z178Nwoz6+lotXztaGZlV2Ef1 CpixLYl6x2AL1P9vmXofXVV6zlEPux5Wi/arcoeVdIo1jK93UAP2ytSCEP1DdwL1dO2BJQQY1ijk 01giWL/oipgkFthqVaWar+BMnQD2Q5Huv+ZAr8dr58FlpM2rQkQIz5JqNrVw6phL9KJHutJlxfVX wXfvzLhdZbqyq2ZmnX4tsrK5rNYZsaXGe/mSZO5o3s428aMZbZoYCdSHTsXmzpx4zXz9awFM7PeX 61UoCfWAi6Ord/sGgC7ntabJkFKaypQt38GS3sUR202cm6G5vW365Pg/L0iUG1VW39y3CxZSsb+E lF/sewX9Jl9ImyJzyGP447v4mj9w+3jLTZd61e8h1BMB6CcvR6V7ji/3iUJgrz91s8XOc/rB0w5o YpHgwC7q8Gsrbufyf/4xNBTcA9YSXnZkRCCfoL+ZT99Tm9G3lU4+uinY4AinKCPT6r5ezfOeCtej xEUzCC/vRnZxUiIX7vvrvdC16YBGKF2yR59Qzdtr1Coi18goYmOLvyTJac8WCWMsB8R+6Gn4W8RG Q918QlQOksqHwkZe+E0IBK1ZM4+ZCzblhVfyh409l0d8brw+MLvVfkzwoIVa89xuWrslxm2OAZTP 6IUTVgSMKnIub3UdFDzwA7iva/S8J8t0b48ge5Qu0TyfH2HihC2I8TUK3XGoorz3iHTNcKSBqoUX AkUv4nacILD/iong2C7NiCIFJgYZr3Goi+/JBRaDMs9rmMtJQkrBrlf1BFd3kOzZkdDEHzJeNoji ByRJN4uZDq5EqrlKHfsW9nlytOxlcVjrgKNTdJUkTzv2w27RSbXSleLbNmEVY5SZh85dORf74RKh QfGsmJeODv/AUaFvl5sbW/hxxONGeGdGs8A2OLeAHHLRpjKuEZqow93zXfeefXo7kXUFjaGPzyvM pyf78bOJck45LHWS7IOVXNdcdAhyeQ8Cfgx4oR5NigRlYCLVD53J8QUsGBSNbqzNsbhY5hejQbU4 5z769f1CfJShgdhVFNOdAuHInRIHPIx+3nzVvoAhuyGLubp/vc0SPioRPGXL8RzXVieM2wSj44K+ 1rbPtcvWpexrHi3cpGKxlUkkIpOc4R8sjDnTp0umksWhMkrm8gmrE5Imk4nsgpc0RhGiER8C58NC FotvLJpENb8AQqfDoK7dKt7BMvPrxF4DGnIZ7fdRFRcs81aQBruYWvoFjkBoWoEqMClYDkqQSvz8 zCT4yccy0d8qBKvUViqT7CpKlwSmIwXoUq9ZicwhLokk/K3bKk4zEVvA171NnE5VqgoZrs+1/+Ts sYxztPEYzUC2ZiZ1IsWvCfe7rOcj9RIkJrzkbxdxtPYj3HQwl0EP0zrCY+SRsxRmDDoxhQAQhfKJ +bYDAxxBWzNz8IBjjraX3xM3+MYiUxSmiy4qKfLMBqfGiFoBI8hwA9RLONSo8UvygvZm6faZecLL UCis6XhkroVziPW97KPpG5rrZNy7IZgfNC27le3Bfgk/Q9AIo+JvmbRIN/QAvdG4hKH8XrkUW3st Wliz5mxae2N8v2xMe6MDIINcZ7YPDfZjZHsKfaegsEozxaI2nlX5Gnheolmm4DUjiQ0Mv7gWxvj3 5BZfTYaSIQotqedNLrH8xJceJa7JhEgGsmKFDSWu+jo6fQ5IbukWVMTP8Y6judTCFBbI9NHLlv8U r7XMGyiqkkuLw3lIKhCMxAeM6dlrUG+IOUGBH/4RRRxLLEt0jZOkUV/fncJ4HLkLqi9oKWzPIgKK OTNNndMgrp4qjPtc+nC4PRRTYlqdlA+ONgBLwkwerfQBI4lGhGm6V6sXkIudzUZuyJs65kGvIpe5 MNpq6x3jGL4ZzH2xD8gLUNJiYqLlT0qksqTpwaoVtAa/ujlPiaT4v5ErllNQudssiKGekvaCeZ/I gCcef7avM65f/iJcuKV+CNgV9HEz+F2aaRK+ylXLMcXjC5BuVt3qrgEpXcStpGt7n/VXO6xh+btE 2OkB5JaeJ6wkRHoU7PT3lrgxom7UFTf1hqeu578h8/JqXMvxy8trXYODxs93bln3sgJP/8+fv7sr omOl4QcgjMk24oMXHImmbCXj8GAhnMk+NzaHvS+LWZPTWmowEI9ORuwuYEN5A/xii/42MoX/fWp9 Gj53wX+GtVj1T4LrvPTtxMtO345WbXc7hfNzqCFNSTI32gqrTD58HRP2/pZ7EuzVTdM/2ke/dDxh iSTJ4F4fgLarrafopTbGWCrI3XLUYCO0MlzSTnWW9631tFT9AV5HwkkxQ7dINXLLcaGvg5JPVcIG FcYWA2LWontShHEPFhQsECIjO216GcjsoZFi4r9hc2jIxyX9+urev9j+g2W9lNZLLb4DMzAKM5tD /2kbV0d/5iZ/giY8b3y8WpbHBECgB0b5DsFaDA0h+9ULx8o6gf3w2DlwTQw4qRWVifh5Dht5xTpQ /KeeWT17ZlCCBR0+oybv4ttJfZip+9KiuS+WYI2MZW9IAouiWchynT/qDHG67Zoa9kew+FJAi8ML wSjm5V0fbpnUNGSLwpNgIo0lM2+QTxpxlm9GjI+mCedu1xxXsk4shIK+4fmON2aCcvENKTpp9nu1 /pG402NcA8XToLLO4J1cOBQ9ifbFFkkd00w7lFOuattfecORK29trOchrbwTPHx4IWfBxiaIQL+c NBEG2uBsaI8u38gghLwzzxG/hjwuprQs9WVYz4yb8PoqhOdIhSXo5hFyJB1fXCYHOM955ME794sf 7/rmchXtt36N+a9hG+eZxyFAHAfMrKe/pgibs2VStty1u8pP7Y0FEASJLSy/vi9J0CcUojQi73Wb ePstIGRgyeggXKs5bffqhGoSEqvqGljq8HI1dPF57wzN6AhOpnK05DyjDw8mz9hZi+T7cn5t+Tk1 amns/NL2eezioFb/47/NcM1llieOFoZfrE8rT+lbg9B1VUPPEuaThfAXk8uYHKaNOTItE39i0WZF THUMikfAH5McCtXXnF4m1WRSyUapSBNP/GdcgQxfzUUd7ckdN/aTraDPSF361ubVgw7mN0ueVf7N VWpbwaGdVe8uwivuoFwf/H/qquBzViG3TLt6HbFxa6+gtrcT513/1mOOJdlXeXwsp7fG275tlGbl iiIz/cGT3pMOLj12E8pTEFeygZdTFeYx1pMvMnGAU74gYzA1VsbM7BXSbisKNtgAyxKz0leaJfUK o/WM97hSoVrknx/VWnSVEN2OOvcpHOXvAeB5266EexYrbef0HsVaBEe2Z6ojqFiFOQ08s3FSSirW EapUFaLqR2VLK/a5LYC82INFPlXTZJgYfSuq0poUGmPPifa0zv7H61pkyKU/f+HLNMcRQWilrBiG S1tQiWFH/PNVsUTpbtkwViLE33RoeJnsN1cNlV8DuMHNtGk8aeKAs7k8R+DZKp2KS6qILYbr1k2V BN6uRlrkzq9lxzCnng34HM0CRnruevasInMWoZ5H4Ln2XT+ZQc36fchwjTnBL3MojMALXd1LCX9+ qH1rqVIhePMzHY6T4XKF8h4WUKmQV02Dumzw6o1K9apSm2nLKPQoDigHW0ZBrz3L5cg39ama+zWN 6zsj8eC6m1HxVTVvF3KR4BMcBLijtngy5xxDOGwsQt5biDnYr++JPe35zRXCCGqHdj6vCP2t+rOE HSDIFLvc+k4qG2txoq2QaaOQQpdLI/XlGjVktnBhT7abGbqKntGpIMfaVPSzwuXXZKxwU/2n9XT6 BhmJaL7N3MBaQtU2Qj8CcSwITNnLpYEig4RfTKGtk1R1fjYmXsWo0ycyjspSvRq1sgyts9wjvXEt 5XAK3v4qt90j460zskek6RYmpQTsjKj7iGU6p62ar+hw7kI7shiRxHLfzUeU223Vj32yKf+Y53sB IkQI2OzLO2HqIxw8hIT85H2Iq8a40M1H5l4ZtQNoAR1d09ecc8a6AXgrkgZGJGqYUbXm+r/s7Ryo Ih+dzj2QzaG8KTNX72jEq56dVljqYrbi/IwBNyGLbbfVu+LaWrbjqWo9EutaW6JaVblZDhW7MhIg MIq5S7sK3Mhzbldre4Pjj4YRWnipLq8DOWc84cwvIar80gcLIUh+9MMTSolar2OqWY91q+XjXFzn Id9vGXkhuAK/O+eEVHgrDwg450DFW0AhdtP1se2KTQIkprFzeI4kIPWUDhnzk07NlnDLMeSOPhnH dii2X/vZ+HBvVzU/9DT3ooSNB5BL0+/XvA/rYGMANY3R9c6E5zFTKURitd2HXZcxfoWGU1NSj2N+ UKwT7EnrbVmdEfUfdA5FvxpHXyaft9+7+PCrxmP4yLQdsnoUXJuh9Vgc54Z+DHUlxjeS16OPKEmx qkUvjD1iXo4lFRvHdNYmewFtvPW6i6Pe3hbvEkt/Z/TH/jxxK6XZkQiRfgu09Wwbep7yHNfKDUWC KYxpC2psoIVVSKybC6CdPG2wm4aD1iEZZ6XiP85KWX/n5jCelHBbFVvOD42jT0gfP59HO4MUylGP YXur7H+GAeu9ShI3FVJDw0rs3JfwVMfRrmSv+klGBZVpxiZ1myPgdM4UKa6J99+jB4QeIQmS1/iY Gk4cG5guy5WKJfQCl31woh3kFQQzynuC8+l4U3bIl3rNQM5h+YpTSAwXfcqPaD2+LPgxUWxsEYad ygy1vVpvAo23AVv9KW3PQVQNRj/PtRZeM9oC/zcGKS50pzeIRkfK6i609ZMUNG9JGlo3njBvkrGv pbRN5iJq47uxjr1AlceMz+Mnmipu90dvSNjH5Y3+Y1UU6pl/w/LXW+Igr2H7Qdns3SP+JLXPZTzw cFE2vF3OlWuqieXgvgJP1cXQE3TnMoaIJg8Q9eMwL+nogHdNYc6Kj3flXjw6010beAN57S/E4FfX Eup64FlYou2Y1/5AEILLz32mqDv4SQVyzugwtncWV3CBT1yyF0sd+gR+u8u91Vhr++2kpDZcRFgU mBsxagUopxstTWtTEUTWkMmayPFaTm/CSw51a9v5I9+PfNwhnfbLNsW+Ps6/5e969uhWw3FDodBh oRL5jpsxmxNqyS72zY7pTMBjwTeP4PiMQIm+1nuoqbHoKRZXXQ5538XVp6yOR/+MF+yYwOGMkgGj AVwNUFSrcQzMaBB9JSxDrJPEvLQezZKJQn6JkK0xKs9+uppaELl+h3dXxNl6p1boqSZboqZ6R4bK pE5qIGv3s6vGghzs8uoAHWit/VEKMggAmkPcm1YtRH+hKo1DrcXxvzppkkTFNxZ2UvLUx5ijwXvp Nvt7trE3ap2zS5nL/cEZ1un7ANaKWPVqykdhlmf5dgVdq2bvU5WwhgCKp90MQk0w3J3DmKzAS+oD FlRpwKF18my9p7PmX5dlYQop5L1DX1aTLQMAgasZAUMfgUT7mrN3IXSZ/H+z1FcKBtgmMGTx8rLQ pt7hj636or63ZQ9eB3u0qiY/66lWr7s5FqbDAfx5zQWKmUmfqFDVZzfhAiidqT6lncuqtyzS2phw Jmic+K8PVNhV/V1rZgZW3xdBhMfTkIK3Ub6q2A5UAP0XWf+c5unT/bCez6LDRJa5oOhtVgeMo5V6 P1Yjkd5qhoCel4It1JlFS4BF4x4sb7T0SvqQsVuuQxJ3U/C/1N34TDuh2b8m7Qdio3jE4xAJiIWB bAwL25trz9Y3p2C7w2OMgfKCOtZCMD2hlBZK0FeT+r153Rx+B5SsuNKHPyryrSe27jYX287Vy8/9 jAUrdvDmmcWtZu+gsujoZtdWMeFsVhrJys+Dv8gKfoGbEiY2Kl1BFHEk0BjIHfnHY7X/9EMmOngw mvCBLKoixoWY2Ty/bES9kLKvpBS7GM7ip63GTjPYwaXuEcpWExojDYHzbBrmJEbcdytmu9tu7fhx EqI0AQ8h4UIKnMLjip0wYgFstJ/KOrM0T69GHPfESPDlc8z9udKUm3wHMB0Tj4dDYtsNvxSs1NgZ UFWpMjvh6a/JE6uqKYOsD1jZ1h/WSCKeDYyoZTyXhyGx4e9BLBxM4byi4+Ivk29NHqt07e5VR/Zb bQRIo9CScAr5TdC1dU23ULEf8js5WRZJDOsFLnNymlSWh+wcu6Y6GuGNOfh0Hd//FrtpmGGwMI0H O+/8U0iYbT+atbOCE7l2+OwgLORcXtKYresCgXJpDyJlbpa0hj07/ih+UPErNE+Ril8YaN0h8V/1 CLZE1YdOWrjQE2XG9J4KROWnqE2eDsJnxXdJ6M7mKHWy7lkkZ19weIZUnOQWurteAvXckSy9+JcS Ip9jXyNjmbgiF7UurPJWkBivGR7kAB1LSuKp4TCH786SdiDWSUnXXQF9J5WSLGFC6fv9y1jPFbQr 4SAE7JkJ4t92TDw5ca+M0FbDxWCthq2e1W87jIY+ycrYGvHEUIlOvAPrjOKr0gbTLYRW7f3myuTV +bnXi2wrLG+IFKEGBeW5Zyvh2l4cU+Of25kIAWgL5OazjIiOS6dJWm6pdrg5lrgE42ZJo2I4jDcT TEIv37VdTb6xY7aPaI5kgrKs8CniCv8VI/huEwXZhGMA2Vq7bNU3z+r2IG3a0JiiLHt32GK/4eLq m46tALYZ1576HvaU3M8SMcoKIY9p3LQ7kmx3Kbp+gNobHL6tp3Ll40gp1/MjZ6D3mt5nRgszWpww Nc81WkseP661a9vU71lqTrzS9Ju/5oDpGIc4OYybWPfGfpOyeP1Mf+Pj31nEpfMkF8XUleM8iIqW 4LEd0Pw+ALg0aKU9KOOp7oWz6V8TGHi2yFN5pYGwN3FcJRl2g1tYoB4LF/m9fGPEb4glIBBhHyBH zAX1DUKKFgJivohuZBTf/W8mxdLO6VM6Wi01pMMehf8skKpBzeVxKkFYnLygN897nu5wq2yNjbNs dMoL5Snt5xruTCshriK4/sLhwfnBdNYKRKHmO6yU/Woupxh+gXp3hs9PFjCTD03FE0WLLOZ37/qm rYB+CvnAXwIWC9dECwyIH3po0rQJepZgp89jh3H0j81iVDMhiaHnwjJt0fdbdq2iXE0tiuZ1E1nH CkU8mDNFbUk9aO2LsnRMQSDaGxXg0f+V+s+8/V9OmBSWLzDqpt/HKZV3siaWr0E1p5OiZkJbw5qg u1bbtKA37SWkOqK1PYexMrmeeaLIjU3GiHU2MJ8SVRGeQjL+LW6WsqqF9HtCQnvs9U38y8uW46Nr Sd6QbYrW/CKD9Q66h0Q1+/TP2jgpytIpHlyojuvnVw32eIv/OeTxconVU9T0g8qWqKzyco4+LzFz 7b/srbLcJlC5z/p3TLGtMl0smUPeZPxGqQjlZqMuKNjqzf9wbOINWaqR6J3ybkZkawsNWTOsT1Ys Iv0DILGfz0ISAVZ3mCO6SaF50tCwXICGnhGQF02kHZPCc+a/BfNaO1GEdqq9SuvWz8RGoJ7dUiY/ H1fcIirEO3uJuOF1DXeFedT8RENutHuRrCwPi61TE67556qMzTtITLE9eSpXfPm4NPXbpRuhTi+z 1qxDwxvvtecqYB4sfN8mtpiC+yE2+UjuA0K0qQC0blp9bzhWQdoK3+G1HoCpde13dvaZxJT/PuOq RLOvIkFcKoUiCMftJ5O8+LMpQj7fbm84DTj8noKaPp0YVfESwXADd0NoUknE1fM9baSkQG7RY3fI /dfl+/tvW68VK3ZUdROZYVouUf8kYaT2OsyGzB891Y9yeMwrEiiibxwShVREfJiIVC5zlYJqExQz t50XOfwX05m0s3VN0c8r7xbxLVR+blu+DIKG8unNnTiO8eVEjQhQqJy5e4BnjcuF+nFUTVuzOlgn xMIikjv+HQ11PSq+381ch5Ik5COIrtLfIWAhtUURql9IhG9zNza/rnAk8PGTmaAg3q+38553qxCR LGixREwa/i30lV5+EqDMBSw20QLSarjZUtkRWJCzdE7/ECRgL5oGrMuxM95GT8E5q4Togq5tS4i3 BenD9fbkmtfNkXB+9o+Wsk5jyjbtcCdvfdKKginRTczM0PunrJtb2cNeXL9fYSSGqSpPlaoPuSiW P3J8l0k8D31J/il9WsdHftytqWeATBqiibQ1ohALPztz6hgNd79pDpeJ3M7TMCTDbbviGjDmtd45 q6KXiS1kCGK/2QiiDulXk3qOM2DaiS14//uGsHFfMZJqo5C89Ib1yJYElN7t7Ajw/+gV3bvd6rUX oZ8ChpRdljQmZjPevWX7Y0cOt/mJT5oR6/iht7BUpZWkenEqLoTY8uggOjCz34mt9OJIVlOwQIy2 L/uPmos07FPf5OMwcrKWaBuzjgRYniXdkZvioXb2Jx9wrgNLHJqefMWeLfkkNrDdEl2OU4a5AB4D w6HCsn6XnPK6SMI8VDz5Mh0EMugciRu9y45y9hnUu2LJkyknrPwzzfUsB7GEn0vNpcluRvkzIbmd kTlXDwk2cJ1zjUxNoINLROJvdUCCkFPwSsk19By8CGL7Iop2Rk98AyKJNGBSUDoFCiudBozmJZa4 uVwmeHjtfGnl7g4A7BH2giB+B0GdeziCGI0wTLyfyUZt6r1/8Yl3AjGGSyvO8n9dbI3qUkefoA92 T288+uSxzhKVlcIN6CxO3PTJdaGYpqZ/psSDcqT//JKZA/i4kyfBmp3Qfre5/3FeG66UEP5UiwAy m/nnofGaos8ltolmu6vSBomo33MKVAmdLw7fDHBXi4HhMLsC/jpUwYbLEfXmWse84oJ8Qzs7dp1B uk9lrn730Wh2r+XCALIOrQwNb6t7qyYt2d176LapDqHryCxDCfBlDZRjllBtqCIXRo/FFUV+b1MY /QBqlfWqP6rNTcPIz3M1VlSW3DXosMewCSsECjJTue9z4cL0u6cqXy4fWVrB7k84dgJsMwJeXpyH K6QWCmA3Ff80JoUZM9zHFCRrcf7Bi4qRccx4qn4QQKhh4gjYSQwOmFETyYXoXiTAajU1+cNBPGfv yRYyzuqGTbbEyzrwvabzygPr/RWmUCqlVd/77FdCZfACJsMW0HP56f0YOze36CCpa5YIkpWKdONv +6KY6voRk5jcNqjBdt/y1snjyb0PlH6eenKHN73cu/17jAd5hoKJt9feRVnPV22hifPtiq0uM7vU ns9v66iYhcepOIMH6ed28zI05B6JC4LkPnS+ZKPDkTENH7nt+G1/5eXiQj98e1jIxX/nYeM/Uprh XQo8PIidiIpSigNffMhBoeUXbPIq/23uT7M8XOChr2HpHmrpcsQJ2Lm2TOTPKuL5j+YOiA+z85ek sDRFK/NcTh4LdoxQ84gu2g86XfIVrQ0t8LUOwX4yHRjf9skgm8HRnwN2f9aqF8D1iFFyUEj55cQ2 8eN3OMOyUvSsad53CPMq2NvnqnwBFwQ8thvmg0UGSfkf+1hPdOGIxzywVGpa1RwXSwavvrFF1z2f 295XjCtJ1stkc4RVc/Dqu5hmS/19XzRWIBHYXR48yQ816iCSbctGheVEXHRFxKPb9rIXq7SU+I+U Av0qY+YHEbOqCeXtkEVzlsgiMoSgLPsCS7BsVHGHMXnaB14/WVGg4WGemgiPbdUkSU7gmGVJv9gO 6IbDfLBfTNj0E69lYJfUrOldHfEL6Y5vpYgsLjCL0LmT7h2PHiI44jlo1D3Wv/AS8U5kmtfc8OpI uwwvdDwyDixx+IojCGr1XitptoyF3aHJBxzvYFjcfmbTOGMzyy3xKkCyIXmeJrv4h34N9bY6E+gQ yc/D5kOwsDeqvsfnRAhWBQZmSwDewaxxAV7Zg+azha8Ud3p0ZC0lKlpBF517OpFndft36GTOCZIT vAYvJIfhM0MWnMA28XnIYFhbc/3GhSSXrJmh9hOkORzSeoQPmvO25cB4DAGE1aKyG3+skDIq6TGD +U82pQdGfQ+EZRdsciIuY9LDC8T/QnwIUSqmxMgye7LNyS5nYyJjcF/tqD/yPhRgDcXhxfJF/Di+ hfLGYEDuRFMfSAXG2ic9V94X/SbGXVtfAc8s4Q+5bRKbR9gT3w1H0kzlv9glEZOnpZBE8qrsRLUW /X3zCb29W0fRIsVIfupQkuy+xRAwmOA94v8b0+Y1W+1L7iXD/LvAOvAaTE7EDgF88Cit/OCAN5nY VsbJBmksDPJA3lsB4YBPpx6Pna/OD4rXQfUtTnSlZu+f1DAHVoQpCBghX9c4W18Y4lDVEGCITkh4 CIFgKojXrDeM779Q7ZYxPra40IzmPu8yQIB+34+gzk8Woy8RiMckOHiI/y/6DzglBEA= --_006_A2C96F6779E6A041BC7023CC207FC99418F0D7D4SJCEML701CHMchi_-- From jmh@joelhalpern.com Mon Feb 10 13:07:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1988A1A087D; Mon, 10 Feb 2014 13:07:16 -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 Xy6V8K_l9quw; Mon, 10 Feb 2014 13:07:14 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E52AF1A0594; Mon, 10 Feb 2014 13:07:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 092A7400A6D; Mon, 10 Feb 2014 13:07:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B07A2400A68; Mon, 10 Feb 2014 13:07:11 -0800 (PST) Message-ID: <52F93F81.1030106@joelhalpern.com> Date: Mon, 10 Feb 2014 16:07:13 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cathy Zhang , "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , Ron Parker , "meng.wei2@zte.com.cn" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:07:16 -0000 While one can choose to deploy different service instances to handle different policies, that is not currently described as a requirement. To take that further, I very strongly disagree with making that a requirement. In the operational models I have seen, that would complicate scaling and operations significantly. I do not believe the architecture can or should prevent per-policy service function instances, but it ought not require such. Yours, Joel On 2/10/14, 3:55 PM, Cathy Zhang wrote: > I share the same view as Reinaldo. > > I think each Service Function is associated with a type, such as FW > Service Function or NAT Service Function > > while each Service Instance is an instantiation of a Service Function on > a Service Node and is associated with a specific policy profile/set of > that type of Service Function. > > In a SFC admin domain, there could be multiple Service Nodes > (physical/virtual) that support a specific Service Function, such as FW, > > and a service instance could be instantiated on any one of the Service > Nodes (as to which Service Node to instantiate the service instance, > > it depends on load status of the Service Nodes, network proximity etc., > which is out of scope) . > > Multiple flow chains can be associated with the same Service Instance on > a Service Node, which means these flows will be applied the same policy set > > for that specific type of service function, as shown in the following > diagram. > > BTW, I would like to suggest that the draft adds a definition for > “Service Instance” to bring everyone on the same page as to its semantics. > > Thanks, > > Cathy > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Reinaldo Penno > (repenno) > *Sent:* Monday, February 10, 2014 12:22 PM > *To:* Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn > *Cc:* Paul Quinn (paulq); sfc; sfc@ietf.org > *Subject:* Re: [sfc] Fwd: New Version Notification for > draft-quinn-sfc-arch-04.txt > > Based on the definition I see this differently. > > The same service function could be instantiated with policy-set-A and > later instantiated with policy-set-B. It is still the same service > function, but different instances. > > Therefore I would consider {1 below} one service function (say, NAT44) > and two different service function instances, one that applies > policy-set-A and other that applies policy-set-A. > > *From: *"Jim Guichard (jguichar)" > > *Date: *Monday, February 10, 2014 at 11:12 AM > *To: *Ron Parker >, Cisco Employee > >, "meng.wei2@zte.com.cn > " > > *Cc: *"Paul Quinn (paulq)" >, > "sfc@ietf.org " >, sfc > > *Subject: *Re: [sfc] Fwd: New Version Notification for > draft-quinn-sfc-arch-04.txt > > 1. A service function that applies policy-set-A and a different service > function that applies policy-set-B e.g. They are two distinct > service functions. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From jguichar@cisco.com Mon Feb 10 13:07:44 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158E31A088B; Mon, 10 Feb 2014 13:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmTjKmDKWfUg; Mon, 10 Feb 2014 13:07:41 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEBF1A0869; Mon, 10 Feb 2014 13:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47738; q=dns/txt; s=iport; t=1392066461; x=1393276061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bOFEAr3GV2nu6FxJ03T4p+Y7icj+sKDQ1ZP627spEa4=; b=QB3kK4f5smj6IqbiJZQRCEkAgr3XrxoiVRaNgerTVurhls4b5Y96dVGs gdJF3oNENuef1gwJFXRiKWHXNqHdcKYCG8uiTkYxI63lLfGKKeJHNnhGd gvJAAp9i9hVOOCMYaJYvV/1gusHU7d6MHXKk98aLR0wD/Y3wcRVx1kLRS U=; X-Files: image002.png : 23430 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAD8/+VKtJXHB/2dsb2JhbABZgkhEwHOBFxZ0giUBAQEEBSAIAUkCEAIBCBEDAQEBBgEBIAcCBRABGhQJCAIEDgUGCId3yUAXjlkJChEGAQSDIIEUAQORcQGGOZIggy0 X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="png'150?scan'150,208,217,150";a="303146697" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 10 Feb 2014 21:07:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AL7emW019698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 21:07:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 15:07:40 -0600 From: "Jim Guichard (jguichar)" To: Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzICAAGcaAIAACXsA//+e1uw= Date: Mon, 10 Feb 2014 21:07:39 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/related; boundary="_004_ECB9F6E791C0448BA5136E2D79462C86ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "sfc@ietf.org" , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:07:44 -0000 --_004_ECB9F6E791C0448BA5136E2D79462C86ciscocom_ Content-Type: multipart/alternative; boundary="_000_ECB9F6E791C0448BA5136E2D79462C86ciscocom_" --_000_ECB9F6E791C0448BA5136E2D79462C86ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_ECB9F6E791C0448BA5136E2D79462C86ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How would you represent an instance of a service function instance? Se= ems more logical to represent a service function type that provides functio= n based on policy set as an independent service function.

Sent from my iPhone

On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as = Reinaldo.

I think each Service Func= tion is associated with a type, such as FW Service Function or NAT Service = Function

while each Service Instan= ce is an instantiation of a Service Function on a Service Node and is = associated with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, th= ere could be multiple Service Nodes (physical/virtual) that support a speci= fic Service Function, such as FW,

and a service instance co= uld be instantiated on any one of the Service Nodes (as to which Service No= de to instantiate the service instance,

it depends on load status= of the Service Nodes, network proximity etc., which is out of scope) .&nbs= p;

Multiple flow chains can = be associated with the same Service Instance on a Service Node, which means= these flows will be applied the same policy set

for that specific type of= service function, as shown in the following diagram.

 <= /p>

BTW, I would like to sugg= est that the draft adds a definition for =93Service Instance=94 to bring ev= eryone on the same page as to its semantics.

 <= /p>

Thanks,=

Cathy

<image002.png>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I s= ee this differently.

 

The same service function c= ould be instantiated with  policy-set-A and later instantiated with &n= bsp;policy-set-B. It is still the same service function, but different instances. 

 

Therefore I would consider = {1 below} one service function (say, NAT44) and two different service funct= ion instances, one that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A service function that applies policy-set-A and a different s= ervice function that applies policy-set-B e.g. They are two distinct servic= e functions.
--_000_ECB9F6E791C0448BA5136E2D79462C86ciscocom_-- --_004_ECB9F6E791C0448BA5136E2D79462C86ciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=23430; creation-date="Mon, 10 Feb 2014 20:55:26 GMT"; modification-date="Mon, 10 Feb 2014 20:55:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAt8AAAHlCAYAAAAtA5CSAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFsGSURBVHja 7d0NzB3Xfd/5B7jTJ7f35skSrosKXid1N86WQXc3DDZBmbRrqECcZVa7Cd00K6JubMVwbdZRAArZ tbiovI6tXTG2V6bsQmZkK5BSKaAcw2ITqaaqrCxIDkyhss0mbChLskXZK4mQbYWKZYV6MTL7/O99 ZuacM+fMnJk7c+68fD/AQOLzMjN3npl7f3Pmf87ZiAEAAAAEscEhAAAAAMIgfAMAAACBEL4BAACA QAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAAAARC+AYAAAACIXwDAAAAgRC+AQAAgEAI 3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE8A0AAAAEQvgGAAAAAiF8AwAAAIEQvgEAAIBACN8A AABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAA QCCEbwAAACAQwjcAABVtTaN4YzKN5/Ot5tY5n8XRxka8IUs0C/M60m1O4ulsK+677PVE8Wze/9eD YSJ8AwBQwdZ8Hk8ny5AcTbesX88tJUF9FlX/nWZeS7jwnTs+yg1GU6G5rfC9yt8WMBG+AQCowCd8 J19XW7PVn9XWN5vGkxG01toCbP44dT98V/nbAjaEbwAAKqgXvt0ty4sSloKf0cpRHK2t6c9sf30a qT+T7dNkc57f5mSyE/yX27ZtK/k9n/3wO26TOIom2u+bodm6LUvIzW5cNozXo4fv5va92t8WsCF8 AwBQQZ2yEzX4Fq3PDOG2bc03JwVlG/myjixoZ2EzKXOZbE6VAJmtI9nfxc9tr8d3P/yOW35bevhW jof5GrRjo9fI60E8C9/N7nu1vy1gQ/gGAKCCWjXfHq2jubpvCcuW4JyGTPVrBSUQZgut/m/l/zcj Z4vwlud++B23nf1IA7UEZSV8T+37kd0wzN37ZCk7aXbf6/1tARXhGwCACqqUnYi0ldU36KWhdDto TiaOwOcKnfYgqAbXdP2LFm1L+La0Bqv7VLfDoRm+1f3aiKL2w3cj+77a3xYQhG8AACqoGr71Fl6/ gJYGzYlfuCsL32pQTWrCZR+t4duz5bv+cVNKR8yabY/wndZcr9Dy3djfvMbfFiB8AwBQgbsEYbId lvWAppaSuGqDk9ZTrc66oA57sQ/boU/7d1n4zu2z2bFR35ZW5621kBfvh99x0/cxbT3OlaBkrfDZ z6i13L41303ue7W/LWBD+AYAoAKf8F02Soe2vlzrb1nrsCVIeoy8oYXcpCOjWQ9u2VZa5uGxH37H Td9H/Xju3BRYt5VvXc6VlGy/rmUoNkY7aWzfq/1tARvCNwAAABAI4RtoSNKykh9pYNliYmthWbRE lQx1xZTTTb6e9uoys5Yxaj8BAG6Eb6CCosfN5qQRCb1+0/IYtKATEFNOd3vWO+ffipEPAAAOhG+g AleP98X3LFNEmxNfqK3fZier3LaYcro34Vu9WZlMqAMFALgRvoEKCsO3bfphs5NP2snJvZ50fUw5 3fkpp3PHbfvvW3XmPADAuBC+gQrKQnM2YYQ+PFY0dYVId0ssU053f8rp/P6rozQw6x0AII/wDVTg rvneCdVGoF2GWQlhetBTW0rLMOV0d6ectv3OluOpAgAAgvANVFDW8m0NsDuhTK3xzlrE/VtGmXK6 e1NOC32CkPCdYwEA/UL4BirwqdVOp0COIvsEFZPtQFlzSDqmnO7alNP2GnQm4AAAuBC+gQqqdZR0 jdzh1yrKlNM9mHK6IMCb9f8AAAjCN1CBV/h2hD2h1m+XBTymnO7+lNNmq7t9H5h0BwCQIXwDAFCR z414+/tQ9mTLZ1Slfs1m2/b+NrH+oc0QjOYRvgEAqKjOyDiN7wPhu5PrJ3yjDOEbAICKymaoDYHw 3c39JXyjDOEbAIAKime6rTgbrLEOW3BzhejSvhmOmV3t+6vMMOvo+1B1RljnvAi2YUtts/GW9GNx 7e9W6Qy++W3kZ9Utnt236LURvlGG8A0AQAWucGUbQcc2G6zfDK1Vw7ffKD/u15JtM+uEXX1WXdu6 bSM+ld20yPft+5H/uawje/FQormhWpX9nm3awnfR37PotRG+UYzwDQBABVmwNcLwtPqY+LlJouqG 702/8e1zr8W6vXzLcVMzwrpGCPLej8LjYw/p+twFypwBZfuxWW0ugOy1Eb5RjPANAEAFpeG7aDbY HoRv637VnBF2FvlNPuW9H57hW6gt8+bfJjczrW2Y1YLZfYtfG+EbxQjfAABU4Cw7WaHlO1++0I2W 76KZY0uPU0HpR9WWb7/j4yoDiuLItd30Rsqs8a4+uy8t3/BF+AYAoAJXh8vc7KqO2WCLZ2hVasMl 2Gktzm3XfBfUUNeYEdYMqOo++dR8F+9HefgWeuv0zmRdyj67O1iWzO5b+NoI3yhG+AYAoCKzHCJR fTbYFWZoNYOj5+9p2yoYZcTdSuw3I6xtRJAoikpbvs1RTPxHg8mHXXWfi0ponGHc8fcsfm2EbxQj fAMAUFGdMgwUHM+Whudj2D90EeEbqIhppeNOvuYurJ8P+jG+D/C37vL1nZb2cJOEDiF8AxUxrXTc ydfchfUTvsf5XrCum/BBHcv0Zsb9nlV/nfyN0C2Eb6AippXu5mtmHwEAfUD4Biooa0lxT0VcPq20 /vvFw4x1fVpp81gVTS3NtNIAgDEhfAMVFPaqd04tPfWaVtq1/vLw3b1ppdX1l00tzbTSAIAxIXwD Fbhmtlt8zzH6ge/MdoufrRO+ezKttPqay4cOY1ppAMAwEb6BCrzCt1lW0aPwbduvutNKq+sqKrdh WmkAwJgQvoEKCstOarZ8+08gEbble5VppV2/V6flm2ml0a/3huZG6yh7z+nkcVhcH66O4Mvruq3O 6m39DYCmEb6BCoo6XLqnlo68ppU21180tXTXp5VOvu8ztTTTSmMY7w2Eb+26s9y4ak+kch2XLU8T zU7PBX1MzG2sczQqoAzhG6jINa20cE5F7Dmt9GIdHlNEd31a6eX6/aaWZlppDAGtruZ1Zz6N0icl Uv+dXPfm+0kapCcT7/DdhXkYgDKEb6AippVu+HgyrTT6eN56Du9ZNkxn+fCYE0d5VNENpH+/DOfv uW5+1Zt1W1mW6/UYoVgL49N8YLZ2lPYJ31z36AHCN1AR00o3fTyZVhp9PWeLS718h+ksHB5zc+o5 BGbdIUHnXkOhWgO6Y722a88sB9HfRwv6mlg6TRf/bZjVEt1H+AZqYFrpBo8l00qjb+fs1K+Ts+8w nX79D6p3BPYpwfAdjck1Tr/9+it6PeaNiVE6p91I5L/nYxZx7aPbCN8AAFRQOXx7DNOphl09iPoN gVl3SNDq4dvvCZXr9aTbzdWAK+s3ylAI3xgawjcAABWs0vLts85pZJskqnrLd93XIswAWzV8u15P +n1L+d7M0fGbshMMDeEbAIAK/Gu+/YfpdA295z0EZt0hQY3XImxDoVYO37kacdewqkopius40uES A0P4BgCgIt/hPasM06nNvmqbebVgCMyq29Jei8dQqHVCrfp63Dcb9sm1rCO/MNQgBoLwDayIyTV2 9peZ7QCsGZPsoA8I38CKCN9LzGwHYJ0YBhZ9QfgGVkSr685xYGY7AGuUvBdzA46uI3wDFTGzHTPb AQBQF+EbqICZ7ZjZDgCAVRC+gQqY2Y6Z7TBs586di2+55Zb4iiuuiC+99NLF8oY3vME9gQ0LS0eX 5PyV5f3vf3988uRJLvCOIHwDFTCzHTPbYXhOnz4dHzx4MN69ezehjWXwy759++Jjx47FFy9e5OJf E8I3UAEz2zGzHYZDQvf+/fsJZCyjXC655JJFi/iFCxd4MwiM8A1UwMx2zGyH/pMWv0OHDlkDya5d uxaBXFoG77///sUC9NH58+cX56+Umxw+fDjes2ePM4SfOnWKAxYQ4RuoiJntyjGzHbrqkUcesYaQ vXv3xidOnOAAYdCklVtau+Um07wG5OsIg/ANYBCYZAdlpMxE+hWogUPqvGndxtgkIdxWD04tePsI 3wB6j5ntUEaCt9naJyOaEDQwZlJuYo7mI2VXaBfhG0DvMbMdikipiRm8ZThBAMtWcGnxNm9M0R7C NwBg0KSem+ANuMkTIPM6OX78OAemJYRvAMBgyaglaqA4cuQIBwWwkBZwdax7GQWFYQjbQfgGWpQM 9cTC0qVFZnEcy/UnASIJEzLKCQA3eX9Qb1Zl8ik0j/ANrEg6rEhrmtTMyTS+5qM7FpYuL9LSlUxB LWNfy6PmobR2maM5SKdLAMWk3lu9buQmFs0ifAMVSauh1IweOHDAOlYqC8sQFrmJlIk5+jz5hvoI XW4uAJSTa159L5DSLTSL8A14kjekqlNRy2PupFWRhaVLS5UbRxmKTD6A+zQsHwECqI8b13YRvoES MjWvvPkUBRN5TCeP68dUT4vhSGrBpXyqqGxK6qellKMPZSnyWnh0DtRjlmwxHn6zCN+Ag4wN7Aoi 0qJ99OjRxc8AQyPhWm4mpbOVOSOkLNJq3vWWZKlfV28aAPiT61+95mlUahbhG7CQNx7bY3lpAWcq aoyJtBhL7bftepAyrK62gqslYnITvYpnvv18fOpPn4g/deefxO+78a74PdfdwcLSq+VDt9wb33HP w/GXz34zfuHFl0rPebNsi8+9ZhG+AYU8WjN7eichg5ESMGYSsqWUwwzh0qrcxU6Z6lMr6Rxdx3ee /94ibO/91Q+zsAxmedM7Prq4kXz5lVed5760dDMxVXsI38AOc4KB5PE6bzpARlrCbeVYXZu8Rvpi 1J0qW0LJ7931UPzmd3+MsMYy2OUtV920eKJjQ/huF+EbiJfBW+q4zbpuaroBO7NDlizSD6IrVgnf V99wIhdU3nbNrfENt38+vvO+04tH9ywsfVqkpfvaT35uEbjNc1vKUUyE73YRvjF6tuAtH9b07gaK SbmJWYbSlQ/puuFbgogaTC678sb43lNn+WNjEOSpjgRxKT1Ry1DOPP609nOE73YRvjFqErBlZkoz eAPwIx2xzBFRZHjOdasTviWAqKHk8vfe7NU5Deibx558VjvXpUVcPdcJ3+0ifGPUpCOW+gZTt2MW MGYSttUALv+/7nG164RvGRVCbQ188pnn+ONisO5+8Iz2lEdaxBOE73YRvjFaEhjUNxdpAafUBKhH Ppy7dCNbNXzLyCZldbDA0Kj9G+RJT4Lw3S7CN0ZJQrb64SzDpfVh1j6gy2RSnq6Un1QN32YroIzt DQyddCC2nfeE73YRvjFK5kgNvLEAq5NSE7mRTa4rGbpzXU+TqoZvGVpQLTkBxkBGQlHDd9LxkvDd LsI3RkfeVNT6VJm1EkAzzPKTdQ0/WDV8S72r2vkMGAMzfMu/BeG7XYRvjI7a6i0hnJkrgWapk/BI CF6HPoXvrfksjpKgE80Cb3MST2db7W9vGsUbk2k8n2/FUI7Jzt99sjlfyz4QvteD8I3RUT+UpZMl gGYdP35c++CW4QjXeZ13OXzPoo3cZEUhQmrI8L01n8fTyfK1RdOtRo/bukJrM8feXKJ4FvjmhPC9 HoRvjIpMCqK+oUhIANAsqfNWJ9+Rjpih9SF8b82m8WRNoSskwrd5PGbxVNnv7Dxo7vj4InyvB+Eb o6KOxiAlJwwtCLRDAm9yrUkQD32t9SJ8p2UH9tZnawup0Sqe/sz216eR+jNZ4FUDarrNyWQn8C23 bdtW8ns++1H4OrXwbdnfgtKL3JOBSRRHk3yrcbav2ba0JZrZj5Vj220ej6K/M+F7HAjfGBV1JAZm sgTaI6Um6xx2sBfhOxcUsxBuay2eb05ydeHWILjz/SxoZ8EwazGeKmUn2TqSgLn4uUVg9dsP39eZ hm8lbGYBW38CkO6/sp3Z5vK1uFq+k+OR7KsebP22rf5OG8djsQ2ltXsjcL2/ivC9HoRvjIa0vDU5 CoNMz3vvqbOLD20Wlj4uMsZv8mHbygeMcr0dOXIk6PXepw6X+dbd7YBpCc5pYFO/VtBqatZ16/9W /n8zcrbebnnuRxF7+FZvNOz152qHRPO1VSk7SX7Wd9u219zk8TBfW8hafxPhez0I3xiNRx55RHsz OXHiROV1yCx4137yc9qbFQvLEJZ3fuD2xoO4GoBD1333cahBbfSLycTSIS8f0so6TqohVW1J1n5v M3K2vFpDYsWwWDd8i7RV2WgdLgrf1k6sdcJ3S8cjf3yUFvnAAZzwvR6Eb4yG+Ri8yhCDL7/y6mIS jje/+2MENZZBL++78a7FTWYTZAz9dY0s1NdxvtNQmYTvkjBWFr7VltpplLUiW8O3Z0tvVauE73Qd aZnG8mecZScFpTZttXw3+XcnfI8D4RujYU7+UWU6+atvOJELKZddeWP8nuvuoHyBpbeLnNdvu+bW 3Lkt4bOJAH7gwIH0etuzZ0/Q670P4Ttp1dXqigvqsIWEP+3fZeE7V1e+rG22l6AYdc1aC3nxfhRZ pewk38lx+TNpi/girM7i2dQenPWRRDzD97zl47Gzj0kpjdpSH3r0FsL3ehC+MRrq5Doy+oIvddrp JHRLrTcwFE8+89ziRlI9z+Xf8sRnFYcPH17bZDv9GmrQ0enS+v2NSuFbaKUbSWdMsx7csq00+Hrs R+HrbKDmu2yfsg6W+dFOoiiqvu02j8eKv98kwvd6EL4xGmr49g0C0qlSfWO6/L03xy+8+BIHE4N0 w+2f1873T3z6geDXXFOYXh4oR/hej16G79DT4hbuwxqGBkI9dYLAh265N31TknpvaSEEhkpauqXj pfqUJ/Q11xTCN1CO8L0enQ3fzoHyzSGSAofv3H6tYWgg1FMnCKj1sDLKCTB0D3zpMe3D+JlvPx/0 mmuKGr4vv/zy0p8nfGOMCN/r0YvwXTZ26Tr2ybcnOrqjahCQ8hL1TenuB89wEDF45nm/Sv+GroTv 17zmNYsJtmTEFdknmfDn/Pnz2s8TvjFGhO/1GET4ts7wZfyeOSzRlmXq3aJtmvSe1oTvPqgaBFxv SsDQqee9hNJQ11yT1PAtI63YxmWWjtcyHKLs529edzPhG6ND+F6PAYRvpQzEnFK3YNxO26D22df0 KW5tCN/9Q/gG/AwtfP/Mz/yMe2KUneX1P/FmwjdGh/C9Hj2s+ZZgXD45QL6l22gt14YwMr7m0Ymy TviWMW+l4498IMkik77IIjMvon19Ct/mOLNhtxmmnGtxvXHz6v47rLEzd5/Dt5STSFmJtGqXBW61 BfzqD99K+MboEL7Xo/8t357h2/za8v+j7d+fpNuYRX4lJ6JO+J5Op6UfAnv37l08Bt2/f38a0mUa dAnpp06d4oxdQV/Ct3Vq5AAhNWT4rlLiVefYrWO83CaPybqfqvUpfMv74tGjRxeNG2prt+8i77kS 2Kn5xhgRvtdj8OFb/d2sZXuazVaVDHYfRd4lJ6Jq+JY396ofCkXL7t27FyE9qVeU5dixY2lr+sWL Fzm7DX0I39nkC37nYV8Rvt3HowudubsavuV9VBojZPIeder6suUHf/AHrXXfsp4E4RtjRPhulm8l wwBqvvOP57PZvPQAY3bMlA/oXGuT56PequFbwrCEYvngSMKytG7LB4i0vDQZzG0dimQ5dOjQYrtH jhxJQ7rZ43/IehG+Lf0V7Oe+u4U0/Zntr08j9WfynYy1bW6HvklJR+Z8GVe9llrz+rbus2PWt9yT AeO1bZRd49q00f7bbfN4rPLe0oauhG95j5L3qyqt2vKEUd7v1LITKfdTG0Dke/JerCJ8Y4wI382S 9x55r5LG0KJG0GGMdmKdqtXecph9cGfhRp16t6wVzloS0OAHpdw1yQeO1CwmIV0+OJIA3VZIlyXZ hlqXLvsxlLr0XoTvXFBUp0HOXxPpuavcNFqDoNkZWTlfs9biqfWmNgmYi59bBFa//ahyfZv7rJaB qdeyrV/GbNP2WvLTb2fTT2fbyqabLtnuvN3joRpr+JYP++PHjy8aCao0SMhTQHnPkg+706dPp+uz TbIjrd+ybtmWifCNMSJ8N0vNaXKTL0/XbI2cTC/fU/LHTFqvpWVIPuQOHjyYBugqnY2qLvIBZtal y4dm1+vS+9Th0tq6awnO6Y2n+jUtXPoO02lMXuUo51qsw3M/irjDt3qzYfma0lHadqPsW3aSlaVV 3G5Lx0M1lvCdvHfJ+4iMwV2lVTtpGLhw4YJz27bwLe9PrtaodYXvtkqwqu9H/slw/npY1xwbxZ2Q q4xUBp1v+P6lX/ql9POexb24ntDJ0zs1HxG+B04+nJKQLi1DcnIk9ZKy+H7o1VnkJOxSXXofhxpU w2ZaC1zy5KWs46QaUNWWZGtfCsuHnT5SUL0nQHXDt1CfVOVawSPPUpWNmuG7peOhGmr4fu1rX7to IKjSqi03+vI70uqmtmr76Mv08q4bNfeIX+2cG66nNU2H7yqvq0on5GT/+9jZep18wzdLM4u8/0lj JeEbqSQUywddEpZlRjgJz/JoN0RdunzQmnXptkfEdZjhWz7M5RG3q+69K+N8p4HSsyNeWfhWW2qn kSMAV2z5rmqV8J2uIy03y75vLTspKLVpq+V7FX0P30n/Frne3vjGN1Z6H0hmoGzi5rwv4dsVGm0t 4mqJZdOt5D7htYkRkayvy/K0rmon5FWeNo0Z4TvsIk/vJOcQvlGZPDpZR+dRtS5dHuGYdellLWNm +Jb9Tz70JeybH/brCN/mB6DeRyFfd7z40NkOf7YaZ3enTbPlafmotqgjc/o7Wgt58X4UWaXsxDV2 v3r8lh/As3g23cpPsKUFGM/tzts9HrZzoC/hW/qDyA27fKC4ZpIsa9Vuo09JH8J3cd8mW0i1zczs 6mBtOXctM0DbW6Jd10PJteHRQl0cvu3vWT7XROh5CoaCspMwZSdSZSA5IymVI3yjNevsPJrUpSct abL88i//sha+ZWxgs0xGHQFhvUMNOj4Ird/fqBS+hVa6kXTG9OjInH7ge+xH4etsoObb+tqN/Vqu Ox8uoiiqFL5dr7mp4yHa7sxdhSt8ywdHcj3L9eUzd0GyzLaDW/JEK4R+hG/3terfQlzQwXruNwO0 +p7gHuUnH77rdDYuKjtxXS9+4bsbtfN9Q4fLZpnZJikzMRG+sXbr7Dzqal2XVnSml8dYJef8f3vZ ofhfvPt/W4TXKqVn8oEjJV3mDW9IvQjfBeP6+9ZGF3awnvpPQlcrfNfobFz4ulZo+VZfF+HbH+G7 WUn4NjtYmgjf6I3QnUf/x//pF+P//p+9j/CN0ZHz/fX/3Zu9O1ZL2ZmtVXsd08snhhm+bT9X0Hoe KnxXeGLjaqEuCtiE7/YQvpslrdw+/dQI3xgkW+fRKp2/kmX+mtelAZzwjbGQ8/2/+YUrnU+G5KZX SrTKJukifBerWnZSeR1T/xmgm2r5Ln/N9teVBfn8DQZlJ+0hfK8H4RujYQYBVzmL1ItLPfhn776f shOMUnLOy83nT//jn1tcD3XG8Cd8F6va4dK+jqIA7z8DdL2a7+qdjW2vS+3vYPs9Oly2h/C9HoRv jIYaBH7kR37EGrjVx0XUfGOsujK9/Cr6MtSga2z6JsL34vueM0DXCd/u9W94hW/XCCzmsfEpaWGo wXoI3+tB+MZoqEHgda973eLxudSOd32cbyC0sYdvWUJpepz4sWKSnXrMz7kzjz+9+Drhu12Eb4xG H2e4BNZhjOH77gfPaK/7O89/L8h+Zi3BlEtwDMO799RZ7bx/5tvPL75O+G4X4RujQfgG/IwxfEvo UF/3Hfc8HGxfk5IJOgrWPH47pTG0eld39Q0nrOVWhO92Eb4xGoRvwM8Yw7d4z3V3pK/7ze/+WNoK CAzRA196zHmtE77bRfjGaBC+AT9jDd/mNf/OD9wev/zKq5wQGBy5sZQbzORcv+zKG7VSK8J3uwjf GA3CN+BnrOFbmB0vL3/vzfGpP32CkwKDISVVavC2fb4RvttF+MZo9CV8d2WyCG2MYKWe0hzarM3x dbNjkR8azbqvO2MZ219H8TqQGXP4Foc+8hntGMgiJSlyLKSDmrwXsLD0abnzvtPxJz79wOJm0jy3 f++uh3LXAOG7XYRvjEZvwrdjvNqi8XHbGKYsndjCCLQhw7c2zq9tbF/zmDiOA8OQVZOc8z93+Qfi O37nM8GuuSatEr6l1ESCypve8dFcUGFhGcoipSYyyo8N4btdhG+MRl/Ct3uyi3yLuDrBRdOt5L6B ta3wra53YpuOWjkek0nxDHhMwFHNW97yf8R3/Pj/EL+w+Tfj7/y9Hwt2zTVplfCdePKZ56yt4Cws fV9uuP3z8QsvvuQ89wnf7SJ8YzT6EL6rTjetBVCzLGQ7aE6jfIuwWU5izi5nb2FXZrQrafm2rr9G 6E0nH4lmzlb4RNn000w9Xc3Rn/pftj8dNrLl6NEg11yTmgjfCQnhUm4iZSdSfsLC0rdFhhSU81f6 L/iMYU/4bhfhG6PRj/DtDon28J0FXdvX0mUntGrBOvlaEnKNbfpNN22G7/w+lgVn+3HQJ83IWvjt 4bk8fHejjr4v3vTPr4sfe83rsvC9a1ccO2aCbfKaa1KT4RsYG8J3uwjfGA01CPzG3/7bcSwfyMeO xfEjj1h/fi3hOw2Z+c6BvjXftkCersMxlXVSW60G7VrhezO//jolH+bv2Fr4VWXhW32NhO9yUuv8 np9/t976XSPAEr6BfiJ8t4vwjdFQg8CBSy7Rg4W07O3bF8dHjsTx/fcvfl7q4dTw7eqY0qTq4dv2 cwWt56HC94qdQtMw7bkewndz1PP+gR/+B/p1cupU7WuO8A30B+G7XYRvjIYaBP7+3/27cTyd6sHC XPbuje/62csWnc8kiHzolntb38eqZSeV11ESvtX1NtXyXf8YuBfz9VN20hx11rvL/tn74r/+AeU6 2bOn9jVH+Ab6g/DdLsI3xuHChfiWt789PixvItvLn29uFgfvndbwP7riqqDTTVftcGlfR1GAV4Lt Tg121sqst6LXq/nO1q/+noR+32H+XDcIIh160Kgfp8Nlc8wp1hdPg9TrQkq1PBG+gX4ifLeL8I3h kRruEyfkkz+OL700js0SE59l797FeqRneOjppm0lIKKJ8L34vjI8YVH5Sr3wveVYv/8Y20XlIVnn 0OX+auOAF5SmMNSgH3N2RxmOLL54MY53786uDbmePDtfEr6BfiJ8t4vwjX6T+mwZBu3gwWXQrhqy bYu09CkkgKiB5G3X3Bqfefzp1l5SUcsv6mGSnWIy9Ni1n/xcblr19Ebz5En9GpHrzQPhG+gnwne7 CN/oyzvBMgBIa/b+/XpLnOfy/73+9YuSk0NJh8sLF/S6b1mnpUOZBBBp8TYnKZCvSTC/456HG50G 2Bxmj6mROZ5tLOq41VJeop7b8m8Z21oj1516TZ0+XXrZEr6Bvn7kEr7bRPhG90gAlgv98OFla7aM RFIlaMvPy+9JUD9+PA0J1iAgHciSljx5vO4gI0CYLeBtLkmZhJReMBvbisdypyxGWr05HuWL3FTm greQUpNptc6XhG+gnwjf7SJ8Y32k5VnKRqTMQz4ckyBcZZHfOXBgGbRlXQW1qNYgINuWFnVPjz35 rNYhjYVlKMtlV95YPpymXGcVOl8SvoF+Iny3i/CNMFbtBCktbvJ7hw4tP/B3xuKuoskgIKOeyKN7 eWzPwtLnRcpP5KbSizwdkmtH7XwpN9EBrrmqCN9AfYTvdhG+0bxVO0HKh7RMeCNBXQK71Hs3YJ1B ABgMuSbV61VuiDt4zRG+gfoI3+0ifGOVq3PlTpCLIf3kg1HCuoT2grrrVRG+gYZ4dr4kfAP9RPhu F+EbflrqBBkS4RtoiNx4q50v5Sa6Y9cc4RtY5RInfLeJ8A1d4E6QIRG+gUYvKP26t3w4r/Oa2717 N+EbqInw3S7C95h1oBNkSIRvoEFSIqa+Z8j/G2Vj67zm9u3bl277UnmfAuDt9OnTWvi+v+Of731D +B6LjnaCDInwDTSspPPlOq+5g9vvdVzvQN1L+4QWvh+Rxjo0hvA9ND3rBBkS4RtogdyUq0/DlP4c 67zm1G3LcnEg72NACEeOHOH6aVEvw3cyY10yXXTw7e/MPrixM2ve2gygE2RIhG+gBdIipna+VEo8 1nnNyWNyNTwcl/c4AF727t2bXjvSfwLN6mz43prP4+lkQ3vz3EgD93rCdxb6bfvU4n4MuBNkSIRv oCXSAKC+3+wE3XVfc5dcckm6fakBB1DO7Gwp1zGa1YvwHU23jO+tMXxPpvF8vtzm1jRKT87GWsBH 1gkyJMI30BJH58t1X3Nq3fd0+73x/AgbHYCqzJKtcz3s49V1gwjfrhZp9fdmkR6S1fXbvmZu07qP q5af0AlybW8ohG+gYdLabXS+XPc1JyM2SOhO9uGAPP0D4CRBW71m9kvfMTRuAOFbKU+JZsvvpy3S Wct4+rWdlmstsOe+FsWzeXn4nm9O/MpO6ATZCYRvoGVqI8L2B/i/+fVfX/s1d2j7JkBtlDkp78UA rNQhOiWEM8pJO3pY8y3BWAnfm3qoTuRbuo3WcqVkJPe1nRBfuH9Kq7d2cyBBm06QndRm+H7m28/H Xz77TRaWXiyPPflsOxeZvF8pnS8ff+Mb1x6+ZZQGtfZ71/Z77GneV4EctUyLWu929b/l2zN8m19b /n+0/fuTdBvJ98tKTgrLTcxxb+kE2RlNhu8HvvRY/KFb7o3fc90d8Zve8dF4769+mIWld8vbrrk1 ft+Nd8V33nc6fuHFl5q50KS/ifI+t78DT5uktVsNFQRwQGfWee/ZzicML9iewYdv9Xezlu3pct3R LAvSUeRVcqK2mFtDurR80wmy828udYPAk888twjcBDeWoS2XXXljfO+ps6tfaEbny/Py+LoDpV4y PbYZwJkyG2N34cKFRV23em3I0ILydbRnADXfSu32TrlIVoutB2mzY6a0WufKWwpKTtQW79yi/l7S mk0nyE5ZNXx/4tMPOIOLtH5LKGdh6cMiQdt1Lsv3pYxqJUbnyyMd6WdhBnBZrrjiCkZBwSjJEyG1 JCv5bGR0k/YNY7QTayi2t2AnLeJqJ8ksrBeXnBSGb89OmlifVcL3Dbd/PhdS5HG91M9+5/nvcXDR Oy+/8uri/P29ux6K3/zuj2nn9uXvvXnx/ZVIJ/Gd8H1xe/nHr399J163BHBp9Vbfv6VjmdS7Ejow BjJ1vJSVmDnm0ksv5UY0EKaXx2jUDd9S320GEwktwFDIDaTcTKrn+bWf/NxqK5WaaqX1+z/MZp15 vTKCgzqDnxrC5RH80aNHGeUBgyG129LKLSP/2EK3LDKdPMIhfGM06oRvCSVqq6A8rqelG0N19Q0n tAB+94NnVlrfKaX1e7FIKV5HSCCRVnB5L9hwPtFcBnJpEWRh6dtSdm4n43jT+Tg8wjdGo074Nuu8 afHGkMmIJ2+56ibtKc8qjlx99aLDpTYxWAdHUJAQLp3MyoIKC8sQFrmhlL4OlFmtD+Ebo1EnfKsd 01Z+DA/0gIx4ot5wnnn86ZWuuSvM0Z86PHaw1LtKEJdg4tNqyMLSl0Vawg8fPhzfz2hrnUD4xmhU Dd9SXtLkI3igD5o875Nr7pQ59GrPWtykhVBCCwtLnxbG6e4uwjdGo2r4llkAKTnBGKnn/afu/JOV r7k9Zuv3/v0cZACjRfjGaFQN3xK2Cd8Yo6bDtyy3b23pAfzkSQ40gFEifGM0CN+AnzbC90//8A9r M1/Gu3d3svMlALSN8I3RIHwDftoI34tr7tgxvfWbsYUBjBDhG6NB+Ab8tBa+xZ49eudLZtQDMDKE b4wG4Rvw02r4Nma+pPMlgLEhfGM0CN+An1bDtzh4UA/gjD0MYEQI3xgNwjfgp/XwLaUmu3Zl4VtK Ueh8CWAkCN8YDcI34Kf18C2OHtVbv+XfADAChG+MBuEb8BMkfAs6XwIYIcI3RmMo4XtrPoujndex Ec0Cbm8ST2db7W9vGsUbk2k8n7e/rb7Ymk3jyc7ffLI5b317wcL3qVN66/eBA/yxAQwe4RujMYTw PYs20teQLi0H1ZDhe2s+j6eT5euKpluNH7cQwbWdY28u7f4tgoVvccUVdL4EMCqEb4xG38N31voZ xbOBtgoTvs3jsR2+lZurxVOBAC3gQcO3rfMlAAwY4Ruj0fvwnQavfKuntYXU0iKe/tz296ZJK/ok 2g54+UCXbm8y2Qn92XZt25Pf9d0P52s0wrd1fx3hM/dUYLHdbH22391yfH8jiry32+bxyG0nUPlJ 0PAt6HwJYEQI3xiN3ofvXFBchmFba/F8c2KtCbeGwe2fyYJ2Fgyz1uKpVnairiMJgIufjabe++Hz GrXwvZF9LQvZ2ROAdP+V7cw2ba9lbj0eyf66yjxc2zV/p+njYUp/f0hlJ0KGGVQ7X0pLOJ0vAQwU 4RujoQaBn/4nPx4/9cKZ+KXvf8/5813tcGmt+zaCc9pCarSyqkFRLesw67r1fxvfswT1xTosX3ft h4s7fNta3ZWvKeUYtnKVKmUn+vEt3q7rdTd1PLRjo7R6N1mSYxM8fAup9VZbv6UWHAAGiPCN0VCD wK/85j+MP/6f9qfL8Ueviu/82jXx/U/9TvzQ+ePxoxe+EP+HLz/Q6aEG1cDpXJzhO99yqgZUtSU5 F8wtrcyl+9Ny+BZZq3B+JJii8O28makavls4Hum6hjraiUlGO1EDuIyGAgADQ/jGaKhB4B/85I9p 4du2/Ou73t75cb614OgR6IrCt9pSm9Q52wJwlZbeqlYJ3+k60qCafd9ZdlJQbtNGy3etY1LSqt+G tYVvKTWR8b7pfAlgwAjfGI0kCPyNH5jEP3f5T8Q3//mvFYbvG/7f3+pU+E5adrW64g13Z0AJba4a Z3unTbOmfFnb7C5JSVrGd34v6aTosR8uq5SdZJ0o899PW8UXQXgWz6ZGucpOQFZbmL3Dd5vHI7c/ 9pb9pq0tfAuz8+WxY7x5ARgUwjdG4cVXL8TX3Xpl/M6j/zC+/j/+Ymmr9x9/8+Pxw3/+REeHGrR0 unSEtCrhW2ilGzvhzhp2LdtblKt47ofzNTZQ8229ETH2K+tgmR/tJIqiSuG71eNRFL5bHHJyreFb Ol/u3p2F70suofMlgEEhfGOwvvVXT8RfPH/bop67LGyri/yOYHp5jNVaw7c4eVJv/T54kD8KgMEg fGMwvv/Xryw6SkqrdVlJyW/9+1+IH3z6dxc/q379z75zT7o+wjfGau3hW+zfrwfw06f5wwAYBMI3 eu0vX342Pv2tP4r/8IkPlrZoX3/v2+J/9Ct/L37N62ZpEJDWcfnejX/2v8Zff/4hbd2Eb4xVJ8I3 nS8BDBThG71z/sVHF63Wt331ysKwLa3f0rItoVpaxV1BQIYYlHWaCN8Yq06Eb3HkCJ0vAQwO4Rud JxPhSDnJPd+4Pr7pzFsLA7fUd0vNtrRom/o+wyUQSmfCt63z5YUL/IEA9BrhG530Fy89tSgn+YPH ry4M21Iucve5I4tabRnRpAjhG/DTmfAtTpzQW78PHeIPBKDXCN/ojCe/+5XFDJO3nn1XYeCW78vP mTXaZQjfgJ9OhW9B50sAA0L4xtpIS/XZ5+5blJNIC3ZR4JYW8Ief/ay1nMQX4Rvw07nwfe6c3vly 717+SAB6i/CNoCQ8S4guG3tbarsllEs4Lysn8UX4Bvx0LnwvV6a3ft9yC38oAL1E+EarZJQRKQ+R MpGysbdl9BIZxUTKT9pA+Ab8qOf9R++4M9g1V0g6X8o61M6X8jUA6BnCNxonY29LB0jpCFk29rYM 8ycdK6WDZdsI34Af9bx/z03/+2LEoRDXXCk6XwIYAMI3GiHjZPtM5S7lJDL2tgwdWPcDva4hhO+t +TyeTpavIZpurXE/ZnG0cyxlmWzOla9N4ulsK/fv5l57FM/m9vVtzabxRNkn93671wE9fP/LY7+x eHIV4przona+lDpwOl8C6BnCN2pJxt72mcpdykkkmNsmsglJDQKXyCPrEp0M30m4nEzj+U54VAN5 blF+rknzzcly/dEs27eWw/cscr8u82YgW/LbTvbdFs6xZIZvuY7rXL+thO9HHtE7X156KX8wAL1C +Ia3ZOxtn6nck7G3pQSlK44ePaoFs4sl9aJnHn+6c+HbFhxtreFqC3AbLeQ+AbbJ8K2ua2Jp+V98 X70hmUZaq7y2LssNDHS28C030dKHo4qDBw+mf4fdMllOUw4f1stPjh/njwagNwjfKPTUC2dqTeXe RSdOnNDC9yPSglbgO89/Twshdz94Zq377yo5sYZv5Wt6UN8JsdvBcxrprciu1mPXtszW5bKWb+v6 PQNwGqajmbXVPffzBeUnTbfID80LL76knfeHfj8bd/+h89VC7r59+9K/9aVNtlDLjbM8vQrU+VJu 1OX9Q1ryDx06tHgtssgNhfWJEwtLD5c9e/ak5/bh7RtcOd9PnjxZ2lCF6gjf0Eg5STL2ts9U7vJh vMrY2yGdOnVKe6O5//77S3/nsitvTEPIh265d6377wqN9vCdBd1cC7H5prsdYrVQvRNqs9Zjv9KN 4vCd30efEK2/vp31psHaHZ7TdVt+pit18529Tv70CS18/5v7/i9tRtkqnaPlwzw5z6644opmd7Tl zpfy/nDkyJF47969BDOW0S8SyOV6OE0fi0YQvrH4MJWxt32ncm9y7O2Qzp8/r72Z3OIxTvANt38+ DSFvesdHF6Uo65KFTr2zYJWab2coT4K28fNJnbXZelw5fG/m1+9b/mH+nKtVP3+c3OE6eV2Eb93L r7waX/7em9Nz/i1X3bQoHVMnwZIRinzt2rUrPRelFa1x+/bpnS9Lnmb5kPcFqU8ncLGwuFvI5UkQ 6iN8j1Qy9rbvVO5tjb0d2nT7Azp5A5HHamUee/LZRehWw4g8ll+HauHbPpqHs/U8VPiu0Sk0a8X2 uLkoGe3EfF2Eb921n/yc1up9xz0PL74uN+fq+4L05yhz7tw57W917Nix5nfY7HwpYbwGeawufUKK Qre0gMt7xvHjxxet4rJcuHCBkwaDIddBcm7LeS7nu/r0ihDeHML3SCRTuUvLte9U7iHG3g5NHp1V 7QAmAUQb9/i6O+Inn3ku+L5XKTupvI6S8G2ut4mW72qv2b2kpTZKJ8ui40DZSZ60eKtPeRa13h/5 jPYz6jCiUpJW9vRLHlGrfycJ462QchO1/KRiGJC+H66AIaUyEi4I2RgzOf8ljMv14Loxbe36Hqhe hu91d5gqGkmhS6QWW2qyq0zlHnrs7dDkkbL6piF14D7MFkFpDf/Epx9YtIyHO+/9O1xWvXa0kLtT g521OOdb0avXfGfr135n+1oqHDFl6g7t6dCDUrOutHhvWGrau/T+0SXSqfjeU2e1vg2uJzzyfqK+ b8h7RhG1M+KlbQ4HuELnS2mNV5+GqaGbMAHkyXUhoxiZ142UmPmUcmKps+HbXceqfpCH/fB0t8J1 Y8KOZCp337G3ZRQTGc1kTOQOXn3TOOTZSUtaBt93411aQFGXd37g9kWLeNuLWgaSfM0M30W/bwZP 7XvWALs8t831qOHbte7cvx0BWV2H6/XaXld2E7y9j0Xh23gNZg15iL9bFxe1nEpdpObbdVMp7xnq +4irHE06ZbVecqKSoQbV1u+SkjJ5H9i/f781dEvfEADF5DqxtYTL1xgdpVwvwrfZmreulivZ7lRt tWt5LGUfVaZyl/G5ZZzuLo29vQ4HDhzQJtup8kYhI0GoHdJCL2ZL8Lr2o8+LeuPA8dCf5vzeXQ8t bjRd5AZfvbGXPiG2oUXlpja5xuRmN0jZhrSue3S+lH0xy0yk1Y7aVaA6ae1WO1bLIkOMEsCLDSJ8 +4xPbHYcs42YULUW1DVyRNuSqdx9x95ex1TuXWaO9111FAYJJxJSpPXQfFzfevg2ht0jNHL8Vg3c ch7LMJpSguJDWrvV9xlpDVdJDbX6dElamIOQIdDUzpeW7UogUMceT+pVae0G6rP1m2h8aNGBGUD4 9huf2Gwx1AJ77mvuMhLro/OScYpXpU7l7jP2dhemcu86dexeCQqr1HdKGJfZL0MtyTko10XI7Q5h Sa5xueEe+7F45tvP1z7npd5bfd9Rx/pXw61cW0HHBS7ofGkL3rTQAc2wPVEigLv1sOZbgnH5KAr5 lm6jtXwa5WfoU2bRc+7XNKo8VFodyVTuMqauz9jbXZvKvevMmtR9NYcoA8ZIRjpRGwLkpl/IiAjq dXWo4YlvSpmdL9/whrTzpQyb1nbwllGQuMll6cvS9KhdtgDeen+Pnup/y/em//jE6teW/x9t//4k 3UbVsX9trecrvXF/9yveU7nL2Ntdnsq9D9S6VFkkOADwIzf86vvSF77x+4s+FHX7UzRGRlxQW7/f //7FzbZaCiMBoYk69Ae+9NiiZEdKdyjrYunrkpSeyfm8KnmKrI6XL/XglHXlDT58W2fxi6bLdatD lEVRacmJTTrcWY3wnYy97TuVu4y93Zep3PtAgoEaFuTD+eTJkxwYwJP6ZO7ol/bHr3ndLL2e1tqB ce9erfPl3p/8ycbKzIS0GBK4WYYaxFdtEZchfNWGLRnkALoB1Hz7j09sdsyUFvBceYtHyUmyP2nw rjDet4Rn36nck7G3+ziVe19I2FZbxOT/ZXYvAOWkPE6dtOtffeJnu/FhK3XmO+H7FqNMcNVp7mV8 f9cwjW9+98dGO3QlS/8WOV9dHbHlPF+FOQwhn6u6YYx2UjA+sSkLzFlnTHX66sKZ8QrGKS4y1qnc +8IM4PKYLGgnMaCn5OnRb/w//7P2PvZrV1/WjU6MO50vdyvv1TLxzyr7Zs4CKouM/y/1s76jxQBd IuetnL+2eSzkfK9LSk3UJ8syyAEyTC/fAmmpTsbe9pnKXTpWDnEq9z6RAK7eUEkYp6MI4CYfrvKB +jd+YBL/63/3c+l72qf+8xXdeFp34UJ86m/9Lb1fx7/9t7VXd/eDZ3KTEUloAYZCzmdzHgs57+uS z1D1+mPW2Azhu2FSUuIzlTtjb3ePOfV88vg8yAQhQI9IPbc6scaP/dRrtfc5GRa1Cw79/M9nT7S2 l4vXXltrPWcef1orNXnLVTfR0o1BkvNazm+1BMU1420Zc0bpVUu+hoTw3TAZX9s1lTtjb3efGSpk kZ7b1KsByw/TgwcPWm9S7/n6x7T3vadeOLP2/VUfex9MZr6sMfLCoY98RgsjEsaBoTJvNuX8r0ud UVrKvrBE+G6BhG2mcu+v5HG6GTAuvfRSpqDGaK8JGZpTbcVKyrPkiZGQJ3nq1PPyPrjOoVDNUrL7 C2a+LPLCiy9pQWSVOligL9T+DXL+y3VQhzmjNP2plgjfgIM5KYc6RrAEDmbGw9DJtNHmqAXqdSDf V0k5ndr6LbPtrotZb3pBHfu7wpCiUger1sBS540xOPWnTzRy3kudt3odJjfrY0f4BgpIuYk5JbU5 S97Ro0dzIQToIykrkcmmJHCrE2Woi5RyyDnvuvmUp37qkKnrmptAvXne9UM/pM98uX3jEHvePN97 6qwWQqj1xhg88+3ntfNeroO61PePI0eOcHBjwjfgRR6VqbVrrlAipSmyyAe/dC5hYen6sn///sU5 ayu1Mvs++DzxkZFO1FGeZESndVBb7KWVPpbRi9TW7+0bCB/mKCfAGJjhe5VRT9QbeekzAsI3UIk8 QpPaV/kwLwoqLCxDWKTzsdx0Vu3rIP1d1PITGXo1NLmhSF7H/qTOW0K4MvOlT+dLwjfGqMnwrd7Y 76/Y52KoCN9ATdIJTVoCJZyYI6SwsPR1kQ9KaRGXKaJXcfzRq7Tyk9Bjf6utbdIKviCvSW399piJ k/CNMWoyfKs3wvL/IHwDjZHH8VIjLovUzVLSwNL1Reovk3O26X4LUuutlp/IpGMhWcO3kP9XA3jJ MKKEb4wR4btdhG8AQCtktBO1/OTrzz8UbNvO8C2lJrt26Z0vCxC+MUaE73YRvgEArZBxvm89+640 fMs44KFm9nWGbyGdLT07XxK+MUaE73YRvgEArXnyu1/RWr/vf+p3gmy3MHwLtfOltIQ7Ol+GCN9b 81kcJXX30SzI8cm2OYmns632tzeN4o3JNJ7Pt2Lo5puTYH8HX4TvdhG+AQCtuucb12sB/PyLj7a+ zdLwbXa+tP1M3H74nkWWjq8BQmrI8L01n8fTyfK1RdOtRo/bZHPe62tD//tH8awjNyeE73YRvgEA rZKRTtSp52UklLanni8N30JGO1EDuGWElzbD99ZsGk86FrraQPgu+ftPJp07Dwjf7SJ8AwBad/a5 +7TW74ef/Wyr2/MK31JqIuN9F3S+bDV8SylGQeuzVo7iaBVPf2b769NI/Zks8KoBNd1mGviW27Zt K/k9n/0ofJ1a+Lbs74Y7SOeeDEyiOJrknxZk+5ptS1uimf1YObbd5vHQ93M7cHfwJozw3S7CNwAg iDu/do029vdfvPRUa9vyCt+ipPNlq+E7FxSzEG5rLV7WBut14dYguPP9LGhnwTBrMZ4qZSfZOpKA ufi5RWD12w/f15mG741snVnA1sNnuv/Kdmaby9fiavlOjkeyr+rx8d22+jttHA/1d2QdXXwCQvhu F+EbABCEhG117G8J423xDt8XL+qdLy+5ROt8GaLDZb51dztgWoJzVqagfE0Ll3pwM+u69X8r/78Z OVtvtzz3o4g9fKs3Gvb68+zJQP61VSk7SX7Wd9u219zo8Uh+PrlJInyPDuEbABCMlJuo5SdSjtIG 7/AtZKIdtfX74MH0WyGHGlTD5mQycc9Eag3f9tIVNaSqLcna721GzpZbdZ/qdgytG75F2qpstOoX hW9rJ9Y64bul4+Havy51uiR8t4vwDQAIRjpaqlPPS0fMNqaerxS+hdn58vTpxZdDj/OdhsokfJcE urLwrbbUTqOsFdkavj1beqtaJXyn60hbh5c/4yw7KSi1aavlu+7f2LU01Sl1FYTvdhG+AQBByVCD auu3DEXYtMrh29b5cjuA3/32Q62F76RVV6srLqjDFhL+tH+Xhe9cXfmyZdVegmLUNWst5MX7UWSV spN8J8flz6Qt4osQPItnU3twzkJ7hfA9b/d45I4PZSejQ/gGAAQnk+2oAVwm42lS5fAtjhzRW7+3 l7t/9KcCDDXo6HRp/f5GpfAttNKNpM7YrAe3bCsNvh77Ufg6G6j5LtunrINlfrSTKIqqb7vF4+E+ DwjfY0H4BgAEJ+Un6tjfMg19k2N/1wrfx48HDd9AVxG+20X4BgCsxdeff0hr/f7i+dsaW3el8C2h e/vnzeBN+MZYEb7bRfgGAKzN3eeOaAH8W3/1RCPrrRS+z52L4337CN/ADsJ3uwjfAIC1kZFO1LG/ ZSSUJtQuO5FxvgnfGDnCd7sI3wCAtfqz79yjtX6f/tYfrbzOWuFbXLgQx/LzhG+MGOG7XYRvAMDa /cHjV2tTz//ly8+utL7a4Ttx6lQc795N+MYoEb7bRfgGAKyd1Hqr5Sd/+MQHV1rfyuFbXLwY3331 bxO+MTqE73YRvgEAnSCjnajlJ49e+ELtdTUSvuPwM1wCXUD4bhfhGwDQCTLO921fvVKbev6l73+v 1roI30B9hO92Eb4BAJ3x1AtntNbvP/7mx2uth/AN1Ef4bhfhGwDQKRK41QAugbwqwjdQH+G7XYRv AECnyNjf6tTzUopSder5voTvrfk8nk6W+xlNt9Z2zLfmszjaOV6yTDbnxtcn8XSm/n8z+zqLdrY5 mcbz+VbxvkWzkn2P4tl8fcdwSAjf7SJ8AwA65+xz92mt3w+dP17p93sTvmfTeGIJn2oozy0FQbWu +eZkuW4j4LYRvoteWxL6rT9X8LqT/Vd/H/URvttF+AYAdJIMN6iO/V1l6vm+hG9XaLS1iKdBvYVW cp/wqgfx+ttPW7uN9WxNI6XFPXv9k8mkvHXccRODegjf7SJ8AwA6SSbaUcf+lol4fPUhfBeVnFjD txpIzbKQ7dA5tZRwmOUkGxvudWZLForLWr6t6/cpIalwA5G2ynutt7mSmDEjfNe0f38cHz4cx+fO Ff4Y4RsA0FkPP/tZrfxEpqL30Y/w7Q6M9vCdD67W8LtTOqIF6+Rr08ja6uxugXeHb9s+uspX0vWl 2/evz/YL392onR8KwnftF7udrDeWy4EDy5lyLQjfAIDOko6Wxx+9Kg3fN51566JDZplehO+0jCQf RH1rvotaktOga4TWpOxDDdq1wrdl/WXlH22Fb/V1Eb5XR/iu/WKz8J0se/fG8XG9zwrhGwDQaVLr rbZ+3/ON60t/Z5jh2/ZzBa3nocJ3hU6hrpb3IoTv8HLh+0d/Kh8qWaotl1wSx0eOxPGFC4RvAED3 Pfj072oB/OvPP1T4822FbwklTaladlJ5HSXhW11vUy3f/q/Zf2QSyk7CM8P3vW/4CcJzU4u8N3GK AQC6TspP1LG/5f+Lxv5uKnx/+ew3tRAi/25K1Q6X9nUUBXilHnynBjsNskYrer2ab3uQVkctscn2 IfndWa423frzdLgMJnfe/50fJTSvuijlJ4RvAEAvPPndr2it39Ia7tJU+H7hxZfiN73jo2kI+cSn H2j0NdlKQEQT4XvxfWV4wqLylTrh273+8lZte8mK/hqyIQnLS1oYarBZcp4n57yc/3Id1DX6mm9L x0vCNwCgN6TeWw3g51981PpzTYVvcegjn9GCyJPPPNfY66lTuoE8Jtlpjpzf6g2nnP+rGGX43rWr cMhBwjcAoDdkpBMZ8SQJ3zISiq38pMnwLY/g1TBy+XtvXqklUJW1cFMuwTFcPzmv5fxWbzbPPP70 SuscVfiW95pjx+L44sXCHyN8AwB6Rcb6Vlu/ZSxwU5PhW9xxz8NaDew7P3B7Yy3gSckEHQVrHr+d 0hhavVcj57Oc1+p5Luf9qpjhMo/wDQDoHZntUp16XmbDVDUdvsXVN5zQgoksN9z++UY7YQKhyfkr 57F5bsv53gTCdx7hGwDQO3/x0lPa1PN3fu0a7ftthG95JH/tJz+XCylqOcp7rruDhaUXi1peYi5y nr/8yquNXDeE7zzCNwCglx46f1wrPzn73H3p99oI3wlpKXzbNbc6gwsLS18XOa+bfpJD+M4jfAMA ekk6Wt721Su1sb+TqefbDN8JmYBHHs0XtSCysHR9kfNXzuNVppAvQvjOI3wDAHrrqRfOaK3ff/zN jy++HiJ8m6TFkIWlT0sIhO88wjcAoNfuf+p3tAAuk/GsI3wDyCN85xG+AQC99tL3v6dNPX/r2XfF b/yv/yvCN9ABhO88wjcAoPcevfAFrfX7V//PnyV8Ax1A+M4jfAMABuEPn/hgGr4/+vAvxf/l3/8v CN/AmhG+8wjfAIBBkIl21LG/r/70PyF8A2tG+M4jfAMABuP0t/5IKz+59K0/SvgG1ojwnUf4BgAM yvFHr0rD9/X/8Rfjf/nrb+egAGtC+M4jfAMABuVbf/WE1vr9wc/+CgcFWBPCdx7hGwAwODLaiRrA ZTQUAOERvvMI3wCAwZFxvn/rcz+vTT0v44EDCIvwnUf4BgAMjsxw+eP/6O9ord8yEyaAsAjfeYRv AMDgJNPLX/Ghn9YC+PkXH+XgAAERvvMI3wCAwUnC9w+9dhpf/8V/mobv2756Zfz9v36FAwQEQvjO I3wDAAYnCd+y/OaH/7nW+v3Q+eONbOOFF1+Kv3z2m/Ed9zwcf+rOP2Fh6eUi56+cx3I+t4HwnUf4 BgAMjhq+ZZKdO792TRq+ZRbMv3jpqdrrPvP40/F7rrsj3vurH2ZhGdQi57Wc300ifOcRvgEAg2OG bwnb6tTzEsarkpbBD91yLyGNZfCLnOdNtYQTvvMI3wCAwTHDt5ByE7X85M++c4/3+l5+5dX4bdfc mgsp7/zA7fG1n/zc4vG9PLpnYenTIuetnL9yHpvntpzvct6vivCdR/gGAAyOLXxLR0t16vmbzrw1 fvHVC17re9+Nd+VCd9OP54F1kvPZDOESzFdF+M4jfAMABscWvoUMNai2ft/zjetL13Xnfae1QHL1 DSc4wBgsOb/V8/2BLz220voI33mEbwDA4LjCt5DJdtQA/uR3v1K4LrU18C1X3dTaqBBAF8j5Lee5 2glzFYTvPMI3AGBwisK3TDMv082rU8+7xv6Wmtc3veOjaRCRYdmAoZNa8OScl/N/FYTvPMI3AGBw isK3+PrzD2mt3w8+/bvW9UgdrPoInjpvjIF0xlTP+8eefLb2ugjfeYRvAMDglIVvcfe5I1oA/9Zf PZH/mQfPaCGkidEfgK575tvPa+e9XAd1Eb7zCN8AgMHxCd8y0ok69reMhGKWn5jhGxgDwne7CN8A gMHxCd9CxvpWW78ffvaz2vcJ3xgjwne7CN8AgMHxDd/iDx6/Wpt6/i9fzupb1xm+t+azONp5DRvR LPA2J/F0ttX+9qZRvDGZxvP5VozuIHy3i/ANABicKuFbar3V8pM/fOKD6ffWFb5n0Ua6/+kSIKSG DN9b83k8nSxfWzTdavS4TTbnvTtn1eOhL2FuhFSE73YRvgEAg1MlfIsvnr9NKz85+9x9ixbwD/+7 o8HD99ZsGk8W+x7FswG3CBO+Xcdj/X93wne7CN8AgMGpGr6lo+WtZ9+lTT0v/z30++8KH76lFKOg xVMrR3G0iqc/s/31aaT+TBZ41YCabnMy2Qn+y23btpX8ns9+FL5OLXxb9nfDHaRzTwYmURxZWo2z fXW0Kkcz+7FybDvM8SB8Dx3hGwAwOFXDtzA7X64tfOeCYhbCba3F881Jri7cGgR3vp8F7SwYZi3G U6XsJFtHEjAXP7cIrH774fs60/C9ka0zC9h6GE33X9nObHP5Wlwt38nxSPZVPT6+21Z/p+3jsWHs T2iE73YRvgEAg1O15tsc83ud4TuRb93dDpiW4JyWqahf08KlHt7Mum7938r/b0bO1tstz/0oYg/f 6o2Gvf48ezKQf21Vyk6Sn/Xdtu01N3k8rH/zjfWU0RC+20X4BgAMjm/4lnKTh84f1zpcdiV8J9Sw OZlMrOFswxm+7aUrakhVW5K139uMnC236j7V7RhaN3yLtFXZaNUvCt+uYFs5fLd0PGxmUbjOtirC d7sI3wCAwaladiKdK2WUky6Gb5GGyiR8l4SxsvCtttROo6wV2Rq+PVt6q1olfKfrSDunLn/GWXZS UGrTVst3E9KbDML3oBC+AQCDU6fmWzz53a/Et331yrWG7yRwaXXFBXXYQsKf9u+y8J2rL17WNttL UIy6Zq2FvHg/iqxSdpLv5Lj8GT2szuLZ1B6cs9BeIXzPWz4ei33Ktqe21FN20g9PveB3nAjfAIDB qRu+hZSiyEyXUoqylg6XSjC0drq0fn+jUvgWWulG0hnTrAe3bCsNvh77Ufg6G6j5LtunrINlvjNj FEXVt93m8XD8Ph0u++POr10T3/znv7YoZXvx1QvOnyN8AwAGZ5XwnZAPz//7zt9menmMDuG7Hgnf 6my5f/zNjy86dJsI3wCAwWkifIt1Ti8PrIsZvj9+182L1tw6y7/67X3xLxzcvVjk/+uupw+LOleA ukgof/TCF9LjS/gGAAwO4RuozwzfUn5lC5Us1RYJ51LSRvgGAAwO4Ruoj/DdziL14IRvAMAgEb6B +ig7abbs5A8ev5qyEwDAsBG+gfrocFmP2uFSlnu+cX18/sVHcz9H+AYADA7hG6iP8F2PhO+bzrw1 /uL52xYTd7kQvgEAg0P4BuojfNcjk3TJPAFlCN8AgMHZvXt3+oF/4MCB2ushfGOMCN/tInwDAAZn 3759jXzgE74xRk2G7z179jTyFGpICN8AgME5ePBg+oEvJSh1Eb4xRk2G7127dqXX4uHDhzm4MeEb ADBA73//+9MPfFnqWlf43prP4+lkue/RdGttx3FrPosj5ThONufG1yfxdKb+fzP7Oot2tjmZxvO5 fZ1bs2k8MfbLvu9RPJuv7xj2UVPh+8KFC9p1eOzYMQ5uTPgGAAzQLbfcon3onz9/vtZ61ha+k2Bp hE81lOeWgqBa13xzslx3NNP3r4XwXfTa1HBt3hBkS377yf7bwjncmgrfjzzyiPY3OnHiBAc3JnwD AAbo3LlzjbS4rSt8u0KjrUVcbQFuupXcJ7zqQbz+9tPWbmM9W9MoH76VGw35/oajBdx1E4NiTYXv I0eOpH+b6XRa+yZ4aAjfAIBBamKUhXWE76KSE2v4Vr6WKwvZDp1TSwmHq/XYtk5by3JZy7d1/UUl JMrPV72BKCo/aerGYGyaCt/qqEPSCRpLhG8AwCBJa7ca/qQ1vKr1hG93YLSH73xwtYbfndIRLVgn X0tbj/Vtulvg3eHbto+u8pV0fen2q9dnp+v2PF4o10T4Pn36tHb+HT9+nAO7g/ANABgk6ewlj7qT D/9Dhw5VXse9p85qIeSFF19qfb+zltx8EPWt+S5qSU6DrtESnZR9qEG7Vvi2rL+s/KNu+PYpuUle F+Hb33ee/5523st1UJWMr5+cmzLiycWLFzmwOwjfAIDB2r9/v1ZzKq1xVZgtgA986bHW97l6+Lb9 XEHreajwXaFTqKvl3e84FdekE76rk/NcPe/lOqji5MmT2t+9zo3vkBG+AQCDJaMtqK3fdWq/3/zu j6Uh5BOffqD1fa5adlJ5HSXhW11vUy3f/q/Zb2QSNeAXHwfKTur40C33puf8W666qdLvSgu3Wut9 ySWX0NHSQPgGAAyaOea3DENYxftuvCsNIm96x0fjM48/3er+Vu1waV9HUYBX6sF3arCzumm9Fb1e zbc9SJujlpiyfUh+d5arTV+sR2nx3nDUtfscB9h9+ew3tVbvaz/5uaDX2xgQvgEAgyYtcTLLpVp+ Io/FfT325LOL0J2EkcuuvHHxtTbZSkBEE+F78X1rgM2Xr9QJ3+71l7dq20tWjKEHi8K38RoYarAa Oa/l/E7OdXnqU6XkxBxff+/evRxUC8I3AGDw7r//fq38RP5fvubLHPVElhtu/3xrreB1SjeQxyQ7 fuQ8lvPZPMer9HGQ0UzU4C2dLKXsC3mEbwDAKMjsemY4OHXqlPfvf+rOP8mFk2R52zW3xu+57o7G lqyFe9nq2+S6x7JwDMsXOW9d57Sc777kSZJ5c1vl2hobwjcAYDTMx+KyyCx8vqSFsCiwNLkkJRNS XhJie0NbktIYafXmePgvcn77PtGRkq7Dhw9r11PVsq4xInwDAEbFFsClNrXKiAx33nd60XIoI0EQ 2Fj6vsh5fOgjn6k0mY6UlMh1Q/CujvANABgdeSQuQ6CZZSgyUkOdYdFkhAgWlj4uVcnkVXKdyPWi Xj8yvCClJn4I3wCAUZIQoU7Co7beyaQgjE0MZOR6kOtCre1OliuuuGJxPcEP4RsAMGrHjh3LteKp 5ShSE06LHsZIzntp5TbLS5JFhvCUUU5QDeEbADB60mp39OjRXCmKWZYiM2TKcvDgwUUoYWEZ0iIt 2Mk5bmvhVkM3k+fUR/gGAGCHjN4gIdzV0sfCMuZFQjmhe3WEbwAALKQ1XB6pSyu3OkMmC8tYFulE Kee/jJEvN6ZoBuEbAABPUgMrM2PKQpkCy9AWGSZQzm36OLSL8A0AAAAEQvgGAAAAAiF8AwAAAIEQ vgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4B AACAQAjfAAB0zNZ8Hk8nG/HGRhTP5lstbmcWRxuyne0lmgV6bck2J/F0thUPQfaa2v17zaKdv9Vk Gs/nwzh2Y0T4BgCgRVmQzodcV2hLQ5YRtHLrsizR1C+UadvYCBfqQobvOsd+tdfUfPgu+ptPNudc YD1E+AYAoEW28JQEZFtoU8PpZOIO1Op6fQN3+ruzaTwJ0FLbt2Nffzvthe/sJkm/WdmaRoTvniJ8 AwDQoiwATuIommgtzNbwvR2qklba+ebEWRKyUvhOtuFofdbKURyt4unPbH99qpVDZPulhsN0m5PJ TvBfbtu2reT3fPajqWNv3Zbrxie9edkwXpMevlff/+z3q/6N0V2EbwAAWqQGwOksC1MSMPMBUP3Z LSXk5UPySuE71yKcrd+2XttNgDVY7nw/C9pZ0ExacCebU6XsRD8e6c9tr8d3P5o59srxMF+D2eJs 1MnrQVx9gtHA/qf7MOwnFGND+AYAoEW5QK0FKiN8J0EubZ21tyLr663fKpqr+5btWoKzuV/L7btb Zc26bv3fyv9vRs7W4C3P/Wjk2E/t+5HdMMyL96voCcYq+0/4HiTCNwAALTIDoEhDbxRpoS1tGd0o 7wzZRPhO15WGvO2gOfHbh7KOk2pwVUtptN/bjNxlNco+1e0Y6n3s2wzfq+x/SXkQ+onwDQBAi2wB MFczrLXE+o1k0mT4FmnQnEy8AmJZ+FZDalITLvtpDd+eLd+tHfuS8K0d9xVavqvvf74sB/1H+AYA oEW2ACj0Vm53ABRZa+3Mst7q4TvZtlZnXVCHvdieMbpGafjO1ZWbHRv1bWl13loLefF+NHLsLeOd Zz9T0ImysOZ79f3P76usa5arT0e/EL4BAGiRKwDq4TSKo6hgdA1L7W8zQw06Ol1av79RKXwLLTgm HRnNenDLttLRTjz2o4ljr9Xbb+RvGNx/j+y1LW9gjKC+4v47t0cpSq8RvgEAAIBACN8AAABAIIRv AAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAA ACAQwjcAAC3bms/j6WQj3tjYiKPp1pr2YRZHG7IPk3g62yr4fhTP5lu11tG9497u/jax/r4dU6yO 8A0AQMu2ZtN4IgFrMo3nc8J3V15zF9ZP+B4fwjcAAC2bb04Wrd6Tzfna9oHw3c39JXyPD+EbAIAW lZWcZOErW5KQbvueuR5beLMFafPn0tb4ZJlMdv7tF76jaGLd56LXVdbyrx4rbYlm9nVvr28abTj3 w2d/1W1qvzuN0n02t5G8jtwxdfwti14X4Xt8CN8AALSoKFypYS0JfrMoCWVKYNsJn2kgtAbtKuFb CYmyLS2I+4TvbHtJq76+/fwNR/pzRpC2rT/5HXV79huO7Hv2/cj/3CzKv041aCc3B8nPTSb5/Z5t 2sJ30d+y6HURvseG8A0AQIuyYJsPtbbQV/a9NBTmWscrhO/N/Lrrlp3YWo5t+1637j15veWt/Zb9 KDw29pAu29GORXrDk39yUXZM/V4X4XtsCN8AALTIK3xbWoP7Er6t+6QE1o2KpSezyP57ZeG7+rHR f1dtmTf/LlmruvEkwnZMHS377tdF+B4bwjcAAC0qLDtZoeU7X8Kw/pbvdJ+m1VqBi15znZZvv2Oj /z3U1x9Fjpbu9EbKrPEubvkufl2E77EhfAMA0KKiDpdaTbJa5611xLO1wKqhWqkNl3CntTq3WfNd UENtqWVffH1734pGfDFDqrpfZTXfxftRHr6F3jq9XI+6z+4OlpZjqv4tC18X4XtsCN8AALTMLIdQ 5UYdUcsmLN8rLF9Rwt9ymwWjnXj8Tm5fC0YZcbcSbxSOiqKvPz8qSBRFhS3f5igm/iPBWJ5EKPtc VELjDOOOv2Xx6yJ8jw3hGwCAltUtw4DjeLY0PB/D/iEEwjcAAC3LWj4Jdc0cz3ZCclrWw00SWkT4 BgAggKQkwTbRDioey/Rmxl0iU3+d/I3QLsI3AAAAEAjhGwAAAAiE8A0AAAAEQvgGAAAAAiF8AwAA AIEQvgEACMxnKvfV1tuPIQ2X45/b9zUZfaRoUp4u/g2AMoRvAAACI3wvpdO5W8bVTsfcjmY7r82c JdIy06cx7Xzyuy7JNtoK+IAN4RsAgMBodd05Dul07PrNgm1SIvVryZTyZmhOw/Rk4hW+0+0zqQ4C InwDANCyLGQmLb2TnX/r4TvXcmsEQ7X1Vw2e2fT1k1yYta1TfrdsW87XYvs9Y2Ka9Ge21zctaN12 vh5LKNYC+dT2feWGJjkeZeGb6eSxBoRvAABapIXV7TCoB/EsfNtmWDRLLxY/lwbtLHgm5RuTzakW JtVtJ+F28bPR1Gtb+deilH4k5SDJ/pQEftd6bVO628pB9Nbw/LHaUgL3lnf4ZlZLhEf4BgCgRbaw bCs7sf7crKiF1wzY8m/je5Z1VtmWz2sRWfifG/tYHmqLX4+7FEUL2wXfK5PsO+EboRC+AQBoUeXw bVsKwq4eQh3h2wihVbZV9lrM/dFfn185h+v1aNs2A7a6DaMMhfCNLiN8AwDQolVavn3WOVXCozN8 e7R8130twgywVcO36/VoP2PphJmOlrLhLkEp3C5lJ1gDwjcAAC3yr/nO12cvvr4dJM1RPVzD7rlL OIzyjCjy3lbRaxFpzbb1tXiG71yNuG0YQcsIKK5jSYdLdBjhGwCAluXKPLZD4bLV1hjtxBwVxRKQ E1noVcfCzodJ2zoX5R0VtqW9FuvvuUZt8Q+16uux7UPx8IOO0V8YahAdRPgGAACjxCQ7WAfCNwAA GB1bSzoQAuEbAACMTlIaQ6s3QiN8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsA AAAIhPANAAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAA CITwDQAAAARC+AYAAAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE 8A0AAAAEQvgGAAAAAiF8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPAN AAAABEL4BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAA AARC+AYAAAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEAjhGwAAAAiE8A0AAAAE QvgGAAAAAiF8AwAAAIEQvgEAAIBACN8AAABAIIRvAAAAIBDCNwAAABAI4RsAAAAIhPANAAAABEL4 BgAAAAIhfAMAAACBEL4BAACAQAjfAAAAQCCEbwAAACAQwjcAAAAQCOEbAAAACITwDQAAAARC+AYA AAACIXwDAAAAgRC+AQAAgEAI3wAAAEAghG8AAAAgEMI3AAAAEMj/D083vFQIMiS4AAAAAElFTkSu QmCC --_004_ECB9F6E791C0448BA5136E2D79462C86ciscocom_-- From Cathy.H.Zhang@huawei.com Mon Feb 10 13:23:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2851A0452; Mon, 10 Feb 2014 13:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 OCIJ7joYEH4P; Mon, 10 Feb 2014 13:23:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C12281A0407; Mon, 10 Feb 2014 13:23:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ20304; Mon, 10 Feb 2014 21:23:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 21:22:28 +0000 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; Mon, 10 Feb 2014 21:23:37 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.228]) by SJCEML703-CHM.china.huawei.com ([169.254.5.128]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 13:23:23 -0800 From: Cathy Zhang To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmkUAauKj/rzmUy13AQN4o8lEpqvG8GAgABFpACAABNCAP//gUTAgACLoYD//33IAA== Date: Mon, 10 Feb 2014 21:23:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.79] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F0D809SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:23:44 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F0D809SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn = (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for "Service = Instance" to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_A2C96F6779E6A041BC7023CC207FC99418F0D809SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

 <= /p>

Could you clarify what yo= u mean by an instance of a service function instance?

 <= /p>

Thanks,=

Cathy

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul= Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as = Reinaldo.

I think each Service Func= tion is associated with a type, such as FW Service Function or NAT Service = Function

while each Service Instan= ce is an instantiation of a Service Function on a Service Node and is = associated with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, th= ere could be multiple Service Nodes (physical/virtual) that support a speci= fic Service Function, such as FW,

and a service instance co= uld be instantiated on any one of the Service Nodes (as to which Service No= de to instantiate the service instance,

it depends on load status= of the Service Nodes, network proximity etc., which is out of scope) .&nbs= p;

Multiple flow chains can = be associated with the same Service Instance on a Service Node, which means= these flows will be applied the same policy set

for that specific type of= service function, as shown in the following diagram.

 <= /p>

BTW, I would like to sugg= est that the draft adds a definition for “Service Instance” to = bring everyone on the same page as to its semantics.

 <= /p>

Thanks,=

Cathy

<image002.png>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I s= ee this differently.

 

The same service function c= ould be instantiated with  policy-set-A and later instantiated with &n= bsp;policy-set-B. It is still the same service function, but different instances. 

 

Therefore I would consider = {1 below} one service function (say, NAT44) and two different service funct= ion instances, one that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A service function that applies policy-set-A and a different s= ervice function that applies policy-set-B e.g. They are two distinct servic= e functions.
--_000_A2C96F6779E6A041BC7023CC207FC99418F0D809SJCEML701CHMchi_-- From prvs=111425afc=Nicolas.BOUTHORS@qosmos.com Mon Feb 10 14:30:29 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AEA1A0488; Mon, 10 Feb 2014 14:30:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1bcMmMWZDqG; Mon, 10 Feb 2014 14:30:25 -0800 (PST) Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.198]) by ietfa.amsl.com (Postfix) with ESMTP id 775DF1A05F2; Mon, 10 Feb 2014 14:30:24 -0800 (PST) Received: from smtp-ex6.fr.colt.net (smtp-ex6.fr.colt.net [213.41.78.122]) by smtp-ft6.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1AMUJCD007658; Mon, 10 Feb 2014 23:30:19 +0100 Received: from mx1.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex6.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WCzMs-000619-2g; Mon, 10 Feb 2014 23:30:23 +0100 X-IronPort-AV: E=Sophos;i="4.95,820,1384297200"; d="scan'208,217";a="843411" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 10 Feb 2014 23:30:17 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Mon, 10 Feb 2014 23:30:20 +0100 From: Nicolas BOUTHORS To: "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , Ron Parker , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJqKEUCP4sPS0Aku8XlnmSAALBJqvDt7f Date: Mon, 10 Feb 2014 22:30:15 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3E364D@LILAS.jungle.qosmos.com> References: , 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: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D3E364DLILASjungleqosmos_" MIME-Version: 1.0 X-ACL-Warn: 2/2 recipients OK. Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:30:29 -0000 --_000_76B41B8FACE1514795D30EC137FF391D3E364DLILASjungleqosmos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMHO: in draft-quinn-sfc-arch-04.txt definitions: "Service Function (SF): A function that is responsible for specific treatm= ent of received packets. " So two instances of a Service Function should apply the same policy, as the= policy is what make the treatment of received packets to be specific. A type of Service Function (eg. FW vs NAT44) is not enough to identify prec= isely a Service Function. There is a need for a descriptor for what makes it specific, and a name so = that it can be identified. Very similar to a class/object paradygm in fact, as a class describes the b= ehavior of its instances. Nicolas ________________________________ From: Reinaldo Penno (repenno) [repenno@cisco.com] Sent: Monday, February 10, 2014 9:21 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_76B41B8FACE1514795D30EC137FF391D3E364DLILASjungleqosmos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
IMHO:

in draft-quinn-sfc-arch-04.txt definitions:
"Service Function (SF)=
:  A function that is responsible for specific treatment of received packet=
s. "

So two instances of a Service Function =
should apply the same policy, as the policy
is what make the treatment of received =
packets to be specific.

A type of Service Function (eg. FW vs N=
AT44) is not enough to identify precisely a Service Function. <=
/pre>

There is a need for a descriptor for what makes it=
 specific, and a name so that it can be identified.


Very=
 similar to a class/object paradygm in fact, as a class describes the behav=
ior of its instances.








 


Nicolas


   






From: Reinaldo Penno (repenno) [repenno@c=
isco.com]

Sent: Monday, February 10, 2014 9:21 PM

To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn

Cc: Paul Quinn (paulq); sfc; sfc@ietf.org

Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc=
-arch-04.txt










Based on the definition I see this differently.







The same service function could be instantiated with  policy-set-=
A and later instantiated with  policy-set-B. It is still the same serv=
ice function, but different instances. 







Therefore I would consider {1 below} one service function (say, NAT44)=
 and two different service function instances, one that applies  polic=
y-set-A and other that applies  policy-set-A.









From: "Jim Guichard (jguichar)=
" <jguichar=
@cisco.com>

Date: Monday, February 10, 2014 at =
11:12 AM

To: Ron Parker <Ron_Parker@affirmednet=
works.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn"
 <meng.wei2@zt=
e.com.cn>

Cc: "Paul Quinn (paulq)" =
<paulq@cisco.com>, "sfc@ietf.org=
" <sfc@ietf.o=
rg>,
 sfc <sfc-boun=
ces@ietf.org>

Subject: Re: [sfc] Fwd: New Version=
 Notification for draft-quinn-sfc-arch-04.txt









    

  1. A service function that applies policy-set-A and a different service fu=
nction that applies policy-set-B e.g. They are two distinct service functio=
ns.
--_000_76B41B8FACE1514795D30EC137FF391D3E364DLILASjungleqosmos_-- From Ron_Parker@affirmednetworks.com Mon Feb 10 14:36:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE00C1A08A5; Mon, 10 Feb 2014 14:36: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGe9hNod43dt; Mon, 10 Feb 2014 14:36:37 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7D1A05F2; Mon, 10 Feb 2014 14:36:34 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 14:36:34 -0800 From: Ron Parker To: Nicolas BOUTHORS , "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgCAABNCAIAAI/mA//9677A= Date: Mon, 10 Feb 2014 22:36:33 +0000 Message-ID: References: , <76B41B8FACE1514795D30EC137FF391D3E364D@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E364D@LILAS.jungle.qosmos.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_CDF2F015F4429F458815ED2A6C2B6B0B1A7A36CDMBX021W3CA2exch_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:36:41 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A36CDMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nicolas, I'm supportive of both mechanisms that Jim described: a) The SF instance identity implies its policy set b) The SF instance locally selects its policy set through means not sp= ecified by SFC The first provides useful simplification while the second more naturally su= pports highly differentiated policy behaviors. So, does a service instance identity fully specify its behavior? It depen= ds. Ron From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Monday, February 10, 2014 5:30 PM To: Reinaldo Penno (repenno); Jim Guichard (jguichar); Ron Parker; meng.wei= 2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt IMHO: in draft-quinn-sfc-arch-04.txt definitions: "Service Function (SF): A function that is responsible for specific treatm= ent of received packets. " So two instances of a Service Function should apply the same policy, as the= policy is what make the treatment of received packets to be specific. A type of Service Function (eg. FW vs NAT44) is not enough to identify prec= isely a Service Function. There is a need for a descriptor for what makes it specific, and a name so = that it can be identified. Very similar to a class/object paradygm in fact, as a class describes the b= ehavior of its instances. Nicolas ________________________________ From: Reinaldo Penno (repenno) [repenno@cisco.com] Sent: Monday, February 10, 2014 9:21 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A36CDMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nicolas,

 <= /p>

I’m supportive of b= oth mechanisms that Jim described:

 <= /p>

a) = ;     The SF instance i= dentity implies its policy set

b) = ;     The SF instance l= ocally selects its policy set through means not specified by SFC=

 <= /p>

The first provides useful= simplification while the second more naturally supports highly differentia= ted policy behaviors.

 <= /p>

So, does a service instan= ce identity fully specify its behavior?   It depends.<= /span>

 <= /p>

   Ron

 <= /p>

 <= /p>

From: Nicola= s BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com]
Sent: Monday, February 10, 2014 5:30 PM
To: Reinaldo Penno (repenno); Jim Guichard (jguichar); Ron Parker; m= eng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

IMHO:
 
in draft-quinn-sfc-=
arch-04.txt definitions:
"Service Function (SF): =
; A function that is responsible for specific treatment of received packets=
. "
 
So two instances of a Service Func=
tion should apply the same policy, as the policy
is what make the treatment of rece=
ived packets to be specific.<=
/span>
 
A type of Service Function (eg. FW=
 vs NAT44) is not enough to identify precisely a Service Function. 
There is a need for a descriptor f=
or what makes it specific, and a name so that it can be identified.<=
span style=3D"color:black">
Very similar to a class/object par=
adygm in fact, as a class describes the behavior of its instances.
 
 
 
Nicolas
   

From: Reinaldo Penno (repenno) [re= penno@cisco.com]
Sent: Monday, February 10, 2014 9:21 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

Based on the definition = I see this differently.

 =

The same service functio= n could be instantiated with  policy-set-A and later instantiated with=  policy-set-B. It is still the same service function, but different i= nstances. 

 =

Therefore I would consid= er {1 below} one service function (say, NAT44) and two different service fu= nction instances, one that applies  policy-set-A and other that applie= s  policy-set-A.

 =

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com= >
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee= <repenno@cisco.c= om>, "meng.wei2@zte.com.cn" <meng.wei2@zt= e.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, sfc <sfc-bounces@ietf.org> Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 =

  1. A service function that applies policy-set-A and a different s= ervice function that applies policy-set-B e.g. They are two distinct servic= e functions.
--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A36CDMBX021W3CA2exch_-- From linda.dunbar@huawei.com Mon Feb 10 14:49:50 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051F61A05F2; Mon, 10 Feb 2014 14:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ahWxvbaIb83X; Mon, 10 Feb 2014 14:49:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9A91A08A8; Mon, 10 Feb 2014 14:49:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL36854; Mon, 10 Feb 2014 22:49:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 22:48:45 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 22:49:38 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 14:49:26 -0800 From: Linda Dunbar To: "Jim Guichard (jguichar)" , Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmkUougjQlmwOEyv0I28a+293JqvG8GAgABFpACAABNCAIAACXsAgAADaoD//4zcwA== Date: Mon, 10 Feb 2014 22:49:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7B28A@dfweml701-chm.china.huawei.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.242] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C7B28Adfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:49:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C7B28Adfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can see that from service perspective, the NAT44-A and NAT44-B are differ= ent instances (or aspects) of NAT function. However, there could be multiple "entities" of NAT44-B (e.g. one "entity"= only has 10G capability), and many "entities" of NAT44-B. Each entity has = its own unique address (or Locator in draft-parker-sfc-chain-to-path). >From network steering perspective, any of the "entities" for NAT44-B can b= e used for a chain that needs NAT44-B. But a Service/Network forwarding node can't use NAT44-B for a chain that ne= eds NAT44-A, so maybe the NAT44-A and NAT44-B can be considered as differen= t service functions? Some people (like Jim) call those "entities" as "instances" because they = perform the same function but with different addresses. How about we call those multiple "entities" as a "component"? in the same = way as the "component" in server cluster http://en.wikipedia.org/wiki/Compu= ter_cluster Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, February 10, 2014 3:08 PM To: Cathy Zhang Cc: sfc@ietf.org; sfc; Paul Quinn (paulq); Ron Parker; meng.wei2@zte.com.cn= ; Reinaldo Penno (repenno) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for "Service = Instance" to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_4A95BA014132FF49AE685FAB4B9F17F645C7B28Adfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can see that from servi= ce perspective, the NAT44-A and NAT44-B are different instances (or aspects= ) of NAT function.

 <= /p>

However, there could be &= nbsp;multiple “entities” of NAT44-B (e.g.  one “enti= ty” only has 10G capability), and many “entities” of NAT4= 4-B. Each entity has its own unique address (or Locator in draft-parker-sfc-chain-to-path).<= /span>

 <= /p>

From network steering per= spective, any of  the “entities” for NAT44-B can be used f= or a chain that needs NAT44-B.

 <= /p>

But a Service/Network for= warding node can’t use NAT44-B for a chain that needs NAT44-A, so may= be the NAT44-A and NAT44-B can be considered as different service functions? 

 <= /p>

Some people (like Jim) ca= ll  those “entities” as  “instances” beca= use they perform the same function but with different addresses.

 <= /p>

How about we call those m= ultiple “entities” as a “component”?  in the same way as the “compone= nt” in server cluster http://en.wikipedia.org/wiki/Computer_cluster

 <= /p>

Linda

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: sfc@ietf.org; sfc; Paul Quinn (paulq); Ron Parker; meng.wei2@zte= .com.cn; Reinaldo Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as = Reinaldo.

I think each Service Func= tion is associated with a type, such as FW Service Function or NAT Service = Function

while each Service Instan= ce is an instantiation of a Service Function on a Service Node and is = associated with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, th= ere could be multiple Service Nodes (physical/virtual) that support a speci= fic Service Function, such as FW,

and a service instance co= uld be instantiated on any one of the Service Nodes (as to which Service No= de to instantiate the service instance,

it depends on load status= of the Service Nodes, network proximity etc., which is out of scope) .&nbs= p;

Multiple flow chains can = be associated with the same Service Instance on a Service Node, which means= these flows will be applied the same policy set

for that specific type of= service function, as shown in the following diagram.

 <= /p>

BTW, I would like to sugg= est that the draft adds a definition for “Service Instance” to = bring everyone on the same page as to its semantics.

 <= /p>

Thanks,=

Cathy

<image002.png>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I s= ee this differently.

 

The same service function c= ould be instantiated with  policy-set-A and later instantiated with &n= bsp;policy-set-B. It is still the same service function, but different instances. 

 

Therefore I would consider = {1 below} one service function (say, NAT44) and two different service funct= ion instances, one that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <= ;jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A service function that applies policy-set-A and a different s= ervice function that applies policy-set-B e.g. They are two distinct servic= e functions.
--_000_4A95BA014132FF49AE685FAB4B9F17F645C7B28Adfweml701chmchi_-- From repenno@cisco.com Mon Feb 10 14:54:30 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC28B1A0892; Mon, 10 Feb 2014 14:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHNk9DTpZfnl; Mon, 10 Feb 2014 14:54:27 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73D1A0488; Mon, 10 Feb 2014 14:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14399; q=dns/txt; s=iport; t=1392072866; x=1393282466; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=GTwYujlSQkpiLMOHzBYxEB6xEARR2H9MVGmtFtnflH0=; b=NBZ4UBnszeHskDYu2d48vqYpfrHB+4uQV06SDimjF4WgetISxXvA6UdH DQ1uz9ToIQNbm+yqiRW+Y3I/OLGYNYJy18lpd1LCVoR9vFDbGU9by2oo3 I8hm0ry481ZWIB1R8YpbvgIIrW/fqPK+Yh7H9bJlPoJhxRNQ+Zb6ptpy6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAOJX+VKtJV2c/2dsb2JhbABPCoJIRDhXtX+IVIEXFnSCJQEBAQRUIwISAQgRAwEBASg5FAkIAgQBDQWIBQ3JXheOIUsRBgGEOASYK4EykG6DLYIq X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="19392608" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 10 Feb 2014 22:54:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1AMsPdg009693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 22:54:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 16:54:25 -0600 From: "Reinaldo Penno (repenno)" To: Nicolas BOUTHORS , "Jim Guichard (jguichar)" , Ron Parker , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoJqu+juAgABFpAD//40egIAAqh2A//+AooA= Date: Mon, 10 Feb 2014 22:54:24 +0000 Message-ID: In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E364D@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.2.3.120616 x-originating-ip: [10.21.88.142] Content-Type: multipart/alternative; boundary="_000_CF1E97178DAArepennociscocom_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:54:31 -0000 --_000_CF1E97178DAArepennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Nicolas, Inline with [RP] From: Nicolas BOUTHORS > Date: Monday, February 10, 2014 at 2:30 PM To: Cisco Employee >, "Jim Guic= hard (jguichar)" >, Ron Parke= r >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, sfc >, "sfc@ietf.org" > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt IMHO: in draft-quinn-sfc-arch-04.txt definitions: "Service Function (SF): A function that is responsible for specific treatm= ent of received packets. " So two instances of a Service Function should apply the same policy, as the= policy is what make the treatment of received packets to be specific. [RP] I see =93specific treatment of packets=94 as in NAT44 translate source= IPv4 packets and Firewalls accept/blocks connections. So, they treat pack= ets differently A type of Service Function (eg. FW vs NAT44) is not enough to identify prec= isely a Service Function. [RP] Yes it is., it depends on your approach. NAT44 behavior is defined in= http://tools.ietf.org/search/rfc4787 There is a need for a descriptor for what makes it specific, and a name so = that it can be identified. Very similar to a class/object paradygm in fact, as a class describes the b= ehavior of its instances. [RP] The SFC NAT44 class would describe basically http://tools.ietf.org/sea= rch/rfc4787 and a specific instance would have the actual policies. Nicolas ________________________________ From: Reinaldo Penno (repenno) [repenno@cisco.com= ] Sent: Monday, February 10, 2014 9:21 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1E97178DAArepennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2963F4C66D495445A7040B63044DE1BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello Nicolas,

Inline with [RP]

From: Nicolas BOUTHORS <Nicolas.BOUTHORS@qosmos.com>=
Date: Monday, February 10, 2014 at = 2:30 PM
To: Cisco Employee <repenno@cisco.com>, "Jim Guichard (jgu= ichar)" <jguichar@cisco.com>, Ron Parker <R= on_Parker@affirmednetworks.com>, "meng.wei2@zte.com.cn&quo= t; <meng.wei2@zte.com.cn>=
Cc: "Paul Quinn (paulq)" = <paulq@cisco.com>, sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

IMHO:

in draft-quinn-sfc-arch-04.txt definitions:
"Service Function (SF)=
:  A function that is responsible for specific treatment of received packet=
s. "

So two instances of a Service Function =
should apply the same policy, as the policy
is what make the treatment of received =
packets to be specific.

[RP] I see =93specific treatment of packets=94 as in NAT44 translate s= ource IPv4 packets and Firewalls accept/blocks connections.  So, they = treat packets differently

A type of Service Function (eg. FW vs N=
AT44) is not enough to identify precisely a Service Function. <=
/pre>

[RP] Yes it is., it depends on your approach.  NAT44 behavior is = defined in  http://to= ols.ietf.org/search/rfc4787 

There is a need for a descriptor for what makes it=
 specific, and a name so that it can be identified.
Very=
 similar to a class/object paradygm in fact, as a class describes the behav=
ior of its instances.

[RP] The SFC NAT44 class would describe basically http://tools.ietf.org/search/rfc4787&= nbsp;and a specific instance would have the actual policies.




 
Nicolas
From: Reinaldo Penno (repenno) [repenno@cisco.com]
Sent: Monday, February 10, 2014 9:21 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

Based on the definition I see this differently.

The same service function could be instantiated with  policy-set-= A and later instantiated with  policy-set-B. It is still the same serv= ice function, but different instances. 

Therefore I would consider {1 below} one service function (say, NAT44)= and two different service function instances, one that applies  polic= y-set-A and other that applies  policy-set-A.

From: "Jim Guichard (jguichar)= " <jguichar= @cisco.com>
Date: Monday, February 10, 2014 at = 11:12 AM
To: Ron Parker <Ron_Parker@affirmednet= works.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zt= e.com.cn>
Cc: "Paul Quinn (paulq)" = <paulq@cisco.com>, "sfc@ietf.org= " <sfc@ietf.o= rg>, sfc <sfc-boun= ces@ietf.org>
Subject: Re: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

  1. A service function that applies policy-set-A and a different service fu= nction that applies policy-set-B e.g. They are two distinct service functio= ns.
 --_000_CF1E97178DAArepennociscocom_-- From repenno@cisco.com Mon Feb 10 15:04:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007AD1A08A2; Mon, 10 Feb 2014 15:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P0FNaaNRxoH; Mon, 10 Feb 2014 15:04:20 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 022A41A060D; Mon, 10 Feb 2014 15:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25890; q=dns/txt; s=iport; t=1392073460; x=1393283060; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=J//XhhiacWTspLk93UEyrmpgf0cz6Or7Hbwik7ssQuU=; b=Xa5v3LX8/wRRaxaREe+qh/TE+Ppleaa9K6OrE6wX7Itee5CQj5ZsYs7l MjAdMdRrxTf77O9aeXde67vn+bJcKwGvL3ZJ68ZxD33pAQrOyv+qP60py rub4aS+uh4WYRFCHoOy2ZkvWozDEj9RDG04sBWSHXJZw+IXECAWUbvwfz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GAMNZ+VKtJXG+/2dsb2JhbABZgkhEOFe1f4hUgRcWdIIlAQEBBC1KAhIBCBEDAQEBIQc5FAkIAgQBDQWIBQ3JYBeOWRMRBgGEOASYK5Iggy2CKg X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="19396524" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 10 Feb 2014 23:04:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1AN4JXN013709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:04:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:04:18 -0600 From: "Reinaldo Penno (repenno)" To: Linda Dunbar , "Jim Guichard (jguichar)" , Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoJqu+juAgABFpAD//40egIAAj58AgAADaoCAABxwAP//fgqA Date: Mon, 10 Feb 2014 23:04:18 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7B28A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.142] Content-Type: multipart/alternative; boundary="_000_CF1E98B38DBCrepennociscocom_" MIME-Version: 1.0 Cc: Ron Parker , "meng.wei2@zte.com.cn" , "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:04:23 -0000 --_000_CF1E98B38DBCrepennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Linda Dunbar = > Date: Monday, February 10, 2014 at 2:49 PM To: "Jim Guichard (jguichar)" >, Cathy Zhang > Cc: "sfc@ietf.org" >= , sfc >, "Paul Quinn (pau= lq)" >, Ron Parker >, "meng.wei2@zte.c= om.cn" >, Cisco Employee > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt I can see that from service perspective, the NAT44-A and NAT44-B are differ= ent instances (or aspects) of NAT function. However, there could be multiple =93entities=94 of NAT44-B (e.g. one =93e= ntity=94 only has 10G capability), and many =93entities=94 of NAT44-B. Each= entity has its own unique address (or Locator in draft-parker-sfc-chain-to= -path). >From network steering perspective, any of the =93entities=94 for NAT44-B c= an be used for a chain that needs NAT44-B. But a Service/Network forwarding node can=92t use NAT44-B for a chain that = needs NAT44-A, so maybe the NAT44-A and NAT44-B can be considered as differ= ent service functions? [RP] I would consider them the same service function but different instance= s. IMHO if a NAT44 performs as described in RFC4787, then that belongs to t= he NAT44 service function class. The configuration, rules and policies insi= de a specific instance of NAT is what makes it different. Now, I can see how one could consider each different NAT44 configuration as= a different service function. But in that case you would have gazillions o= f service functions when in fact you only need a small number. Some people (like Jim) call those =93entities=94 as =93instances=94 becau= se they perform the same function but with different addresses. How about we call those multiple =93entities=94 as a =93component=94? in t= he same way as the =93component=94 in server cluster http://en.wikipedia.or= g/wiki/Computer_cluster Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, February 10, 2014 3:08 PM To: Cathy Zhang Cc: sfc@ietf.org; sfc; Paul Quinn (paulq); Ron Parker;= meng.wei2@zte.com.cn; Reinaldo Penno (repenno= ) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1E98B38DBCrepennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1054AF88B6411249B3E406D1C861A6AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, February 10, 2014 at = 2:49 PM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = Cathy Zhang <Cathy.H.Zhang@h= uawei.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>, sfc <sfc-bounces@ie= tf.org>, "Paul Quinn (paulq)" <paulq@cisco.com>, Ron Parker <Ron_Park= er@affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, Cisco Employee <repenno@cisco.com>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

I can see that from service perspec= tive, the NAT44-A and NAT44-B are different instances (or aspects) of NAT f= unction.

 

However, there could be  multi= ple =93entities=94 of NAT44-B (e.g.  one =93entity=94 only has 10G cap= ability), and many =93entities=94 of NAT44-B. Each entity has its own unique address (or Locator in draft-parker-sfc-chain-to-path).=


From network steering perspective, = any of  the =93entities=94 for NAT44-B can be used for a chain that ne= eds NAT44-B.

 

But a Service/Network forwarding no= de can=92t use NAT44-B for a chain that needs NAT44-A, so maybe the NAT44-A= and NAT44-B can be considered as different service functions? 

[RP] I would consider them the same service function but different ins= tances. IMHO if a NAT44 performs as described in RFC4787, then that belongs= to the NAT44 service function class. The configuration, rules and policies= inside a specific instance of NAT  is what makes it different. 

Now, I can see how one could consider each different NAT44 configurati= on as a different service function. But in that case you would have gazilli= ons of service functions when in fact you only need a small number. 

 

Some people (like Jim) call  t= hose =93entities=94 as  =93instances=94 because they perform the same = function but with different addresses.

 

How about we call those multiple = =93entities=94 as a =93component=94?  in the same way as the =93component=94 in ser= ver cluster http://en.wikipedia.org/wiki/Computer_cluster

 

Linda

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: sfc@ietf.org; sfc; Paul Quin= n (paulq); Ron Parker; meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_CF1E98B38DBCrepennociscocom_-- From jguichar@cisco.com Mon Feb 10 15:17:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA981A0671; Mon, 10 Feb 2014 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.448 X-Spam-Level: X-Spam-Status: No, score=-14.448 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, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDGcbeuYosAf; Mon, 10 Feb 2014 15:17:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 018F81A061A; Mon, 10 Feb 2014 15:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24366; q=dns/txt; s=iport; t=1392074267; x=1393283867; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6entYXNcvkDxwH5S7ZOFyicmEAouya5EvALohm9CxqE=; b=TcLjrLVBlImn9djydppQfLZNgRjTO7o1Is+7qAFFm2gQpyCYrnGtPn7h 4Bqv5v0y1UGqrBY4zSZ5TlgPMg4LLDe/803uytVJVPkRZfAVQA0+T7HvQ F4B+NjOL1/uwwpdxm4buFPBBfEgrQHN4wv77xsuMDh4nQ9jGqTRvVY5SA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAH1d+VKtJV2d/2dsb2JhbABZgkpEOFW8O4EYFgF0g30BAQEELUoCEAIBCBEDAQEBIQcHMhQJCAIEDgWIBMJ6F45uExEGAQKENAEDmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="300135319" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 10 Feb 2014 23:17:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1ANHSQe018370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:17:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:17:27 -0600 From: "Jim Guichard (jguichar)" To: Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzICAAGcaAIAACXsA//+e1uyAAGj5gP//zAmA Date: Mon, 10 Feb 2014 23:17:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.188] Content-Type: multipart/alternative; boundary="_000_CF1EC3E6153D1jguicharciscocom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:17:51 -0000 --_000_CF1EC3E6153D1jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Cathy, let=92s take the FW example with policy-set-a and policy-set-b. If we treat= the FW as a type of service function where policy-set-a and policy-set-b a= re instances of that =93type" of service function then my point is that eac= h of those could be located at multiple points in the network thereby givin= g you multiple =93instances=94 of the policy-set-a =93instance=94 and the p= olicy-set-b =93instance. I will argue that that is not the right way to loo= k at it.. Let me explain my logic. Let=92s take the FW example again. Suppose that I now have policy-set=92s a= ,b,c, & d. Lets further suppose that policy-set=92s a&b are available at se= rvice nodes 1, 2, 3 & 4 and policy-set=92s c&d are available at service nod= es 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy= -set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will n= ot have the necessary policy to treat the traffic even though we have said = they are of the same service function =93type". This gives us a dilemma tha= t can be tackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let=92s call th= em FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely = upon the FW itself to determine which of the policy-set=92s to apply using = some out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+p= olicy-set into its own distinct service function; FW(a), FW(b), FW(c), and = FW(d). The problem with this is that I could end up with a large number of = distinct service functions. 3. I could let the SFC service encapsulation carry enough information fo= r the FW to determine which of the policy-set=92s a,b,c,d to apply to a giv= en flow without needing to reclassify at the FW or split all of the FW+poli= cy-set combinations into separate service functions. In other words I could= simply have a service function with type =93FW=94 and indicate the policy-= set within the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1EC3E6153D1jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2A763688C631DC4680565BB7409F2823@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Cathy,

let=92s take the FW example with policy-set-a and policy-set-b. If we = treat the FW as a type of service function where policy-set-a and policy-se= t-b are instances of that =93type" of service function then my point i= s that each of those could be located at multiple points in the network thereby giving you multiple =93instances=94= of the policy-set-a =93instance=94 and the policy-set-b =93instance. I wil= l argue that that is not the right way to look at it.. Let me explain my lo= gic.

Let=92s take the FW example again. Suppose that I now have policy-set= =92s a,b,c, & d. Lets further suppose that policy-set=92s a&b are a= vailable at service nodes 1, 2, 3 & 4 and policy-set=92s c&d are av= ailable at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to servic= e nodes 5, 6 or 7 as they will not have the necessary policy to treat the t= raffic even though we have said the= y are of the same service function =93type". This gives us a dilemma t= hat can be tackled in 1 of 3 ways imho:
  1. I could split them into 2 separate service functions; let=92s call them= FW(a,b) & FW(c,d). Now the problem with this is that now I have to rel= y upon the FW itself to determine which of the policy-set=92s to apply usin= g some out-of-scope for the SFC WG mechanism. 
  2. To avoid reclas= sification as indicated in (1) I could split each FW+policy-set into it= s own distinct service function; FW(a), FW(b), FW(c), and FW(d). The proble= m with this is that I could end up with a large number of distinct service = functions.
  3. I could let the SFC service encapsulation carry enough i= nformation for the FW to determine which of the policy-set=92s a,b,c,d to a= pply to a given flow without needing to reclassif= y at the FW or split all of the FW+policy-set combinations into separat= e service functions. In other words I could simply have a service function = with type =93FW=94 and indicate the policy-set within the service encapsula= tion.

For me point (3) highlights pretty nicely one of the reasons for havin= g an SFC service encapsulation.

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Monday, February 10, 2014 at = 4:23 PM
To: Jim Guichard <jguichar@cisco.com>
Cc: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, R= on Parker <Ron_Parker= @affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, = Paul Quinn <paulq@cisco.com>, = sfc <sfc-bounces@ietf.org>= ;, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

Hi Jim,

 

Could you clarify what you mean by = an instance of a service function instance?

 

Thanks,

Cathy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_CF1EC3E6153D1jguicharciscocom_-- From jguichar@cisco.com Mon Feb 10 15:18:10 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AB51A068E; Mon, 10 Feb 2014 15:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB-mj0TJ-S3H; Mon, 10 Feb 2014 15:18:08 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC91A05F2; Mon, 10 Feb 2014 15:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12336; q=dns/txt; s=iport; t=1392074288; x=1393283888; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VCI4MZ2hR10BBPtnoSk2c+Lvg8RzR1435645ldnpl/g=; b=JZfe1du8nqrs0qF/NxvRwynEYVgeYKUJry5ApPEgEyU1NEM6hy0Hvari HN16EXzm0nwZc0OB+8lSyu9wIp1MuTrKk4xbDINYnzmqAX/klGWTZKkmC KK1qHGItr3pk1gS5vZAJsONJKtqUhzkI+VilJ0TfER7sXlZtEpA6R4HO8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAPhc+VKtJXHA/2dsb2JhbABPCoJIRIEPvlOBFxZ0giUBAQEEVCMCEAIBCBEDAQEBKAcyFAkIAgQBDQWIBclvF44hSxEGAYQ4AQOYK5Iggy2CKg X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="302954842" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 10 Feb 2014 23:18:07 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1ANI7GS022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:18:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:18:06 -0600 From: "Jim Guichard (jguichar)" To: Nicolas BOUTHORS , "Reinaldo Penno (repenno)" , Ron Parker , "meng.wei2@zte.com.cn" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzICAAGcaAIAAI/mA//+5h4A= Date: Mon, 10 Feb 2014 23:18:06 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D3E364D@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E364D@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: [10.98.43.188] Content-Type: multipart/alternative; boundary="_000_CF1EC84415403jguicharciscocom_" MIME-Version: 1.0 Cc: "Paul Quinn \(paulq\)" , "sfc@ietf.org" , sfc Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:18:10 -0000 --_000_CF1EC84415403jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree (see previous post for logic). From: Nicolas BOUTHORS > Date: Monday, February 10, 2014 at 5:30 PM To: "Reinaldo Penno (repenno)" = >, Jim Guichard >, Ron Parker= >,= "meng.wei2@zte.com.cn" > Cc: Paul Quinn >, sfc >, "sfc@ietf.org"= > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt IMHO: in draft-quinn-sfc-arch-04.txt definitions: "Service Function (SF): A function that is responsible for specific treatm= ent of received packets. " So two instances of a Service Function should apply the same policy, as the= policy is what make the treatment of received packets to be specific. A type of Service Function (eg. FW vs NAT44) is not enough to identify prec= isely a Service Function. There is a need for a descriptor for what makes it specific, and a name so = that it can be identified. Very similar to a class/object paradygm in fact, as a class describes the b= ehavior of its instances. Nicolas ________________________________ From: Reinaldo Penno (repenno) [repenno@cisco.com= ] Sent: Monday, February 10, 2014 9:21 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1EC84415403jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <831DEBB6728B50468E4A79CA36D10027@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Yes, I agree (see previous post for logic). 

From: Nicolas BOUTHORS <Nicolas.BOUTHORS@qosmos.com>=
Date: Monday, February 10, 2014 at = 5:30 PM
To: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, J= im Guichard <jguichar@cisco.com>, Ron Parker <Ro= n_Parker@affirmednetworks.com>, "meng.wei2@zte.com.cn&quo= t; <meng.wei2@zte.com.cn>=
Cc: Paul Quinn <paulq@cisco.com>, sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ie= tf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

IMHO:

in draft-quinn-sfc-arch-04.txt definitions:
"Service Function (SF)=
:  A function that is responsible for specific treatment of received packet=
s. "

So two instances of a Service Function =
should apply the same policy, as the policy
is what make the treatment of received =
packets to be specific.

A type of Service Function (eg. FW vs N=
AT44) is not enough to identify precisely a Service Function. <=
/pre>

There is a need for a descriptor for what makes it=
 specific, and a name so that it can be identified.


Very=
 similar to a class/object paradygm in fact, as a class describes the behav=
ior of its instances.








 


Nicolas


   






From: Reinaldo Penno (repenno) [repenno@cisco.com]

Sent: Monday, February 10, 2014 9:21 PM

To: Jim Guichard (jguichar); Ron Parker; 
meng.wei2@zte.com.cn

Cc: Paul Quinn (paulq); sfc; sfc@iet=
f.org

Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc=
-arch-04.txt










Based on the definition I see this differently.







The same service function could be instantiated with  policy-set-=
A and later instantiated with  policy-set-B. It is still the same serv=
ice function, but different instances. 







Therefore I would consider {1 below} one service function (say, NAT44)=
 and two different service function instances, one that applies  polic=
y-set-A and other that applies  policy-set-A.









From: "Jim Guichard (jguichar)=
" <jguichar=
@cisco.com>

Date: Monday, February 10, 2014 at =
11:12 AM

To: Ron Parker <Ron_Parker@affirmednet=
works.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn"
 <meng.wei2@zt=
e.com.cn>

Cc: "Paul Quinn (paulq)" =
<paulq@cisco.com>, "sfc@ietf.org=
" <sfc@ietf.o=
rg>,
 sfc <sfc-boun=
ces@ietf.org>

Subject: Re: [sfc] Fwd: New Version=
 Notification for draft-quinn-sfc-arch-04.txt









    

  1. A service function that applies policy-set-A and a different service fu=
nction that applies policy-set-B e.g. They are two distinct service functio=
ns.
--_000_CF1EC84415403jguicharciscocom_-- From jguichar@cisco.com Mon Feb 10 15:21:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD21A061A; Mon, 10 Feb 2014 15:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTs_uUBIN7Lp; Mon, 10 Feb 2014 15:21:32 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 29C361A0618; Mon, 10 Feb 2014 15:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18527; q=dns/txt; s=iport; t=1392074492; x=1393284092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RUfOtF5Zu/0jQxDf/fB2GtOX7uryVqSe5tr2C5Jokn4=; b=d5iCA5wOQFng1WeseDS5p7QVb8S+xL/I8HuFYFluRwAFgq4e/sEhhEr2 7ZYDdtYeRKLlm1ZCdOoo9wpMHf4DLUWDPjRz6jM34EFNY4aMNeOkAiDJq cSH6bvgobBMmmOyhaNDvKPyNRNXkbrYhYMGrio2PvfoEgJN4ZhknrTdBE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAL1e+VKtJXHA/2dsb2JhbABZgkpEOFW8O4EYFgF0g30BAQEEdwIQAgEIEQMBAQEoBzIUCQgCBAENBYgEwnQXjwERBgGENgEDmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="300135837" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 10 Feb 2014 23:21:15 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1ANLFCg025217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:21:15 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:21:14 -0600 From: "Jim Guichard (jguichar)" To: "Reinaldo Penno (repenno)" , Linda Dunbar , Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzICAAGcaAIAACXsA//+e1uyAAIEEAIAABCgA//+w44A= Date: Mon, 10 Feb 2014 23:21:14 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645C7B28A@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.188] Content-Type: multipart/alternative; boundary="_000_CF1EC8E115409jguicharciscocom_" MIME-Version: 1.0 Cc: Ron Parker , "meng.wei2@zte.com.cn" , "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:21:35 -0000 --_000_CF1EC8E115409jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Reinaldo, Now, I can see how one could consider each different NAT44 configuration as= a different service function. But in that case you would have gazillions o= f service functions when in fact you only need a small number. Jim> not if you rely upon the service encapsulation to differentiate ;-) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, February 10, 2014 3:08 PM To: Cathy Zhang Cc: sfc@ietf.org; sfc; Paul Quinn (paulq); Ron Parker;= meng.wei2@zte.com.cn; Reinaldo Penno (repenno= ) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1EC8E115409jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <77A798D98D68584682D4A60C6EC54E52@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Reinaldo,

Now, I can see how one could consider each different NAT44 configurati= on as a different service function. But in that case you would have gazilli= ons of service functions when in fact you only need a small number. 

Jim> not if you rely upon the service encapsulation to differentiat= e ;-)

 

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: sfc@ietf.org; sfc; Paul Quin= n (paulq); Ron Parker; meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_CF1EC8E115409jguicharciscocom_-- From Ron_Parker@affirmednetworks.com Mon Feb 10 15:31:09 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904681A068E; Mon, 10 Feb 2014 15:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 to6yAyDz1veV; Mon, 10 Feb 2014 15:31:06 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id D05D31A0511; Mon, 10 Feb 2014 15:31:06 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 15:31:06 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgCAABNCAIAACXsAgAADaoCAAARlgIAAH9+A//99tLg= Date: Mon, 10 Feb 2014 23:31:05 +0000 Message-ID: <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_31B7FA43FC33419CB020DD810B80CAB8affirmednetworkscom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:31:09 -0000 --_000_31B7FA43FC33419CB020DD810B80CAB8affirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Approach 3 is the most elegant, but also the most costly in terms of the se= rvice header. Rather than deriving both sequence and policy selection from= the chain id that presumably appears in the service header, we would now n= eed a stack of policy set identifiers that is pushed on by the classifier -= - one for each service function in the chain. Ron On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" > wrote: Hi Cathy, let=92s take the FW example with policy-set-a and policy-set-b. If we treat= the FW as a type of service function where policy-set-a and policy-set-b a= re instances of that =93type" of service function then my point is that eac= h of those could be located at multiple points in the network thereby givin= g you multiple =93instances=94 of the policy-set-a =93instance=94 and the p= olicy-set-b =93instance. I will argue that that is not the right way to loo= k at it.. Let me explain my logic. Let=92s take the FW example again. Suppose that I now have policy-set=92s a= ,b,c, & d. Lets further suppose that policy-set=92s a&b are available at se= rvice nodes 1, 2, 3 & 4 and policy-set=92s c&d are available at service nod= es 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy= -set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will n= ot have the necessary policy to treat the traffic even though we have said = they are of the same service function =93type". This gives us a dilemma tha= t can be tackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let=92s call th= em FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely = upon the FW itself to determine which of the policy-set=92s to apply using = some out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+p= olicy-set into its own distinct service function; FW(a), FW(b), FW(c), and = FW(d). The problem with this is that I could end up with a large number of = distinct service functions. 3. I could let the SFC service encapsulation carry enough information fo= r the FW to determine which of the policy-set=92s a,b,c,d to apply to a giv= en flow without needing to reclassify at the FW or split all of the FW+poli= cy-set combinations into separate service functions. In other words I could= simply have a service function with type =93FW=94 and indicate the policy-= set within the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_31B7FA43FC33419CB020DD810B80CAB8affirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Approach 3 is the most elegant, but also the most costly in terms of t= he service header.  Rather than deriving both sequence and policy sele= ction from the chain id that presumably appears in the service header, we w= ould now need a stack of policy set identifiers that is pushed on by the classifier -- one for each service function in th= e chain. 

   Ron


On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Hi Cathy,

let=92s take the FW example with policy-set-a and policy-set-b. If we = treat the FW as a type of service function where policy-set-a and policy-se= t-b are instances of that =93type" of service function then my point i= s that each of those could be located at multiple points in the network thereby giving you multiple =93instances=94= of the policy-set-a =93instance=94 and the policy-set-b =93instance. I wil= l argue that that is not the right way to look at it.. Let me explain my lo= gic.

Let=92s take the FW example again. Suppose that I now have policy-set= =92s a,b,c, & d. Lets further suppose that policy-set=92s a&b are a= vailable at service nodes 1, 2, 3 & 4 and policy-set=92s c&d are av= ailable at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to servic= e nodes 5, 6 or 7 as they will not have the necessary policy to treat the t= raffic even though we have said the= y are of the same service function =93type". This gives us a dilemma t= hat can be tackled in 1 of 3 ways imho:
  1. I could split them into 2 separate service functions; let=92s call them= FW(a,b) & FW(c,d). Now the problem with this is that now I have to rel= y upon the FW itself to determine which of the policy-set=92s to apply usin= g some out-of-scope for the SFC WG mechanism. 
  2. To avoid reclas= sification as indicated in (1) I could split each FW+policy-set into it= s own distinct service function; FW(a), FW(b), FW(c), and FW(d). The proble= m with this is that I could end up with a large number of distinct service = functions.
  3. I could let the SFC service encapsulation carry enough i= nformation for the FW to determine which of the policy-set=92s a,b,c,d to a= pply to a given flow without needing to reclassif= y at the FW or split all of the FW+policy-set combinations into separat= e service functions. In other words I could simply have a service function = with type =93FW=94 and indicate the policy-set within the service encapsula= tion.

For me point (3) highlights pretty nicely one of the reasons for havin= g an SFC service encapsulation.

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Monday, February 10, 2014 at = 4:23 PM
To: Jim Guichard <jguichar@cisco.com>
Cc: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, R= on Parker <Ron_Parker= @affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, = Paul Quinn <paulq@cisco.com>, = sfc <sfc-bounces@ietf.org>= ;, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

Hi Jim,

 

Could you clarify what you mean by = an instance of a service function instance?

 

Thanks,

Cathy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_31B7FA43FC33419CB020DD810B80CAB8affirmednetworkscom_-- From repenno@cisco.com Mon Feb 10 15:31:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A11A068E; Mon, 10 Feb 2014 15:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 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, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcJV57gOPhMR; Mon, 10 Feb 2014 15:31:48 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id A80C41A06C4; Mon, 10 Feb 2014 15:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27853; q=dns/txt; s=iport; t=1392075107; x=1393284707; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=R/24X8xN6fJd5kwHuzLsTfLj1qNPZ5AcpCfQWaZmHIc=; b=OKOEhjAis7R4gqQk+KtA+I8MVDdCFVUsGr9jeNki5zVjPRjVMFdJg1Md dgii/nEhTEs1Rb686McFa6a+koK1Dboz6vExZZQlYGnnDuzjaSCno//8O S98iEXhYXKoG9ZVqqjQKcWGdKDIf4/+ecgfrdfhS7SypEWVqEo2OnvXI9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAHlg+VKtJXG9/2dsb2JhbABZgkhEOFe+U4EXFnSCJQEBAQQtSgISAQgRAwEBASEHORQJCAIEAQ0FiAXJaheOWRMRBgEChDYBA5grkiCDLYIq X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208,217";a="19404856" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 10 Feb 2014 23:31:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1ANVkaG003537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:31:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:31:46 -0600 From: "Reinaldo Penno (repenno)" To: "Jim Guichard (jguichar)" , Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoJqu+juAgABFpAD//40egIAAj58AgAADaoCAAARlgIAAH9+A//9944A= Date: Mon, 10 Feb 2014 23:31:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.142] Content-Type: multipart/alternative; boundary="_000_CF1EA0CC8DE1repennociscocom_" MIME-Version: 1.0 Cc: "meng.wei2@zte.com.cn" , "sfc@ietf.org" , "Paul Quinn \(paulq\)" , sfc , Ron Parker Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:31:51 -0000 --_000_CF1EA0CC8DE1repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Inline with [RP] From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 3:17 PM To: Cathy Zhang > Cc: Cisco Employee >, Ron Parke= r >= , "meng.wei2@zte.com.cn" >, "Paul Quinn (paulq)" >, sfc = >, "sfc@ietf.org" > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Cathy, let=92s take the FW example with policy-set-a and policy-set-b. If we treat= the FW as a type of service function where policy-set-a and policy-set-b a= re instances of that =93type" of service function then my point is that eac= h of those could be located at multiple points in the network thereby givin= g you multiple =93instances=94 of the policy-set-a =93instance=94 and the p= olicy-set-b =93instance. I will argue that that is not the right way to loo= k at it.. Let me explain my logic. Let=92s take the FW example again. Suppose that I now have policy-set=92s a= ,b,c, & d. Lets further suppose that policy-set=92s a&b are available at se= rvice nodes 1, 2, 3 & 4 and policy-set=92s c&d are available at service nod= es 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy= -set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will n= ot have the necessary policy to treat the traffic even though we have said = they are of the same service function =93type". [RP] Since we are starting from different premises the results with differe= nt. We never said Service Functions with different policies have the same t= ype. All we said is that they have the capability to provide the same func= tionality, This gives us a dilemma that can be tackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let=92s call th= em FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely = upon the FW itself to determine which of the policy-set=92s to apply using = some out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+p= olicy-set into its own distinct service function; FW(a), FW(b), FW(c), and = FW(d). The problem with this is that I could end up with a large number of = distinct service functions. 3. I could let the SFC service encapsulation carry enough information fo= r the FW to determine which of the policy-set=92s a,b,c,d to apply to a giv= en flow without needing to reclassify at the FW or split all of the FW+poli= cy-set combinations into separate service functions. In other words I could= simply have a service function with type =93FW=94 and indicate the policy-= set within the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1EA0CC8DE1repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8E34712CCE60C24BAA9580A2CE0C6BFA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Inline with [RP]

From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Monday, February 10, 2014 at = 3:17 PM
To: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Cc: Cisco Employee <repenno@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com= >, "meng.wei2@zte.com.c= n" <meng.wei2@zte.com.cn>, = "Paul Quinn (paulq)" <paulq= @cisco.com>, sfc <sfc-bou= nces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

Hi Cathy,

let=92s take the FW example with policy-set-a and policy-set-b. If we = treat the FW as a type of service function where policy-set-a and policy-se= t-b are instances of that =93type" of service function then my point i= s that each of those could be located at multiple points in the network thereby giving you multiple =93instances=94= of the policy-set-a =93instance=94 and the policy-set-b =93instance. I wil= l argue that that is not the right way to look at it.. Let me explain my lo= gic.

Let=92s take the FW example again. Suppose that I now have policy-set= =92s a,b,c, & d. Lets further suppose that policy-set=92s a&b are a= vailable at service nodes 1, 2, 3 & 4 and policy-set=92s c&d are av= ailable at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot send the traffic to servic= e nodes 5, 6 or 7 as they will not have the necessary policy to treat the t= raffic even though we have said the= y are of the same service function =93type".

[RP] Since we are starting from different premises the results with di= fferent. We never said Service Functions with different policies have the s= ame type.  All we said is that they have the capability to provide the= same functionality,


This gives us a dilemma that can be tackled in 1 of 3 ways imho:
  1. I could split them into 2 separate service functions; let=92s call them= FW(a,b) & FW(c,d). Now the problem with this is that now I have to rel= y upon the FW itself to determine which of the policy-set=92s to apply usin= g some out-of-scope for the SFC WG mechanism. 
  2. To avoid reclas= sification as indicated in (1) I could split each FW+policy-set into it= s own distinct service function; FW(a), FW(b), FW(c), and FW(d). The proble= m with this is that I could end up with a large number of distinct service = functions.
  3. I could let the SFC service encapsulation carry enough i= nformation for the FW to determine which of the policy-set=92s a,b,c,d to a= pply to a given flow without needing to reclassif= y at the FW or split all of the FW+policy-set combinations into separat= e service functions. In other words I could simply have a service function = with type =93FW=94 and indicate the policy-set within the service encapsula= tion.

For me point (3) highlights pretty nicely one of the reasons for havin= g an SFC service encapsulation.

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Monday, February 10, 2014 at = 4:23 PM
To: Jim Guichard <jguichar@cisco.com>
Cc: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, R= on Parker <Ron_Parker= @affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, = Paul Quinn <paulq@cisco.com>, = sfc <sfc-bounces@ietf.org>= ;, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

Hi Jim,

 

Could you clarify what you mean by = an instance of a service function instance?

 

Thanks,

Cathy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_CF1EA0CC8DE1repennociscocom_-- From linda.dunbar@huawei.com Mon Feb 10 15:37:10 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF111A0619 for ; Mon, 10 Feb 2014 15:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Cfv9Fg7sx4Dp for ; Mon, 10 Feb 2014 15:37:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 154471A0511 for ; Mon, 10 Feb 2014 15:37:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ25763; Mon, 10 Feb 2014 23:37:07 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 23:36:11 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 23:37:04 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 15:36:52 -0800 From: Linda Dunbar To: Dave Dolson , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt Thread-Index: AQHPJOJWuIDUqtgnlkaZEJ6rdtz9jJqrfb3QgAMtfTCAAHjBMA== Date: Mon, 10 Feb 2014 23:36:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7B551@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C7A7AC@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-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, 10 Feb 2014 23:37:10 -0000 RGF2ZSwgDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBBbnN3ZXJzIGFyZSBpbnNlcnRlZCBi ZWxvdzoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhdmUgRG9sc29uIFtt YWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb21dIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwg MjAxNCAxMToxMCBBTQ0KVG86IExpbmRhIER1bmJhcjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBS RTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1s NC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDIudHh0DQoNCkxpbmRhIGV0IGFsLiwNCg0KSSBtYXkg bm90IGhhdmUgdW5kZXJzdG9vZCBldmVyeXRoaW5nIHlvdSB3ZXJlIHNheWluZywgYnV0IEkgdGhp bmsgdGhlIGZvbGxvd2luZyBwZXJzcGVjdGl2ZSBpcyB1c2VmdWwgYW5kIGNvbmNpc2U6DQoNCkxl Z2FjeSBub2RlcyBtdXN0IGJlIHdyYXBwZWQgd2l0aCBTRkYgbm9kZXMgdG8gbWFrZSB0aGVtIGxv b2sgbGlrZSBwcm9wZXIgU0Ygbm9kZXMuDQpbTGluZGFdIFllcywgZXZlbiB0aG91Z2ggImF0dGFj aGVkIHRvIFNGRiIgaXMgbW9yZSBhY2N1cmF0ZSB0aGFuICJ3cmFwcGVkIi4gDQoNCg0KDQoNCmIu IEEgY2x1c3RlciBvZiBsZWdhY3kgbm9kZXMgY2FuIGJlIHdyYXBwZWQgc3VjaCB0aGF0IHRoZSBj bHVzdGVyIGlzIGV4cG9zZWQgYXMgYSBzaW5nbGUgU0YgaW5zdGFuY2UuIFRoZW4gdGhlIENsYXNz aWZpZXIgY2hvb3NlcyB0aGUgY2x1c3RlciBidXQgaXMgYWdub3N0aWMgYWJvdXQgdGhlIHBhdGgg b2YgdHJhZmZpYyB3aXRoaW4gdGhlIGNsdXN0ZXIuIA0KDQpbTGluZGFdIEkgZG9uJ3QgdGhpbmsg aXQgd2lsbCBzY2FsZSBmb3IgQ2xhc3NpZmllciB0byBjaG9vc2UgdGhlIHdob2xlIGNsdXN0ZXIg d2l0aCBtdWx0aXBsZSBTZXJ2aWNlIGZ1bmN0aW9ucy4gWW91IGNhbiBoYXZlIHR3byBjaGFpbnMg Z29pbmcgdGhyb3VnaCBvbmUgU0ZGIHRvIHdoaWNoIDMgU2VydmljZSBGdW5jdGlvbnMgYXJlIGF0 dGFjaGVkIChTRiMxLCBTRiMyLCBTRiMzKS4gIENoYWluICMxIG9ubHkgbmVlZHMgdG8gZ28gdGhy b3VnaCBTRiAjMSwgQ2hhaW4gIzIgbmVlZHMgdG8gZ28gdGhyb3VnaCBTRiMxICYgU0YjMi4gDQoN Cg0KDQooVGhpcyBpcyB3aGVyZSB0aGUgY2hhbGxlbmdlcyBhcHBlYXIsIGJ1dCBhbHNvIHByb3Zp ZGUgZ3JlYXQgZmxleGliaWxpdHk7IHVzZSBWTEFOcyBvciBNUExTIG9yIHByb3ByaWV0YXJ5IHRh Z2dpbmcgdG8gc2VwYXJhdGUgdGhlIGNoYWlucy4pIE1vcmUgZ2VuZXJhbGx5LCBhIGNsdXN0ZXIg Y291bGQgZXhwb3NlIG11bHRpcGxlIFNGIGluc3RhbmNlcyBmb3IgZGlmZmVyZW50IHBvbGljaWVz Lg0KDQpbTGluZGFdIEFncmVlIGhlcmUuIFRoYXQgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBv ZiB0aGUgZHJhZnQuIA0KDQoNCg0KSXQgbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gc2F5IGFueXRo aW5nIG1vcmUuIFByb3ZpZGVkIHRoZSBsZWdhY3kgbm9kZXMgYXJlIHdyYXBwZWQgdG8gbG9vayBs aWtlIHByb3BlciBTRkMgbm9kZXMgKG5hbWVseSwgcHJvcGVybHkgZm9yd2FyZGluZyBwYWNrZXRz KSwgd2h5IHNob3VsZCB0aGUgU0ZDIHN0YW5kYXJkIHNheSBhbnl0aGluZyBhYm91dCB3aGF0IGhh cHBlbnMgYmVuZWF0aCB0aGUgd3JhcHBpbmc/DQoNCltMaW5kYV0gSSBkb24ndCB0aGluayBpdCBp cyB0aGF0IHNpbXBsZS4gd2hlbiBTRkYgaXMgb24gYSBzZXBhcmF0ZSBib3gsIHRoZSBTRkMtQXJj aGl0ZWN0dXJlIG5lZWQgdG8gIGFkZHJlc3M6IA0KLSBWYXJpb3VzIFNGIGNvbm5lY3Rpb24gdG8g U0ZGIE5vZGVzDQotIFRyYWZmaWMgU3RlZXJpbmcgYXQgU0ZGIE5vZGVzIA0KCWUuZy4gSG93IHN0 ZWVyaW5nIHBvbGljeSBpcyBwYXNzZWQgdG8gYSBTRkYgbm9kZSwgYW5kIHRoZSBuZWVkIGZvciBT RkYgdG8gcmUtY2xhc3NpZnkgdHJhZmZpYyBjb21pbmcgYmFjayBmcm9tIGEgcG9ydCBjb25uZWN0 ZWQgdG8gYSBTRiBpZiB0aGUgQ2hhaW4gSUQgaXMgbm90IHBhc3NlZCBieSB0aGUgU0Ygbm9kZXMu DQoNClRob3NlIGFyZSBkZXNjcmliZWQgaW4gdGhlIFNlY3Rpb24gNCBvZiB0aGUgZHJhZnQuIA0K DQoNCg0KDQpPbiBhIHNvbWV3aGF0IHJlbGF0ZWQgbm90ZSwgSSB0aGluayBpdCBpcyBhbHNvIHJl YXNvbmFibGUgdGhhdCBTRkMgY291bGQgYmUgZGVwbG95ZWQgaGllcmFyY2hpY2FsbHkuIEkuZS4s IGEgbG9hZC1iYWxhbmNlciBjb3VsZCBhcHBlYXIgYXMgYSBzaW5nbGUgU0Ygbm9kZSB3aXRoaW4g YSBzZXJ2aWNlIGNoYWluLCBhbmQgdXRpbGl6ZSBTRkMgdG8gZGlzdHJpYnV0ZSB0cmFmZmljIHdp dGhpbiBpdHMgY2x1c3RlciwgaW4gYSBkaWZmZXJlbnQgU0ZDIGRvbWFpbi4gV2hlbiB0aGUgaW5u ZXIgY2hhaW4gZW5kcywgdGhlIHBhY2tldCByZXR1cm5zIHRvIHRoZSBvcmlnaW5hbCBTRiBDaGFp bi4gDQoNCkhpZXJhcmNoaWVzIGFyZSBhcmNoaXRlY3R1cmFsbHkgcG93ZXJmdWwsIGFsbG93aW5n IHNpbXBsaWZpY2F0aW9uIGJ5IGFic3RyYWN0aW9uLiBUaGlzIHZpZXcgYWxsb3dzIGEgdmVuZG9y IHRvIHByb3ZpZGUgYSBzb2x1dGlvbiBhcHBlYXJpbmcgYXMgYSBzaW5nbGUgU0ZDIG5vZGUsIGJ1 dCBpbnRlcm5hbGx5IHV0aWxpemluZyBtdWx0aXBsZSBjb21wb25lbnRzIHdpdGggU0ZDIHRlY2hu b2xvZ3kuDQoNCltMaW5kYV0gQWdyZWUuIFRoYXQgaXMgZGVzY3JpYmVkIGluIHRoZSBTZWN0aW9u IDUgb2YgdGhlIGRyYWZ0LiBZb3UgY2FuIGFsc28gaGF2ZSBsb2NhbCBsb2FkIGJhbGFuY2VyIGFu ZCBnbG9iYWwgbG9hZCBiYWxhbmNlciAodG8gYWRkcmVzcyBzYW1lIGZ1bmN0aW9uIGJ1dCBtdWx0 aXBsZSBlbnRpdGllcyBhdHRhY2hlZCB0byBkaWZmZXJlbnQgU0ZGIG5vZGVzKS4gDQoNCg0KDQoN CkRhdmlkIERvbHNvbg0KU2VuaW9yIFNvZnR3YXJlIEFyY2hpdGVjdCwgU2FuZHZpbmUgSW5jLg0K DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaW5kYSBEdW5iYXINClNlbnQ6IFNhdHVy ZGF5LCBGZWJydWFyeSAwOCwgMjAxNCAxMDo0OCBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogW3NmY10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNm Yy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAyLnR4dA0KDQpUaGlzIGRyYWZ0IGFu YWx5emVzIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGNoYWluaW5nIGV4aXN0aW5nIExheWVy IDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSBub3QgYXdhcmUgb2Ygc2VydmljZSBlbmNh cHN1bGF0aW9uIGxheWVycy4gVGhpcyBkcmFmdCBhbHNvIGV4YW1pbmVzIHRoZSBuZXR3b3JrIGFy Y2hpdGVjdHVyZSBmb3IgY2hhaW5pbmcgZXhpc3RpbmcgTDQtTDcgc2VydmljZSBmdW5jdGlvbnMu IFRoZSBnb2FsIG9mIHRoZSBkcmFmdCBpczoNCg0KDQotIFRvIG1ha2UgU0ZDIFdHIGFkb3B0IHRo ZSBmYWN0IHRoYXQgdGhlcmUgYXJlIG1hbnkgc2VydmljZSBmdW5jdGlvbnMgZGVwbG95ZWQgdGhh dCBkb27igJl0IHRlcm1pbmF0ZSB0aGUgbmV3bHkgcHJvcG9zZWQgU0ZDIEhlYWRlcjsgTWFueSBv ZiB0aGVtIGRvbuKAmXQgaGF2ZSBMMi9MMyBzd2l0Y2hpbmcvcm91dGluZyBjYXBhYmlsaXR5DQoN Ci0gVG8gbWFrZSBTRkMgV0cgYWRvcHQgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciAo dGhhdCBpcyBkZWZpbmVkIGJ5IGRyYWZ0LXF1aW5uLW5zYy1hcmNoLTA0KSBjYW4gYmUgYSBzZXBh cmF0ZSBlbnRpdHkgZnJvbSBzZXJ2aWNlIGZ1bmN0aW9ucy4gDQoNCi0gVG8gbWFrZSBTRkMgV0cg YWRvcHQgdGhhdCBpdCBpcyBub3QgbmVjZXNzYXJ5IGZvciBldmVyeSBwYWNrZXQgdG8gY2Fycnkg dGhlIGNvbXBsZXRlIHNlcnZpY2UgY2hhaW4gZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpbiBpdHMg U0ZDIGhlYWRlci4gwqBJdCBzaG91bGQgYmUgYWNjZXB0YWJsZSB0byBoYXZlIHZhcmlhYmxlIGxl bmd0aCBTRkMgSGVhZGVyLiBGb3IgZXhhbXBsZSwgZm9yIHBhY2tldHMgdG8gYmUgZW5jb2RlZCB3 aXRoIGEgQ2hhaW4gSUQgcGx1cyBvcHRpb25hbCBhdHRyaWJ1dGVzIGFuZCBoYXZlIHNlcGFyYXRl IG1lc3NhZ2VzIChlaXRoZXIgaW4tYmFuZCBvciBvdXQtb2YtYmFuZCkgdG8gaW5mb3JtIHRoZSBk ZXRhaWxlZCBmb3J3YXJkaW5nIHBvbGljaWVzIGZvciB0aGUgQ2hhaW4gSUQgYW5kIHRoZSBDaGFp biBhdHRyaWJ1dGVzIGluIHRoZSBwYWNrZXRzIMKgdG8gdGhlIFNlcnZpY2UgRnVuY3Rpb24gRm9y d2FyZGluZyBub2Rlcy4gDQoNCi0gUmVjb2duaXplIHRoYXQgZnJvbSB1c2Vy4oCZcyBwZXJzcGVj dGl2ZSwgdGhlIG9yZGVyIG9mIHNlcnZpY2UgZnVuY3Rpb25zLCBlLmcuIENoYWluIzEge3MxLCBz NCwgczZ9LCBDaGFpbiMye3M0LCBzN30sIGlzIGltcG9ydGFudCwgYnV0IHZlcnkgb2Z0ZW4gd2hp Y2ggaW5zdGFuY2Ugb2YgdGhlIFNlcnZpY2UgRnVuY3Rpb24g4oCcczHigJ0gaXMgc2VsZWN0ZWQg Zm9yIHRoZSBDaGFpbiAjMSBpcyBub3QuICANCglBbW9uZyBtdWx0aXBsZSBpbnN0YW5jZXMgb2Yg b25lIHNlcnZpY2UgZnVuY3Rpb24sIHNvbWUgY291bGQgYmUgaW4gY2xvc2UgcHJveGltaXR5IHdo aWxlIG90aGVycyBhcmUgZmFyIGFwYXJ0IGJlaW5nIGNvbm5lY3RlZCBieSBkaWZmZXJlbnQgbmV0 d29yayBub2Rlcy4NCglJdCBzaG91bGQgYmUgYWNjZXB0YWJsZSBmb3IgU2VydmljZSBDaGFpbiBj bGFzc2lmaWVyIG9ubHkgaWRlbnRpZnkgdGhlIGNoYWluaW5nIGF0IGZ1bmN0aW9uIGxldmVsIGFu ZCBoYXZlIGFub3RoZXIgZW50aXR5IG1hbmFnaW5nIHRoZSBkZXRhaWxlZCBzZXJ2aWNlIGluc3Rh bmNlIHBhdGguDQoNCg0KWW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkg YXBwcmVjaWF0ZWQuIA0KDQpUaGFua3MsIExpbmRhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDA4LCAyMDE0IDk6MjggQU0N ClRvOiBMaW5kYSBEdW5iYXI7IFJvbiBQYXJrZXI7IE5pbmcgU287IFJvbiBQYXJrZXI7IFNvIE5p bmc7IERvbmFsZCBFYXN0bGFrZTsgTGluZGEgRHVuYmFyOyBEb25hbGQgRS4gRWFzdGxha2UgM3Jk DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMt bGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJl LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBEdW5iYXIg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZHVuYmFy LXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlDQpSZXZpc2lvbjoJMDINClRpdGxl OgkJQXJjaGl0ZWN0dXJlIGZvciBDaGFpbmluZyBMZWdhY3kgTGF5ZXIgNC03IFNlcnZpY2UgRnVu Y3Rpb25zDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTA3DQpHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6CQkxNQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hp dGVjdHVyZS0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUv DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFy LXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAyDQpEaWZmOiAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3kt bDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBh bmFseXplcyB0aGUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyBleGlzdGluZw0KICAg TGF5ZXIgNC03IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgYXJlIG5vdCBhd2FyZSBvZiBzZXJ2aWNl DQogICBlbmNhcHN1bGF0aW9uIGxheWVycy4gVGhpcyBkcmFmdCBhbHNvIGV4YW1pbmVzIHRoZSBu ZXR3b3JrDQogICBhcmNoaXRlY3R1cmUgZm9yIGNoYWluaW5nIGV4aXN0aW5nIEw0LUw3IHNlcnZp Y2UgZnVuY3Rpb25zLiBUaGUNCiAgIGludGVudCBpcyB0byBpZGVudGlmeSBvcHRpbWFsIGFyY2hp dGVjdHVyZSBmb3IgZmxleGlibHkgY2hhaW5pbmcNCiAgIGV4aXN0aW5nIExheWVyIDQtNyBmdW5j dGlvbnMgdG8gbWVldCB2YXJpb3VzIHNlcnZpY2UgbmVlZHMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From repenno@cisco.com Mon Feb 10 15:54:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5EC1A0704; Mon, 10 Feb 2014 15:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdpRXsN0pPoL; Mon, 10 Feb 2014 15:53:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D40681A0700; Mon, 10 Feb 2014 15:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21866; q=dns/txt; s=iport; t=1392076439; x=1393286039; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=e/qI0msa3eOKGNEEXezQ8D99vOFG8ajTYf/WGz42jDU=; b=GraFPPHfKQ+9o1l9YcdkJCnQ9nqCH39pciupsm3SbCqUvCBgJOBN522d QA3hEMNK0Ohk79ulRNV1g2g83b7+3wLqNURmCD4PGuJqA0lEhfYcZ2VYG D2Wg1G+6dKft+hJdYiPr6QjseaKnS1B3nenc+07uJR71oGPZGD/Jvez7X 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFVm+VKtJXG8/2dsb2JhbABZgkhEOFe+U4EYFnSCJQEBAQR3AhIBCBEDAQEBIQc5FAkIAgQBDQWIBcl3F45sEQYBhDgBA5grkiCDLYIq X-IronPort-AV: E=Sophos;i="4.95,821,1384300800"; d="scan'208,217";a="302960089" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 10 Feb 2014 23:53:52 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ANrqi1015044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 23:53:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 17:53:52 -0600 From: "Reinaldo Penno (repenno)" To: "Jim Guichard (jguichar)" , Linda Dunbar , Cathy Zhang Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmhz8fSBhbHt4UuOqqBmnNsJoJqu+juAgABFpAD//40egIAAj58AgAADaoCAABxwAP//fgqAgACK2QD//4L+gA== Date: Mon, 10 Feb 2014 23:53:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.142] Content-Type: multipart/alternative; boundary="_000_CF1E9FB68DD7repennociscocom_" MIME-Version: 1.0 Cc: Ron Parker , "meng.wei2@zte.com.cn" , "Paul Quinn \(paulq\)" , sfc , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:54:03 -0000 --_000_CF1E9FB68DD7repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You now have to manage a set of (service function + policy-set) tags in the= data plane. I call (service function + policy tag) =3D =93service instanc= e=94. This allows me to still have a small number of service functions sinc= e those are decouple from the policy. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 3:21 PM To: Cisco Employee >, Linda Dun= bar >, Cathy Zhang = > Cc: "sfc@ietf.org" >= , sfc >, "Paul Quinn (pau= lq)" >, Ron Parker >, "meng.wei2@zte.c= om.cn" > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Reinaldo, Now, I can see how one could consider each different NAT44 configuration as= a different service function. But in that case you would have gazillions o= f service functions when in fact you only need a small number. Jim> not if you rely upon the service encapsulation to differentiate ;-) From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, February 10, 2014 3:08 PM To: Cathy Zhang Cc: sfc@ietf.org; sfc; Paul Quinn (paulq); Ron Parker;= meng.wei2@zte.com.cn; Reinaldo Penno (repenno= ) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_CF1E9FB68DD7repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4C7469C3A7BAB145BCCBB4D4E6522DFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
You now have to manage a set of (service function + policy-set) ta= gs in the data plane.  I call (service function + policy tag) =3D = =93service instance=94. This allows me to still have a small number of serv= ice functions since those are decouple from the policy. 


From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
Date: Monday, February 10, 2014 at = 3:21 PM
To: Cisco Employee <repenno@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, Cathy= Zhang <Cathy.H.Zhang@huawei= .com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>, sfc <sfc-bounces@ie= tf.org>, "Paul Quinn (paulq)" <paulq@cisco.com>, Ron Parker <Ron_Park= er@affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Subject: Re: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

Hi Reinaldo,

Now, I can see how one could consider each different NAT44 configurati= on as a different service function. But in that case you would have gazilli= ons of service functions when in fact you only need a small number. 

Jim> not if you rely upon the service encapsulation to differentiat= e ;-)

 

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, February 10, 2014 3:08 PM
To: Cathy Zhang
Cc: sfc@ietf.org; sfc; Paul Quin= n (paulq); Ron Parker; meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

How would you represent an instance of a service fun= ction instance? Seems more logical to represent a service function type tha= t provides function based on policy set as an independent service function.=

Sent from my iPhone


On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

I share the same view as Reinaldo.

I think each Service Function is as= sociated with a type, such as FW Service Function or NAT Service Function

while each Service Instance is an i= nstantiation of a Service Function on a Service Node and is  associate= d with a specific policy profile/set of that type of Service Function.

In a SFC admin domain, there could = be multiple Service Nodes (physical/virtual) that support a specific Servic= e Function, such as FW,

and a service instance could be ins= tantiated on any one of the Service Nodes (as to which Service Node to inst= antiate the service instance,

it depends on load status of the Se= rvice Nodes, network proximity etc., which is out of scope) . 

Multiple flow chains can be associa= ted with the same Service Instance on a Service Node, which means these flo= ws will be applied the same policy set

for that specific type of service f= unction, as shown in the following diagram.

 

BTW, I would like to suggest that t= he draft adds a definition for =93Service Instance=94 to bring everyone on = the same page as to its semantics.

 

Thanks,

Cathy

<image002.png>

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Based on the definition I see this different= ly.

 

The same service function could be instantia= ted with  policy-set-A and later instantiated with  policy-set-B.= It is still the same service function, but different instances. 

 

Therefore I would consider {1 below} one ser= vice function (say, NAT44) and two different service function instances, on= e that applies  policy-set-A and other that applies  policy-set-A.

 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

  1. A serv= ice function that applies policy-set-A and a different service function tha= t applies policy-set-B e.g. They are two distinct service functions.=
--_000_CF1E9FB68DD7repennociscocom_-- From Chuong.D.Pham@team.telstra.com Mon Feb 10 16:01:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020341A06E2; Mon, 10 Feb 2014 16:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5V9omdPlWoo; Mon, 10 Feb 2014 16:00:57 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACD81A066E; Mon, 10 Feb 2014 16:00:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,821,1384261200"; d="scan'208,217";a="172149745" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 11 Feb 2014 11:00:54 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="147659563" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 11 Feb 2014 11:00:54 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 11 Feb 2014 11:00:54 +1100 From: "Pham, Chuong D" To: Ron Parker , "Jim Guichard (jguichar)" Date: Tue, 11 Feb 2014 10:58:24 +1100 Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: Ac8muDJfMcXEVooeTyivZDjvEjt3dAAASoLQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com> In-Reply-To: <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: multipart/alternative; boundary="_000_5602569641FB314FB4D9AD5659D41B9C2983B7C8C0WSMSG3154Vsrv_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:01:03 -0000 --_000_5602569641FB314FB4D9AD5659D41B9C2983B7C8C0WSMSG3154Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is a policy set? Is it a virtual/logical firewall? Or is it what polic= ies to apply to a traffic flow? In any case, in approach 3, the classifier would need to know which FW owns= which policy sets anyway unless the idea is having only one FW SF with all= the policy sets in it. If the classifier needs to know the individual FW S= Fs, I think approach 1 and 2 in combination is more practical. Effectively, there will be FW SF1, SF2...SFn in a network, depends on the n= eed of that network. A FW SF may host multiple policy sets. It's the local = choice and in this case, the FW will need to decide which policy set to use= , just like the way it does today. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 10:31 AM To: Jim Guichard (jguichar) Cc: sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.c= n; Reinaldo Penno (repenno) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Approach 3 is the most elegant, but also the most costly in terms of the se= rvice header. Rather than deriving both sequence and policy selection from= the chain id that presumably appears in the service header, we would now n= eed a stack of policy set identifiers that is pushed on by the classifier -= - one for each service function in the chain. Ron On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" > wrote: Hi Cathy, let's take the FW example with policy-set-a and policy-set-b. If we treat t= he FW as a type of service function where policy-set-a and policy-set-b are= instances of that "type" of service function then my point is that each of= those could be located at multiple points in the network thereby giving yo= u multiple "instances" of the policy-set-a "instance" and the policy-set-b = "instance. I will argue that that is not the right way to look at it.. Let = me explain my logic. Let's take the FW example again. Suppose that I now have policy-set's a,b,c= , & d. Lets further suppose that policy-set's a&b are available at service = nodes 1, 2, 3 & 4 and policy-set's c&d are available at service nodes 5, 6 = & 7. Given this, when I instantiate an SFC that requires say policy-set-a, = I cannot send the traffic to service nodes 5, 6 or 7 as they will not have = the necessary policy to treat the traffic even though we have said they are= of the same service function "type". This gives us a dilemma that can be t= ackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let's call them = FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely upo= n the FW itself to determine which of the policy-set's to apply using some = out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+po= licy-set into its own distinct service function; FW(a), FW(b), FW(c), and F= W(d). The problem with this is that I could end up with a large number of d= istinct service functions. 3. I could let the SFC service encapsulation carry enough information for= the FW to determine which of the policy-set's a,b,c,d to apply to a given = flow without needing to reclassify at the FW or split all of the FW+policy-= set combinations into separate service functions. In other words I could si= mply have a service function with type "FW" and indicate the policy-set wit= hin the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for "Service = Instance" to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service f= unction that applies policy-set-B e.g. They are two distinct service functi= ons. --_000_5602569641FB314FB4D9AD5659D41B9C2983B7C8C0WSMSG3154Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is a= policy set? Is it a virtual/logical firewall? Or is it what policies to ap= ply to a traffic flow?

 

In any case, in approa= ch 3, the classifier would need to know which FW owns which policy sets any= way unless the idea is having only one FW SF with all the policy sets in it= . If the classifier needs to know the individual FW SFs, I think approach 1= and 2 in combination is more practical.

 

Effe= ctively, there will be FW SF1, SF2…SFn in a network, depends on the n= eed of that network. A FW SF may host multiple policy sets. It’s the = local choice and in this case, the FW will need to decide which policy set = to use, just like the way it does today.

 

Reg= ards,

Chuong

 

 

From: Ron Parker [mailto:Ron_Parker@affirmedne= tworks.com]
Sent: Tuesday, 11 February 2014 10:31 AM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org; Cathy Zhang; sfc; Pa= ul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo Penno (repenno)
Subj= ect: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt

 

Approach 3 is the most elegant, but also th= e most costly in terms of the service header.  Rather than deriving bo= th sequence and policy selection from the chain id that presumably appears = in the service header, we would now need a stack of policy set identifiers = that is pushed on by the classifier -- one for each service function in the= chain. 

 

   Ron

=

 


On Feb 10, 2014, at 6:17 PM, "J= im Guichard (jguichar)" <jgui= char@cisco.com> wrote:

Hi Cathy,<= o:p>

 

let’s take the FW example with policy-set-a a= nd policy-set-b. If we treat the FW as a type of service function where pol= icy-set-a and policy-set-b are instances of that “type" of servi= ce function then my point is that each of those could be located at multipl= e points in the network thereby giving you multiple “instances”= of the policy-set-a “instance” and the policy-set-b “ins= tance. I will argue that that is not the right way to look at it.. Let me e= xplain my logic.

 <= /o:p>

Let’s take the FW example ag= ain. Suppose that I now have policy-set’s a,b,c, & d. Lets furthe= r suppose that policy-set’s a&b are available at service nodes 1,= 2, 3 & 4 and policy-set’s c&d are available at service nodes= 5, 6 & 7. Given this, when I instantiate an SFC that requires say poli= cy-set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will= not have the necessary policy to treat the traffic even though = ;we have said they are of the same service function “type". This= gives us a dilemma that can be tackled in 1 of 3 ways imho:

=
  1. I could split = them into 2 separate service functions; let’s call them FW(a,b) &= FW(c,d). Now the problem with this is that now I have to rely upon the FW = itself to determine which of the policy-set’s to apply using some out= -of-scope for the SFC WG mechanism. 
  2. To avoid reclassification as indicated in (1) I could split e= ach FW+policy-set into its own distinct service function; FW(a), FW(b), FW(= c), and FW(d). The problem with this is that I could end up with a large nu= mber of distinct service functions.
  3. I could let the SFC service encapsulation carry enough information = for the FW to determine which of the policy-set’s a,b,c,d to apply to= a given flow without needing to reclassify at the FW or=  split all of the FW+policy-set combinations into separate service fun= ctions. In other words I could simply have a service function with type = 220;FW” and indicate the policy-set within the service encapsulation.=

 

<= div>

For me point (3) highlights pretty nicely one of t= he reasons for having an SFC service encapsulation.

 

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Monday= , February 10, 2014 at 4:23 PM
To: Jim Guichard <jguichar@cisco.com>
Cc: "Rei= naldo Penno (repenno)" <repenn= o@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, Paul Quinn <paulq@cisco.com>, sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version Noti= fication for draft-quinn-sfc-arch-04.txt

 

Hi Jim,

 =

Could you cl= arify what you mean by an instance of a service function instance?

 

Thanks,

Cathy

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monda= y, February 10, 2014 1:08 PM
To: Cathy Zhang
Cc: Reinal= do Penno (repenno); Ron Parker; men= g.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notific= ation for draft-quinn-sfc-arch-04.txt<= /span>

 

How would you r= epresent an instance of a service function instance? Seems more logical to = represent a service function type that provides function based on policy se= t as an independent service function.

Sent from my iPhone=

<= span lang=3DEN-US>
On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" = <Cathy.H.Zhang@huawei.com> wrote:

I sh= are the same view as Reinaldo. =

I think each Service Function = is associated with a type, such as FW Service Function or NAT Service Funct= ion

while each Service Instance is an instantiation of a Serv= ice Function on a Service Node and is  associated with a specific poli= cy profile/set of that type of Service Function. =

In a SFC adm= in domain, there could be multiple Service Nodes (physical/virtual) that su= pport a specific Service Function, such as FW,

and a service = instance could be instantiated on any one of the Service Nodes (as to which= Service Node to instantiate the service instance,

it depends= on load status of the Service Nodes, network proximity etc., which is out = of scope) . 

Multiple flow chains can be associated wit= h the same Service Instance on a Service Node, which means these flows will= be applied the same policy set

for that specific type of ser= vice function, as shown in the following diagram.=

 

BTW, I would like to suggest that the draft adds a definition for= “Service Instance” to bring everyone on the same page as to it= s semantics.

 

Thanks,

Cathy

<image002.png>

 

From:= sfc [mailto:sfc-bo= unces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent= : Monday, February 10, 2014 12:22 PM
To: Jim Guichard (jguich= ar); Ron Parker; meng.wei2@zte.com.= cn
Cc: Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notificat= ion for draft-quinn-sfc-arch-04.txt

 

Based on the defin= ition I see this differently.

 

The same service function could be instantiated with  policy-s= et-A and later instantiated with  policy-set-B. It is still the same s= ervice function, but different instances. 

 = ;

Therefore I would consider {1 below} one service fu= nction (say, NAT44) and two different service function instances, one that = applies  policy-set-A and other that applies  policy-set-A.

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Date: Monday, February= 10, 2014 at 11:12 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco E= mployee <repenno@cisco.com>,= "meng.wei2@zte.com.cn&quo= t; <meng.wei2@zte.com.cn>=
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sf= c@ietf.org" <sfc@ietf.org&g= t;, sfc <sfc-bounces@ietf.org>
Subject: Re: [sfc] Fwd: New Version Notification for draft-= quinn-sfc-arch-04.txt

=

 

  1. A service function that applies policy-set-A and= a different service function that applies policy-set-B e.g. They are two d= istinct service functions.
    2. =
= --_000_5602569641FB314FB4D9AD5659D41B9C2983B7C8C0WSMSG3154Vsrv_-- From Ron_Parker@affirmednetworks.com Mon Feb 10 17:05:42 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328C61A0722; Mon, 10 Feb 2014 17:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 81DxpfiSD4x7; Mon, 10 Feb 2014 17:05:39 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 526981A0633; Mon, 10 Feb 2014 17:05:38 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 17:05:36 -0800 From: Ron Parker To: "Pham, Chuong D" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgCAABNCAIAACXsAgAADaoCAAARlgIAAH9+A//99tLiAAI29AP//jKyQ Date: Tue, 11 Feb 2014 01:05:36 +0000 Message-ID: <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com> References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2A715232CE764378A25079D620AA4DE8affirmednetworkscom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 01:05:42 -0000 --_000_2A715232CE764378A25079D620AA4DE8affirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Chuong A policy set is simply the configuration. What it means is service functio= n specific. For example, with NAT44, perhaps when some set of clients acc= ess some particular remote subnet, they should be NAT'd with a special pool= of IP addresses, otherwise the generic pool of IP addresses. But for som= e other set of clients, always use the generic pool. This would be 2 poli= cy sets (I'm open to better names for this). Per our previous thread, you could chose to call this NAT44-A and NAT44-B a= nd create the classifier policy rules such that the correct flows engage th= e correct chains and therefore the correct NAT functionality. It may even = be that both logical NAT instances are located with the same transport addr= ess. Or, you could 1/2 the number of distinct chains by requiring that the NAT44= decide on its own, without an assist from the classifier, when to use the = special pool. I believe that both use cases are entirely valid and both should be support= ed. Ron On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" > wrote: What is a policy set? Is it a virtual/logical firewall? Or is it what polic= ies to apply to a traffic flow? In any case, in approach 3, the classifier would need to know which FW owns= which policy sets anyway unless the idea is having only one FW SF with all= the policy sets in it. If the classifier needs to know the individual FW S= Fs, I think approach 1 and 2 in combination is more practical. Effectively, there will be FW SF1, SF2=85SFn in a network, depends on the n= eed of that network. A FW SF may host multiple policy sets. It=92s the loca= l choice and in this case, the FW will need to decide which policy set to u= se, just like the way it does today. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 10:31 AM To: Jim Guichard (jguichar) Cc: sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq)= ; meng.wei2@zte.com.cn; Reinaldo Penno (repenn= o) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Approach 3 is the most elegant, but also the most costly in terms of the se= rvice header. Rather than deriving both sequence and policy selection from= the chain id that presumably appears in the service header, we would now n= eed a stack of policy set identifiers that is pushed on by the classifier -= - one for each service function in the chain. Ron On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" > wrote: Hi Cathy, let=92s take the FW example with policy-set-a and policy-set-b. If we treat= the FW as a type of service function where policy-set-a and policy-set-b a= re instances of that =93type" of service function then my point is that eac= h of those could be located at multiple points in the network thereby givin= g you multiple =93instances=94 of the policy-set-a =93instance=94 and the p= olicy-set-b =93instance. I will argue that that is not the right way to loo= k at it.. Let me explain my logic. Let=92s take the FW example again. Suppose that I now have policy-set=92s a= ,b,c, & d. Lets further suppose that policy-set=92s a&b are available at se= rvice nodes 1, 2, 3 & 4 and policy-set=92s c&d are available at service nod= es 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy= -set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will n= ot have the necessary policy to treat the traffic even though we have said = they are of the same service function =93type". This gives us a dilemma tha= t can be tackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let=92s call th= em FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely = upon the FW itself to determine which of the policy-set=92s to apply using = some out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+p= olicy-set into its own distinct service function; FW(a), FW(b), FW(c), and = FW(d). The problem with this is that I could end up with a large number of = distinct service functions. 3. I could let the SFC service encapsulation carry enough information fo= r the FW to determine which of the policy-set=92s a,b,c,d to apply to a giv= en flow without needing to reclassify at the FW or split all of the FW+poli= cy-set combinations into separate service functions. In other words I could= simply have a service function with type =93FW=94 and indicate the policy-= set within the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. --_000_2A715232CE764378A25079D620AA4DE8affirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Chuong

A policy set is simply the configuration.  What it means is servi= ce function specific.   For example, with NAT44, perhaps when some set= of clients access some particular remote subnet, they should be NAT'd with= a special pool of IP addresses, otherwise the generic pool of IP addresses.   But for some other set of clients= , always use the generic pool.   This would be 2 policy sets (I'm open= to better names for this).   

Per our previous thread, you could chose to call this NAT44-A and NAT4= 4-B and create the classifier policy rules such that the correct flows enga= ge the correct chains and therefore the correct NAT functionality.  It= may even be that both logical NAT instances are located with the same transport address. 

Or, you could 1/2 the number of distinct chains by requiring that the = NAT44 decide on its own, without an assist from the classifier, when to use= the special pool.  

I believe that both use cases are entirely valid and both should be su= pported.  

  Ron

What is a policy set? Is = it a virtual/logical firewall? Or is it what policies to apply to a traffic= flow?

 <= /p>

In any case, in approach = 3, the classifier would need to know which FW owns which policy sets anyway= unless the idea is having only one FW SF with all the policy sets in it. If the classifier needs to know the individual FW SFs, I think= approach 1 and 2 in combination is more practical.

 <= /p>

Effectively, there will b= e FW SF1, SF2=85SFn in a network, depends on the need of that network. A FW= SF may host multiple policy sets. It=92s the local choice and in this case, the FW will need to decide which policy set to use, just lik= e the way it does today.

 <= /p>

Regards,

Chuong<= /p>

 <= /p>

 <= /p>

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, 11 February 2014 10:31 AM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org; Cathy Zhang; s= fc; Paul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Approach 3 is the most elegant, but also the most co= stly in terms of the service header.  Rather than deriving both sequen= ce and policy selection from the chain id that presumably appears in the se= rvice header, we would now need a stack of policy set identifiers that is pushed on by the classifier -- one for e= ach service function in the chain. 

 

   Ron

 


On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Hi Cathy,

 

let=92s take the FW example with policy-set-a and po= licy-set-b. If we treat the FW as a type of service function where policy-s= et-a and policy-set-b are instances of that =93type" of service functi= on then my point is that each of those could be located at multiple points in the network thereby giving you multiple = =93instances=94 of the policy-set-a =93instance=94 and the policy-set-b =93= instance. I will argue that that is not the right way to look at it.. Let m= e explain my logic.

 

Let=92s take the FW example again. Suppose that I no= w have policy-set=92s a,b,c, & d. Lets further suppose that policy-set= =92s a&b are available at service nodes 1, 2, 3 & 4 and policy-set= =92s c&d are available at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot s= end the traffic to service nodes 5, 6 or 7 as they will not have the necess= ary policy to treat the traffic even though we have said they are of the same service function = =93type". This gives us a dilemma that can be tackled in 1 of 3 ways i= mho:

  1. I could split them into 2 separate service functions; let=92s call them FW(= a,b) & FW(c,d). Now the problem with this is that now I have to rely up= on the FW itself to determine which of the policy-set=92s to apply using so= me out-of-scope for the SFC WG mechanism. 
  2. To avoid reclassification as indicated in (1) I could split each FW+pol= icy-set into its own distinct service function; FW(a), FW(b), FW(c), and FW= (d). The problem with this is that I could end up with a large number of di= stinct service functions.
  3. I could let the SFC service encapsulation carry enough information for the = FW to determine which of the policy-set=92s a,b,c,d to apply to a given flo= w without needing to reclassify at the FW or split al= l of the FW+policy-set combinations into separate service functions. In= other words I could simply have a service function with type =93FW=94 and = indicate the policy-set within the service encapsulation.

    4.  

    For me point (3) highlights pretty nicely one of the= reasons for having an SFC service encapsulation.

     

    From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
    Date: Monday, February 10, 2014 at 4:23 PM
    To: Jim Guichard <jguichar@= cisco.com>
    Cc: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, &q= uot;meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, = Paul Quinn <paulq@cisco.com>, = sfc <sfc-bounces@ietf.org>= ;, "sfc@ietf.org" <sfc@ietf.org>
    Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    Hi Jim,

     

    Could you = clarify what you mean by an instance of a service function instance?=

     

    Thanks,

    Cathy

     

    From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
    Sent: Monday, February 10, 2014 1:08 PM
    To: Cathy Zhang
    Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    How would you represent an inst= ance of a service function instance? Seems more logical to represent a serv= ice function type that provides function based on policy set as an independ= ent service function.

    Sent from my iPhone

    =
    On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

    I share th= e same view as Reinaldo.

    I think ea= ch Service Function is associated with a type, such as FW Service Function = or NAT Service Function

    while each= Service Instance is an instantiation of a Service Function on a Service No= de and is  associated with a specific policy profile/set of that type of Service Function.

    In a SFC a= dmin domain, there could be multiple Service Nodes (physical/virtual) that = support a specific Service Function, such as FW,

    and a serv= ice instance could be instantiated on any one of the Service Nodes (as to w= hich Service Node to instantiate the service instance,

    it depends= on load status of the Service Nodes, network proximity etc., which is out = of scope) . 

    Multiple f= low chains can be associated with the same Service Instance on a Service No= de, which means these flows will be applied the same policy set

    for that s= pecific type of service function, as shown in the following diagram.=

     

    BTW, I wou= ld like to suggest that the draft adds a definition for =93Service Instance= =94 to bring everyone on the same page as to its semantics.

     

    Thanks,

    Cathy

    <image0= 02.png>

     

    From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
    Sent: Monday, February 10, 2014 12:22 PM
    To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
    Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    Based on the= definition I see this differently.<= /span>

     

    The same ser= vice function could be instantiated with  policy-set-A and later insta= ntiated with  policy-set-B. It is still the same service function, but different instances. 

     

    Therefore I = would consider {1 below} one service function (say, NAT44) and two differen= t service function instances, one that applies  policy-set-A and other that applies  policy-set-A.

     

    From: "Jim Guichard (jgui= char)" <jguichar@cisco.com>
    Date: Monday, February 10, 2014 at 11:12 AM
    To: Ron Parker <    Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
    Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    1. A service function that applies policy-set-A an= d a different service function that applies policy-set-B e.g. They are two = distinct service functions.
--_000_2A715232CE764378A25079D620AA4DE8affirmednetworkscom_-- From Chuong.D.Pham@team.telstra.com Mon Feb 10 18:55:20 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791941A0755; Mon, 10 Feb 2014 18:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnE6wfxNs7Hj; Mon, 10 Feb 2014 18:55:15 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 039B31A0750; Mon, 10 Feb 2014 18:55:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,822,1384261200"; d="scan'208,217";a="173451808" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 11 Feb 2014 13:55:13 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="147695744" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcani.tcif.telstra.com.au with ESMTP; 11 Feb 2014 13:55:12 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 11 Feb 2014 13:55:12 +1100 From: "Pham, Chuong D" To: Ron Parker Date: Tue, 11 Feb 2014 13:55:11 +1100 Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgCAABNCAIAACXsAgAADaoCAAARlgIAAH9+A//99tLiAAI29AP//jKyQgAAbJ5A= Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com> In-Reply-To: <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: multipart/alternative; boundary="_000_5602569641FB314FB4D9AD5659D41B9C2983B7CD5EWSMSG3154Vsrv_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:55:20 -0000 --_000_5602569641FB314FB4D9AD5659D41B9C2983B7CD5EWSMSG3154Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron, I would just simply call the policy set "policy" (the term used by a FW ven= dor we use in our network). There are many policies in the firewall (1000's= ) of them. I don't think it is scalable for the classifier to know all of t= hese these policies. This would also require integration between each firew= all vendor and the classifier's implementation for the two to understand th= e language. Note that a flow may find matches among multiple policies and t= he policies can be nested etc. What the classifier can do at a minimum is t= o have information related to which FW SF (physical, logical or virtual) sh= ould be included in the chain for a particular flow. If multiple FW SFs i.e= . multiple virtualised FWs hosting different sets of policies designed for = different tenant/networks reside at a same IP address then I can see a bene= fit of the classifier to specify the correct virtual firewall by name or si= milar semantics which is understood by the front-end of the virtualised fir= ewall SF complex. In any case, pointing to the specific policies within the policies configur= ed on a FW (physical/logical/virtual) is not scalable or workable, IMHO. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 12:06 PM To: Pham, Chuong D Cc: Jim Guichard (jguichar); sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (pa= ulq); meng.wei2@zte.com.cn; Reinaldo Penno (repenno) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Chuong A policy set is simply the configuration. What it means is service functio= n specific. For example, with NAT44, perhaps when some set of clients acc= ess some particular remote subnet, they should be NAT'd with a special pool= of IP addresses, otherwise the generic pool of IP addresses. But for som= e other set of clients, always use the generic pool. This would be 2 poli= cy sets (I'm open to better names for this). Per our previous thread, you could chose to call this NAT44-A and NAT44-B a= nd create the classifier policy rules such that the correct flows engage th= e correct chains and therefore the correct NAT functionality. It may even = be that both logical NAT instances are located with the same transport addr= ess. Or, you could 1/2 the number of distinct chains by requiring that the NAT44= decide on its own, without an assist from the classifier, when to use the = special pool. I believe that both use cases are entirely valid and both should be support= ed. Ron On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" > wrote: What is a policy set? Is it a virtual/logical firewall? Or is it what polic= ies to apply to a traffic flow? In any case, in approach 3, the classifier would need to know which FW owns= which policy sets anyway unless the idea is having only one FW SF with all= the policy sets in it. If the classifier needs to know the individual FW S= Fs, I think approach 1 and 2 in combination is more practical. Effectively, there will be FW SF1, SF2...SFn in a network, depends on the n= eed of that network. A FW SF may host multiple policy sets. It's the local = choice and in this case, the FW will need to decide which policy set to use= , just like the way it does today. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 10:31 AM To: Jim Guichard (jguichar) Cc: sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq)= ; meng.wei2@zte.com.cn; Reinaldo Penno (repenn= o) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Approach 3 is the most elegant, but also the most costly in terms of the se= rvice header. Rather than deriving both sequence and policy selection from= the chain id that presumably appears in the service header, we would now n= eed a stack of policy set identifiers that is pushed on by the classifier -= - one for each service function in the chain. Ron On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" > wrote: Hi Cathy, let's take the FW example with policy-set-a and policy-set-b. If we treat t= he FW as a type of service function where policy-set-a and policy-set-b are= instances of that "type" of service function then my point is that each of= those could be located at multiple points in the network thereby giving yo= u multiple "instances" of the policy-set-a "instance" and the policy-set-b = "instance. I will argue that that is not the right way to look at it.. Let = me explain my logic. Let's take the FW example again. Suppose that I now have policy-set's a,b,c= , & d. Lets further suppose that policy-set's a&b are available at service = nodes 1, 2, 3 & 4 and policy-set's c&d are available at service nodes 5, 6 = & 7. Given this, when I instantiate an SFC that requires say policy-set-a, = I cannot send the traffic to service nodes 5, 6 or 7 as they will not have = the necessary policy to treat the traffic even though we have said they are= of the same service function "type". This gives us a dilemma that can be t= ackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let's call them = FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely upo= n the FW itself to determine which of the policy-set's to apply using some = out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+po= licy-set into its own distinct service function; FW(a), FW(b), FW(c), and F= W(d). The problem with this is that I could end up with a large number of d= istinct service functions. 3. I could let the SFC service encapsulation carry enough information for= the FW to determine which of the policy-set's a,b,c,d to apply to a given = flow without needing to reclassify at the FW or split all of the FW+policy-= set combinations into separate service functions. In other words I could si= mply have a service function with type "FW" and indicate the policy-set wit= hin the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for "Service = Instance" to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service f= unction that applies policy-set-B e.g. They are two distinct service functi= ons. --_000_5602569641FB314FB4D9AD5659D41B9C2983B7CD5EWSMSG3154Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ron,=

 

I would just simply call the policy set “po= licy” (the term used by a FW vendor we use in our network). There are= many policies in the firewall (1000’s) of them. I don’t think = it is scalable for the classifier to know all of these these policies. This= would also require integration between each firewall vendor and the classi= fier’s implementation for the two to understand the language. Note th= at a flow may find matches among multiple policies and the policies can be = nested etc. What the classifier can do at a minimum is to have information = related to which FW SF (physical, logical or virtual) should be included in= the chain for a particular flow. If multiple FW SFs i.e. multiple virtuali= sed FWs hosting different sets of policies designed for different tenant/ne= tworks reside at a same IP address then I can see a benefit of the classifi= er to specify the correct virtual firewall by name or similar semantics whi= ch is understood by the front-end of the virtualised firewall SF complex.

 

In any case, pointing to the specific policies= within the policies configured on a FW (physical/logical/virtual) is not s= calable or workable, IMHO.

 

Regards,

Chuong

 

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tue= sday, 11 February 2014 12:06 PM
To: Pham, Chuong D
Cc: = Jim Guichard (jguichar); sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq)= ; meng.wei2@zte.com.cn; Reinaldo Penno (repenno)
Subject: Re: [sf= c] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt=

 

Chuong

&= nbsp;

A policy set is simply the c= onfiguration.  What it means is service function specific.   For = example, with NAT44, perhaps when some set of clients access some particula= r remote subnet, they should be NAT'd with a special pool of IP addresses, = otherwise the generic pool of IP addresses.   But for some other set o= f clients, always use the generic pool.   This would be 2 policy sets = (I'm open to better names for this).   

=

 

P= er our previous thread, you could chose to call this NAT44-A and NAT44-B an= d create the classifier policy rules such that the correct flows engage the= correct chains and therefore the correct NAT functionality.  It may e= ven be that both logical NAT instances are located with the same transport = address. 

 

Or, you could 1/2 the number of dist= inct chains by requiring that the NAT44 decide on its own, without an assis= t from the classifier, when to use the special pool.  

<= /div>

 

I believe that both use cases are entirely valid and both should b= e supported.  

&nbs= p;

  Ron

=

 


On Feb 10, 2014, at 7:01 PM, "P= ham, Chuong D" <C= huong.D.Pham@team.telstra.com> wrote:

= What is a policy set? Is it a virtual/logical firewall? Or is it wha= t policies to apply to a traffic flow?

 

In a= ny case, in approach 3, the classifier would need to know which FW owns whi= ch policy sets anyway unless the idea is having only one FW SF with all the= policy sets in it. If the classifier needs to know the individual FW SFs, = I think approach 1 and 2 in combination is more practical.

 

Effectively, there will be FW SF1, SF2…SFn in a network= , depends on the need of that network. A FW SF may host multiple policy set= s. It’s the local choice and in this case, the FW will need to decide= which policy set to use, just like the way it does today.

 

Regards,

Ch= uong

 

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks= .com]
Sent: Tuesday, 11 February 2014 10:31 AM
To:= Jim Guichard (jguichar)
Cc: sfc@= ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo Penno (repenno)
S= ubject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arc= h-04.txt

 <= /o:p>

Approach 3 is the most elegant, but also= the most costly in terms of the service header.  Rather than deriving= both sequence and policy selection from the chain id that presumably appea= rs in the service header, we would now need a stack of policy set identifie= rs that is pushed on by the classifier -- one for each service function in = the chain. 

 <= /o:p>

   Ron

 


On Feb 10, 2014, at 6:17 PM, &quo= t;Jim Guichard (jguichar)" <j= guichar@cisco.com> wrote:

Hi Cath= y,

 

let’s take the FW example with policy-set-= a and policy-set-b. If we treat the FW as a type of service function where = policy-set-a and policy-set-b are instances of that “type" of se= rvice function then my point is that each of those could be located at mult= iple points in the network thereby giving you multiple “instancesR= 21; of the policy-set-a “instance” and the policy-set-b “= instance. I will argue that that is not the right way to look at it.. Let m= e explain my logic.

 

Let’s take the FW example= again. Suppose that I now have policy-set’s a,b,c, & d. Lets fur= ther suppose that policy-set’s a&b are available at service nodes= 1, 2, 3 & 4 and policy-set’s c&d are available at service no= des 5, 6 & 7. Given this, when I instantiate an SFC that requires say p= olicy-set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they w= ill not have the necessary policy to treat the traffic even though&n= bsp;we have said they are of the same service function “type". T= his gives us a dilemma that can be tackled in 1 of 3 ways imho:<= /p>

  1. I could spl= it them into 2 separate service functions; let’s call them FW(a,b) &a= mp; FW(c,d). Now the problem with this is that now I have to rely upon the = FW itself to determine which of the policy-set’s to apply using some = out-of-scope for the SFC WG mechanism. 
  2. To avoid reclassification as indicated in (1) I could spli= t each FW+policy-set into its own distinct service function; FW(a), FW(b), = FW(c), and FW(d). The problem with this is that I could end up with a large= number of distinct service functions.
  3. I could let the SFC service encapsulation carry enough informati= on for the FW to determine which of the policy-set’s a,b,c,d to apply= to a given flow without needing to reclassify at the FW or<= /b> split all of the FW+policy-set combinations into separate service = functions. In other words I could simply have a service function with type = “FW” and indicate the policy-set within the service encapsulati= on.

 

For me point (3) highlights pretty nicely one o= f the reasons for having an SFC service encapsulation.

=

 

From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
Date: Mon= day, February 10, 2014 at 4:23 PM
To: Jim Guichard <jguichar@cisco.com>
Cc: "= Reinaldo Penno (repenno)" <rep= enno@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, Paul Quinn <paulq@cisco.com>, sfc <sfc-bounces@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] Fwd: New Version= Notification for draft-quinn-sfc-arch-04.txt

 

Hi Jim,

 

Could you clarify what you mean by an instance of a service= function instance?

 

Thanks,

Cath= y

 

From: Jim Guichard (jguichar) [mailt= o:jguichar@cisco.com]
Sent: Monday, February 10, 2014 1:08 P= M
To: Cathy Zhang
Cc: Reinaldo Penno (repenno); Ron Par= ker; meng.wei2@zte.com.cn; Paul= Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-a= rch-04.txt

 

How would you represent an instance of a service function instance= ? Seems more logical to represent a service function type that provides fun= ction based on policy set as an independent service function.

Sent f= rom my iPhone


On Feb 10, 2014, at 3:55 PM, = "Cathy Zhang" <Cat= hy.H.Zhang@huawei.com> wrote:

<= span lang=3DEN-US style=3D'font-size:14.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>I share the same view as Reinaldo.

I think each Service Function is = associated with a type, such as FW Service Function or NAT Service Function=

while each = Service Instance is an instantiation of a Service Function on a Service Nod= e and is  associated with a specific policy profile/set of that type o= f Service Function.

In a SFC admin domain, there could be multiple Service Nodes (phy= sical/virtual) that support a specific Service Function, such as FW,

and a service inst= ance could be instantiated on any one of the Service Nodes (as to which Ser= vice Node to instantiate the service instance,

it depends on load status of the Service= Nodes, network proximity etc., which is out of scope) .  =

Multiple flow chains can= be associated with the same Service Instance on a Service Node, which mean= s these flows will be applied the same policy set

for that specific type of service fun= ction, as shown in the following diagram.

 

BTW, I would like to suggest that the draft adds a d= efinition for “Service Instance” to bring everyone on the same = page as to its semantics.

 

Thanks,

Cathy

&l= t;image002.png>

 

From: sfc [mailto= :sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
= Sent: Monday, February 10, 2014 12:22 PM
To: Jim Guichard = (jguichar); Ron Parker; meng.wei2@z= te.com.cn
Cc: Paul Quinn (paulq); sfc; sfc@ietf.org
Subject: Re: [sfc] Fwd: New Version No= tification for draft-quinn-sfc-arch-04.txt

 

<= p class=3DMsoNormal>Based on the definition I see this di= fferently.

 

The same service function could be instantiated with  polic= y-set-A and later instantiated with  policy-set-B. It is still the sam= e service function, but different instances. 

 

=

Therefore I would conside= r {1 below} one service function (say, NAT44) and two different service fun= ction instances, one that applies  policy-set-A and other that applies=  policy-set-A.

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

From: "Jim Gui= chard (jguichar)" <jguichar@c= isco.com>
Date: Monday, February 10, 2014 at 11:12 AM
<= b>To: Ron Parker <Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Cc: "Paul = Quinn (paulq)" <paulq@cisco.com<= /a>>, "sfc@ietf.org" <<= a href=3D"mailto:sfc@ietf.org">sfc@ietf.org>, sfc <sfc-bounces@ietf.org>
Subject: R= e: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt

 =

  1. A service function that applies policy-set-A and = a different service function that applies policy-set-B e.g. They are two di= stinct service functions.
= --_000_5602569641FB314FB4D9AD5659D41B9C2983B7CD5EWSMSG3154Vsrv_-- From Ron_Parker@affirmednetworks.com Mon Feb 10 19:41:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FDA1A055E; Mon, 10 Feb 2014 19:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 xXK6aZhrMtG3; Mon, 10 Feb 2014 19:41:24 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id B53281A072B; Mon, 10 Feb 2014 19:41:24 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 19:41:24 -0800 From: Ron Parker To: "Pham, Chuong D" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmh/x/U2/0y5WE+DMDELbPHvWpquk7xggADNqgCAABNCAIAACXsAgAADaoCAAARlgIAAH9+A//99tLiAAI29AP//jKyQgAAbJ5CAABBfLA== Date: Tue, 11 Feb 2014 03:41:23 +0000 Message-ID: References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F1D0D7B8DE494D548921CE72DFFD5705affirmednetworkscom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 03:41:28 -0000 --_000_F1D0D7B8DE494D548921CE72DFFD5705affirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Chuong, The reason I used policy set was precisely as you described. Perhaps for t= enant A there are a 1000 ACLs. For tenant B, there are also 1000 , but 10= 0 are different. Just like in the 3gpp PCRF practical use cases, a "ruleb= ase" is indicated for a subscriber, never the individual rules. In the ca= se where there are relatively few distinct rulebases (perhaps the mythical = gold silver and bronze users each receive distinct treatment), treating the= sf function+rulebase as a distinct logical instance could simplify the ove= rall service orchestration by concentrating the rulebase selection in one p= lace. Another way to view this is that the policy may be evaluated at 2 l= evels -- first pick the set of classification rules using non-specified mec= hanisms, then apply the selected set of policy to the relevant traffic flow= s. Of course this 2 level approach would be optional. I'm not sure much = needs to happen in the architecture except to ensure that multiple logical = service functions, even of the same type, are allowed to have the same tran= sport address (locator). Ron On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" > wrote: Ron, I would just simply call the policy set =93policy=94 (the term used by a FW= vendor we use in our network). There are many policies in the firewall (10= 00=92s) of them. I don=92t think it is scalable for the classifier to know = all of these these policies. This would also require integration between ea= ch firewall vendor and the classifier=92s implementation for the two to und= erstand the language. Note that a flow may find matches among multiple poli= cies and the policies can be nested etc. What the classifier can do at a mi= nimum is to have information related to which FW SF (physical, logical or v= irtual) should be included in the chain for a particular flow. If multiple = FW SFs i.e. multiple virtualised FWs hosting different sets of policies des= igned for different tenant/networks reside at a same IP address then I can = see a benefit of the classifier to specify the correct virtual firewall by = name or similar semantics which is understood by the front-end of the virtu= alised firewall SF complex. In any case, pointing to the specific policies within the policies configur= ed on a FW (physical/logical/virtual) is not scalable or workable, IMHO. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 12:06 PM To: Pham, Chuong D Cc: Jim Guichard (jguichar); sfc@ietf.org; Cathy Zhang= ; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo Penno (repenno) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Chuong A policy set is simply the configuration. What it means is service functio= n specific. For example, with NAT44, perhaps when some set of clients acc= ess some particular remote subnet, they should be NAT'd with a special pool= of IP addresses, otherwise the generic pool of IP addresses. But for som= e other set of clients, always use the generic pool. This would be 2 poli= cy sets (I'm open to better names for this). Per our previous thread, you could chose to call this NAT44-A and NAT44-B a= nd create the classifier policy rules such that the correct flows engage th= e correct chains and therefore the correct NAT functionality. It may even = be that both logical NAT instances are located with the same transport addr= ess. Or, you could 1/2 the number of distinct chains by requiring that the NAT44= decide on its own, without an assist from the classifier, when to use the = special pool. I believe that both use cases are entirely valid and both should be support= ed. Ron On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" > wrote: What is a policy set? Is it a virtual/logical firewall? Or is it what polic= ies to apply to a traffic flow? In any case, in approach 3, the classifier would need to know which FW owns= which policy sets anyway unless the idea is having only one FW SF with all= the policy sets in it. If the classifier needs to know the individual FW S= Fs, I think approach 1 and 2 in combination is more practical. Effectively, there will be FW SF1, SF2=85SFn in a network, depends on the n= eed of that network. A FW SF may host multiple policy sets. It=92s the loca= l choice and in this case, the FW will need to decide which policy set to u= se, just like the way it does today. Regards, Chuong From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, 11 February 2014 10:31 AM To: Jim Guichard (jguichar) Cc: sfc@ietf.org; Cathy Zhang; sfc; Paul Quinn (paulq)= ; meng.wei2@zte.com.cn; Reinaldo Penno (repenn= o) Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Approach 3 is the most elegant, but also the most costly in terms of the se= rvice header. Rather than deriving both sequence and policy selection from= the chain id that presumably appears in the service header, we would now n= eed a stack of policy set identifiers that is pushed on by the classifier -= - one for each service function in the chain. Ron On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" > wrote: Hi Cathy, let=92s take the FW example with policy-set-a and policy-set-b. If we treat= the FW as a type of service function where policy-set-a and policy-set-b a= re instances of that =93type" of service function then my point is that eac= h of those could be located at multiple points in the network thereby givin= g you multiple =93instances=94 of the policy-set-a =93instance=94 and the p= olicy-set-b =93instance. I will argue that that is not the right way to loo= k at it.. Let me explain my logic. Let=92s take the FW example again. Suppose that I now have policy-set=92s a= ,b,c, & d. Lets further suppose that policy-set=92s a&b are available at se= rvice nodes 1, 2, 3 & 4 and policy-set=92s c&d are available at service nod= es 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy= -set-a, I cannot send the traffic to service nodes 5, 6 or 7 as they will n= ot have the necessary policy to treat the traffic even though we have said = they are of the same service function =93type". This gives us a dilemma tha= t can be tackled in 1 of 3 ways imho: 1. I could split them into 2 separate service functions; let=92s call th= em FW(a,b) & FW(c,d). Now the problem with this is that now I have to rely = upon the FW itself to determine which of the policy-set=92s to apply using = some out-of-scope for the SFC WG mechanism. 2. To avoid reclassification as indicated in (1) I could split each FW+p= olicy-set into its own distinct service function; FW(a), FW(b), FW(c), and = FW(d). The problem with this is that I could end up with a large number of = distinct service functions. 3. I could let the SFC service encapsulation carry enough information fo= r the FW to determine which of the policy-set=92s a,b,c,d to apply to a giv= en flow without needing to reclassify at the FW or split all of the FW+poli= cy-set combinations into separate service functions. In other words I could= simply have a service function with type =93FW=94 and indicate the policy-= set within the service encapsulation. For me point (3) highlights pretty nicely one of the reasons for having an = SFC service encapsulation. From: Cathy Zhang > Date: Monday, February 10, 2014 at 4:23 PM To: Jim Guichard > Cc: "Reinaldo Penno (repenno)" = >, Ron Parker >, "meng.wei2@zte.com.cn" >, Paul Quinn >, sfc >, "sfc@ietf.org" = > Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Hi Jim, Could you clarify what you mean by an instance of a service function instan= ce? Thanks, Cathy From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Monday, February 10, 2014 1:08 PM To: Cathy Zhang Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt How would you represent an instance of a service function instance? Seems m= ore logical to represent a service function type that provides function bas= ed on policy set as an independent service function. Sent from my iPhone On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" > wrote: I share the same view as Reinaldo. I think each Service Function is associated with a type, such as FW Service= Function or NAT Service Function while each Service Instance is an instantiation of a Service Function on a = Service Node and is associated with a specific policy profile/set of that = type of Service Function. In a SFC admin domain, there could be multiple Service Nodes (physical/virt= ual) that support a specific Service Function, such as FW, and a service instance could be instantiated on any one of the Service Node= s (as to which Service Node to instantiate the service instance, it depends on load status of the Service Nodes, network proximity etc., whi= ch is out of scope) . Multiple flow chains can be associated with the same Service Instance on a = Service Node, which means these flows will be applied the same policy set for that specific type of service function, as shown in the following diagr= am. BTW, I would like to suggest that the draft adds a definition for =93Servic= e Instance=94 to bring everyone on the same page as to its semantics. Thanks, Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn= o) Sent: Monday, February 10, 2014 12:22 PM To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn Cc: Paul Quinn (paulq); sfc; sfc@ietf.org Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt Based on the definition I see this differently. The same service function could be instantiated with policy-set-A and late= r instantiated with policy-set-B. It is still the same service function, b= ut different instances. Therefore I would consider {1 below} one service function (say, NAT44) and = two different service function instances, one that applies policy-set-A an= d other that applies policy-set-A. From: "Jim Guichard (jguichar)" > Date: Monday, February 10, 2014 at 11:12 AM To: Ron Parker >, Cisco Employee >= , "meng.wei2@zte.com.cn" > Cc: "Paul Quinn (paulq)" >, "sfc@ie= tf.org" >, sfc > Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-0= 4.txt 1. A service function that applies policy-set-A and a different service = function that applies policy-set-B e.g. They are two distinct service funct= ions. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_F1D0D7B8DE494D548921CE72DFFD5705affirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Chuong,

The reason I used policy set was precisely as you described.  Per= haps for tenant A there are a 1000 ACLs.   For tenant B, there are als= o 1000 , but 100 are different.   Just like in the 3gpp PCRF practical= use cases, a "rulebase" is indicated for a subscriber, never the individual rules.   In the case where there are relatively = few distinct rulebases (perhaps the mythical gold silver and bronze users e= ach receive distinct treatment), treating the sf function+rulebase as a= distinct logical instance could simplify the overall service orchestration by concentrating the rulebase selection = in one place.   Another way to view this is that the policy may be eva= luated at 2 levels -- first pick the set of classification rules using non-= specified mechanisms, then apply the selected set of policy to the relevant traffic flows.   Of course thi= s 2 level approach would be optional.  I'm not sure much needs to happ= en in the architecture except to ensure that multiple logical service funct= ions, even of the same type, are allowed to have the same transport address (locator). 

   Ron



On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com> w= rote:

Ron,

 <= /p>

I would just simply call = the policy set =93policy=94 (the term used by a FW vendor we use in our net= work). There are many policies in the firewall (1000=92s) of them. I don=92t think it is scalable for the classifier to know all of these the= se policies. This would also require integration between each firewall vend= or and the classifier=92s implementation for the two to understand the lang= uage. Note that a flow may find matches among multiple policies and the policies can be nested etc. What the class= ifier can do at a minimum is to have information related to which FW SF (ph= ysical, logical or virtual) should be included in the chain for a particula= r flow. If multiple FW SFs i.e. multiple virtualised FWs hosting different sets of policies designed for d= ifferent tenant/networks reside at a same IP address then I can see a benef= it of the classifier to specify the correct virtual firewall by name or sim= ilar semantics which is understood by the front-end of the virtualised firewall SF complex.=

 <= /p>

In any case, pointing to = the specific policies within the policies configured on a FW (physical/logi= cal/virtual) is not scalable or workable, IMHO.

 <= /p>

Regards,

Chuong<= /p>

 <= /p>

 <= /p>

 <= /p>

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, 11 February 2014 12:06 PM
To: Pham, Chuong D
Cc: Jim Guichard (jguichar); sfc@iet= f.org; Cathy Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Chuong

 

A policy set is simply the configuration.  What= it means is service function specific.   For example, with NAT44, per= haps when some set of clients access some particular remote subnet, they sh= ould be NAT'd with a special pool of IP addresses, otherwise the generic pool of IP addresses.   But for some other set = of clients, always use the generic pool.   This would be 2 policy sets= (I'm open to better names for this).   

 

Per our previous thread, you could chose to call thi= s NAT44-A and NAT44-B and create the classifier policy rules such that the = correct flows engage the correct chains and therefore the correct NAT funct= ionality.  It may even be that both logical NAT instances are located with the same transport address. 

 

Or, you could 1/2 the number of distinct chains by r= equiring that the NAT44 decide on its own, without an assist from the class= ifier, when to use the special pool.  

 

I believe that both use cases are entirely valid and= both should be supported.  

 

  Ron

 


On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com> w= rote:

What is a policy set? Is = it a virtual/logical firewall? Or is it what policies to apply to a traffic= flow?

 <= /p>

In any case, in approach = 3, the classifier would need to know which FW owns which policy sets anyway= unless the idea is having only one FW SF with all the policy sets in it. If the classifier needs to know the individual FW SFs, I think= approach 1 and 2 in combination is more practical.

 <= /p>

Effectively, there will b= e FW SF1, SF2=85SFn in a network, depends on the need of that network. A FW= SF may host multiple policy sets. It=92s the local choice and in this case, the FW will need to decide which policy set to use, just lik= e the way it does today.

 <= /p>

Regards,

Chuong<= /p>

 <= /p>

 <= /p>

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, 11 February 2014 10:31 AM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org; Cathy Zhang; s= fc; Paul Quinn (paulq); meng.wei2@zte.com.cn; Reinaldo = Penno (repenno)
Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

 

Approach 3 is the most elegant, but also the most co= stly in terms of the service header.  Rather than deriving both sequen= ce and policy selection from the chain id that presumably appears in the se= rvice header, we would now need a stack of policy set identifiers that is pushed on by the classifier -- one for e= ach service function in the chain. 

 

   Ron

 


On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Hi Cathy,

 

let=92s take the FW example with policy-set-a and po= licy-set-b. If we treat the FW as a type of service function where policy-s= et-a and policy-set-b are instances of that =93type" of service functi= on then my point is that each of those could be located at multiple points in the network thereby giving you multiple = =93instances=94 of the policy-set-a =93instance=94 and the policy-set-b =93= instance. I will argue that that is not the right way to look at it.. Let m= e explain my logic.

 

Let=92s take the FW example again. Suppose that I no= w have policy-set=92s a,b,c, & d. Lets further suppose that policy-set= =92s a&b are available at service nodes 1, 2, 3 & 4 and policy-set= =92s c&d are available at service nodes 5, 6 & 7. Given this, when I instantiate an SFC that requires say policy-set-a, I cannot s= end the traffic to service nodes 5, 6 or 7 as they will not have the necess= ary policy to treat the traffic even though we have said they are of the same service function = =93type". This gives us a dilemma that can be tackled in 1 of 3 ways i= mho:

  1. I could split them into 2 separate service functions; let=92s call them FW(= a,b) & FW(c,d). Now the problem with this is that now I have to rely up= on the FW itself to determine which of the policy-set=92s to apply using so= me out-of-scope for the SFC WG mechanism. 
  2. To avoid reclassification as indicated in (1) I could split each FW+pol= icy-set into its own distinct service function; FW(a), FW(b), FW(c), and FW= (d). The problem with this is that I could end up with a large number of di= stinct service functions.
  3. I could let the SFC service encapsulation carry enough information for the = FW to determine which of the policy-set=92s a,b,c,d to apply to a given flo= w without needing to reclassify at the FW or split al= l of the FW+policy-set combinations into separate service functions. In= other words I could simply have a service function with type =93FW=94 and = indicate the policy-set within the service encapsulation.

    4.  

    For me point (3) highlights pretty nicely one of the= reasons for having an SFC service encapsulation.

     

    From: Cathy Zhang <Cathy.H.Zhang@huawei.com>
    Date: Monday, February 10, 2014 at 4:23 PM
    To: Jim Guichard <jguichar@= cisco.com>
    Cc: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, &q= uot;meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>, = Paul Quinn <paulq@cisco.com>, = sfc <sfc-bounces@ietf.org>= ;, "sfc@ietf.org" <sfc@ietf.org>
    Subject: RE: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    Hi Jim,

     

    Could you = clarify what you mean by an instance of a service function instance?=

     

    Thanks,

    Cathy

     

    From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
    Sent: Monday, February 10, 2014 1:08 PM
    To: Cathy Zhang
    Cc: Reinaldo Penno (repenno); Ron Parker; meng.wei2@zte.com.cn; Paul Quinn (paulq); sfc; sfc@ietf.org
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    How would you represent an inst= ance of a service function instance? Seems more logical to represent a serv= ice function type that provides function based on policy set as an independ= ent service function.

    Sent from my iPhone

    =
    On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:

    I share th= e same view as Reinaldo.

    I think ea= ch Service Function is associated with a type, such as FW Service Function = or NAT Service Function

    while each= Service Instance is an instantiation of a Service Function on a Service No= de and is  associated with a specific policy profile/set of that type of Service Function.

    In a SFC a= dmin domain, there could be multiple Service Nodes (physical/virtual) that = support a specific Service Function, such as FW,

    and a serv= ice instance could be instantiated on any one of the Service Nodes (as to w= hich Service Node to instantiate the service instance,

    it depends= on load status of the Service Nodes, network proximity etc., which is out = of scope) . 

    Multiple f= low chains can be associated with the same Service Instance on a Service No= de, which means these flows will be applied the same policy set

    for that s= pecific type of service function, as shown in the following diagram.=

     

    BTW, I wou= ld like to suggest that the draft adds a definition for =93Service Instance= =94 to bring everyone on the same page as to its semantics.

     

    Thanks,

    Cathy

    <image0= 02.png>

     

    From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
    Sent: Monday, February 10, 2014 12:22 PM
    To: Jim Guichard (jguichar); Ron Parker; meng.wei2@zte.com.cn
    Cc: Paul Quinn (paulq); sfc; sfc@iet= f.org
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    Based on the= definition I see this differently.

     

    The same ser= vice function could be instantiated with  policy-set-A and later insta= ntiated with  policy-set-B. It is still the same service function, but different instances. 

     

    Therefore I = would consider {1 below} one service function (say, NAT44) and two differen= t service function instances, one that applies  policy-set-A and other that applies  policy-set-A.

     

    From: "Jim Guichard (jgui= char)" <jguichar@cisco.com>
    Date: Monday, February 10, 2014 at 11:12 AM
    To: Ron Parker <    Ron_Parker@affirmednetworks.com>, Cisco Employee <repenno@cisco.com>, "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
    Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "sfc@ie= tf.org" <sfc@ietf.org>, = sfc <sfc-bounces@ietf.org>= ;
    Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc= -arch-04.txt

     

    1. A service function that applies policy-set-A an= d a different service function that applies policy-set-B e.g. They are two = distinct service functions.
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_F1D0D7B8DE494D548921CE72DFFD5705affirmednetworkscom_-- From jmh@joelhalpern.com Mon Feb 10 20:20:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A131A0791; Mon, 10 Feb 2014 20:20:28 -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_21=0.6, 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 8i-ADcomDrqg; Mon, 10 Feb 2014 20:20:25 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A90AD1A0678; Mon, 10 Feb 2014 20:20:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8FE8540290A; Mon, 10 Feb 2014 20:20:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A0723402908; Mon, 10 Feb 2014 20:20:20 -0800 (PST) Message-ID: <52F9A504.1090103@joelhalpern.com> Date: Mon, 10 Feb 2014 23:20:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ron Parker , "Pham, Chuong D" References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , "meng.wei2@zte.com.cn" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 04:20:28 -0000 This seems to be a distinction which will be made differently in different cases. We ought not mandate that there be different service instances for different policies, but we also should not prohibit it. The way we typically design IETF RFCs will lead naturally to the above result. The general rule is taht as long as things interact properly, you can do whatever you want. So one environment can have different service instances, on different chains, for different policies. Another deployment may have a collection of instances, each of which can apply all the policies, and the collection may itself appear to service chaining as a single service function instance (as long as the steering can steer traffic to it.) Yours, Joel On 2/10/14, 10:41 PM, Ron Parker wrote: > Chuong, > > The reason I used policy set was precisely as you described. Perhaps > for tenant A there are a 1000 ACLs. For tenant B, there are also 1000 > , but 100 are different. Just like in the 3gpp PCRF practical use > cases, a "rulebase" is indicated for a subscriber, never the individual > rules. In the case where there are relatively few distinct rulebases > (perhaps the mythical gold silver and bronze users each receive distinct > treatment), treating the sf function+rulebase as a distinct logical > instance could simplify the overall service orchestration by > concentrating the rulebase selection in one place. Another way to view > this is that the policy may be evaluated at 2 levels -- first pick the > set of classification rules using non-specified mechanisms, then apply > the selected set of policy to the relevant traffic flows. Of course > this 2 level approach would be optional. I'm not sure much needs to > happen in the architecture except to ensure that multiple logical > service functions, even of the same type, are allowed to have the same > transport address (locator). > > Ron > > > > On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" > > > wrote: > >> Ron, >> >> I would just simply call the policy set “policy” (the term used by a >> FW vendor we use in our network). There are many policies in the >> firewall (1000’s) of them. I don’t think it is scalable for the >> classifier to know all of these these policies. This would also >> require integration between each firewall vendor and the classifier’s >> implementation for the two to understand the language. Note that a >> flow may find matches among multiple policies and the policies can be >> nested etc. What the classifier can do at a minimum is to have >> information related to which FW SF (physical, logical or virtual) >> should be included in the chain for a particular flow. If multiple FW >> SFs i.e. multiple virtualised FWs hosting different sets of policies >> designed for different tenant/networks reside at a same IP address >> then I can see a benefit of the classifier to specify the correct >> virtual firewall by name or similar semantics which is understood by >> the front-end of the virtualised firewall SF complex. >> >> In any case, pointing to the specific policies within the policies >> configured on a FW (physical/logical/virtual) is not scalable or >> workable, IMHO. >> >> Regards, >> >> Chuong >> >> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> *Sent:* Tuesday, 11 February 2014 12:06 PM >> *To:* Pham, Chuong D >> *Cc:* Jim Guichard (jguichar); sfc@ietf.org ; >> Cathy Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn >> ; Reinaldo Penno (repenno) >> *Subject:* Re: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> Chuong >> >> A policy set is simply the configuration. What it means is service >> function specific. For example, with NAT44, perhaps when some set of >> clients access some particular remote subnet, they should be NAT'd >> with a special pool of IP addresses, otherwise the generic pool of IP >> addresses. But for some other set of clients, always use the generic >> pool. This would be 2 policy sets (I'm open to better names for this). >> >> Per our previous thread, you could chose to call this NAT44-A and >> NAT44-B and create the classifier policy rules such that the correct >> flows engage the correct chains and therefore the correct NAT >> functionality. It may even be that both logical NAT instances are >> located with the same transport address. >> >> Or, you could 1/2 the number of distinct chains by requiring that the >> NAT44 decide on its own, without an assist from the classifier, when >> to use the special pool. >> >> I believe that both use cases are entirely valid and both should be >> supported. >> >> Ron >> >> >> On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" >> > > wrote: >> >> What is a policy set? Is it a virtual/logical firewall? Or is it >> what policies to apply to a traffic flow? >> >> In any case, in approach 3, the classifier would need to know >> which FW owns which policy sets anyway unless the idea is having >> only one FW SF with all the policy sets in it. If the classifier >> needs to know the individual FW SFs, I think approach 1 and 2 in >> combination is more practical. >> >> Effectively, there will be FW SF1, SF2…SFn in a network, depends >> on the need of that network. A FW SF may host multiple policy >> sets. It’s the local choice and in this case, the FW will need to >> decide which policy set to use, just like the way it does today. >> >> Regards, >> >> Chuong >> >> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> *Sent:* Tuesday, 11 February 2014 10:31 AM >> *To:* Jim Guichard (jguichar) >> *Cc:* sfc@ietf.org ; Cathy Zhang; sfc; Paul >> Quinn (paulq); meng.wei2@zte.com.cn ; >> Reinaldo Penno (repenno) >> *Subject:* Re: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> Approach 3 is the most elegant, but also the most costly in terms >> of the service header. Rather than deriving both sequence and >> policy selection from the chain id that presumably appears in the >> service header, we would now need a stack of policy set >> identifiers that is pushed on by the classifier -- one for each >> service function in the chain. >> >> Ron >> >> >> On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" >> > wrote: >> >> Hi Cathy, >> >> let’s take the FW example with policy-set-a and policy-set-b. >> If we treat the FW as a type of service function where >> policy-set-a and policy-set-b are instances of that “type" of >> service function then my point is that each of those could be >> located at multiple points in the network thereby giving you >> multiple “instances” of the policy-set-a “instance” and the >> policy-set-b “instance. I will argue that that is not the >> right way to look at it.. Let me explain my logic. >> >> Let’s take the FW example again. Suppose that I now have >> policy-set’s a,b,c, & d. Lets further suppose that >> policy-set’s a&b are available at service nodes 1, 2, 3 & 4 >> and policy-set’s c&d are available at service nodes 5, 6 & 7. >> Given this, when I instantiate an SFC that requires say >> policy-set-a, I cannot send the traffic to service nodes 5, 6 >> or 7 as they will not have the necessary policy to treat the >> traffic *even though* we have said they are of the same >> service function “type". This gives us a dilemma that can be >> tackled in 1 of 3 ways imho: >> >> 1. I could split them into 2 separate service functions; >> let’s call them FW(a,b) & FW(c,d). Now the problem with >> this is that now I have to rely upon the FW itself to >> determine which of the policy-set’s to apply using some >> out-of-scope for the SFC WG mechanism. >> 2. To avoid reclassification as indicated in (1) I could >> split each FW+policy-set into its own distinct service >> function; FW(a), FW(b), FW(c), and FW(d). The problem with >> this is that I could end up with a large number of >> distinct service functions. >> 3. I could let the SFC service encapsulation carry enough >> information for the FW to determine which of the >> policy-set’s a,b,c,d to apply to a given flow >> *without* needing to reclassify at the FW *or* split all >> of the FW+policy-set combinations into separate service >> functions. In other words I could simply have a service >> function with type “FW” and indicate the policy-set within >> the service encapsulation. >> >> For me point (3) highlights pretty nicely one of the reasons >> for having an SFC service encapsulation. >> >> *From: *Cathy Zhang > > >> *Date: *Monday, February 10, 2014 at 4:23 PM >> *To: *Jim Guichard > > >> *Cc: *"Reinaldo Penno (repenno)" > >, Ron Parker >> > >, >> "meng.wei2@zte.com.cn " >> >, Paul >> Quinn >, sfc >> >, >> "sfc@ietf.org " > > >> *Subject: *RE: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> Hi Jim, >> >> Could you clarify what you mean by an instance of a service >> function instance? >> >> Thanks, >> >> Cathy >> >> *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> *Sent:* Monday, February 10, 2014 1:08 PM >> *To:* Cathy Zhang >> *Cc:* Reinaldo Penno (repenno); Ron Parker; >> meng.wei2@zte.com.cn ; Paul Quinn >> (paulq); sfc; sfc@ietf.org >> *Subject:* Re: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> How would you represent an instance of a service function >> instance? Seems more logical to represent a service function >> type that provides function based on policy set as an >> independent service function. >> >> Sent from my iPhone >> >> >> On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" >> > >> wrote: >> >> I share the same view as Reinaldo. >> >> I think each Service Function is associated with a type, >> such as FW Service Function or NAT Service Function >> >> while each Service Instance is an instantiation of a >> Service Function on a Service Node and is associated with >> a specific policy profile/set of that type of Service >> Function. >> >> In a SFC admin domain, there could be multiple Service >> Nodes (physical/virtual) that support a specific Service >> Function, such as FW, >> >> and a service instance could be instantiated on any one of >> the Service Nodes (as to which Service Node to instantiate >> the service instance, >> >> it depends on load status of the Service Nodes, network >> proximity etc., which is out of scope) . >> >> Multiple flow chains can be associated with the same >> Service Instance on a Service Node, which means these >> flows will be applied the same policy set >> >> for that specific type of service function, as shown in >> the following diagram. >> >> BTW, I would like to suggest that the draft adds a >> definition for “Service Instance” to bring everyone on the >> same page as to its semantics. >> >> Thanks, >> >> Cathy >> >> >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >> *Reinaldo Penno (repenno) >> *Sent:* Monday, February 10, 2014 12:22 PM >> *To:* Jim Guichard (jguichar); Ron Parker; >> meng.wei2@zte.com.cn >> *Cc:* Paul Quinn (paulq); sfc; sfc@ietf.org >> >> *Subject:* Re: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> Based on the definition I see this differently. >> >> The same service function could be instantiated with >> policy-set-A and later instantiated with policy-set-B. >> It is still the same service function, but different >> instances. >> >> Therefore I would consider {1 below} one service function >> (say, NAT44) and two different service function instances, >> one that applies policy-set-A and other that applies >> policy-set-A. >> >> *From: *"Jim Guichard (jguichar)" > > >> *Date: *Monday, February 10, 2014 at 11:12 AM >> *To: *Ron Parker > >, Cisco Employee >> >, >> "meng.wei2@zte.com.cn " >> > >> *Cc: *"Paul Quinn (paulq)" > >, "sfc@ietf.org >> " > >, sfc > > >> *Subject: *Re: [sfc] Fwd: New Version Notification for >> draft-quinn-sfc-arch-04.txt >> >> 1. A service function that applies policy-set-A and a >> different service function that applies policy-set-B >> e.g. They are two distinct service functions. >> >> _______________________________________________ >> 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 liushucheng@huawei.com Tue Feb 11 01:18:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AC01A08F5 for ; Tue, 11 Feb 2014 01:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 g1ex32B5bKCl for ; Tue, 11 Feb 2014 01:18:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 685391A0914 for ; Tue, 11 Feb 2014 01:18:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL80361; Tue, 11 Feb 2014 09:18:18 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 09:18:01 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 09:18:12 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.102]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 17:18:09 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPJwmwr4CF3fGr1U2UamRYQIgrPpqvxVzA Date: Tue, 11 Feb 2014 09:18:09 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Tue, 11 Feb 2014 09:18:25 -0000 SGkgYWxsLA0KDQpXZSd2ZSBqdXN0IHVwZGF0ZWQgb3VyIHVzZSBjYXNlIGRyYWZ0LiBUaGUgbWFp biBjaGFuZ2UgaXMgaW4gdGhlIHNlY3Rpb24gb2YgVXNlIENhc2Ugb2YgU2VydmljZSBGdW5jdGlv biBDaGFpbiBpbiBNb2JpbGUgQ29yZSBOZXR3b3JrLiBMb29raW5nIGZvcndhcmQgdG8geW91ciBj b21tZW50cy4NCg0KUmVnYXJkcywNClNodWNoZW5nIChXaWxsKQ0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQg NToxNCBQTQ0KVG86IE5pY29sYWkgTGV5bWFubjsgSG9uZ3l1IExpIChKdWxpbyk7IExpdXNodWNo ZW5nIChXaWxsKTsgSmllIEh1OyBIdWFuZ3lvbmcgKE9saXZlcik7IEhvbmd5dSBMaSAoSnVsaW8p OyBNb2hhbWVkIEJvdWNhZGFpcjsgTmljb2xhaSBMZXltYW5uOyBMaXVzaHVjaGVuZyAoV2lsbCk7 IFpoZW4gQ2FvOyBNb2hhbWVkIEJvdWNhZGFpcjsgWmhlbiBDYW87IEppZSBIdTsgSHVhbmd5b25n IChPbGl2ZXIpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp dS1zZmMtdXNlLWNhc2VzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1s aXUtc2ZjLXVzZS1jYXNlcy0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBXaWxsKFNodWNoZW5nKSBMaXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIFVzZSBDYXNlcw0KRG9jdW1lbnQgZGF0ZToJ MjAxNC0wMi0xMQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVS TDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s aXUtc2ZjLXVzZS1jYXNlcy0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wMQ0K RGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxp dS1zZmMtdXNlLWNhc2VzLTAxDQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbGl2ZXJ5IG9mIHZhbHVl LWFkZGVkIHNlcnZpY2VzIHJlbGllcyBvbiB0aGUgaW52b2NhdGlvbiBvZg0KICAgYWR2YW5jZWQg U2VydmljZSBGdW5jdGlvbnMgaW4gYSBzZXF1ZW50aWFsIG9yZGVyLiAgVGhpcyBtZWNoYW5pc20g aXMNCiAgIGNhbGxlZCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiAgVGhlIHNldCBv ZiBpbnZvbHZlZCBTZXJ2aWNlDQogICBGdW5jdGlvbnMgYW5kIHRoZWlyIG9yZGVyIGRlcGVuZHMg b24gdGhlIHNlcnZpY2UgY29udGV4dC4NCg0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNl dCBvZiB1c2UgY2FzZXMgb2YgU2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5pbmcgKFNGQykuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From meng.wei2@zte.com.cn Tue Feb 11 01:40:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B91A07CD; Tue, 11 Feb 2014 01:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.797 X-Spam-Level: X-Spam-Status: No, score=-98.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] 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 H2198TQFYYlj; Tue, 11 Feb 2014 01:40:27 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id F03F41A0564; Tue, 11 Feb 2014 01:40:26 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id A4E7F49C4C; Tue, 11 Feb 2014 17:40:10 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6F339CC5AAE; Tue, 11 Feb 2014 17:40:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s1B9eAPC071723; Tue, 11 Feb 2014 17:40:10 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: "Jim Guichard (jguichar)" MIME-Version: 1.0 X-KeepSent: E69138DE:DDEF5209-48257C7C:0033391A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Tue, 11 Feb 2014 17:40:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-11 17:40:09, Serialize complete at 2014-02-11 17:40:09 Content-Type: multipart/alternative; boundary="=_alternative 00354B0948257C7C_=" X-MAIL: mse01.zte.com.cn s1B9eAPC071723 Cc: "sfc@ietf.org" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 09:40:31 -0000 This is a multipart message in MIME format. --=_alternative 00354B0948257C7C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQogIElubGluZSB3aXRoIFtNV10uDQoNCg0KDQpUaGFua3MsDQpXZWkgTWVuZw0K DQoNCg0KIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28uY29tPiDQtNPa IDIwMTQtMDItMTEgMDc6MTc6Mjc6DQoNCj4gSGkgQ2F0aHksDQo+IA0KPiBsZXShr3MgdGFrZSB0 aGUgRlcgZXhhbXBsZSB3aXRoIHBvbGljeS1zZXQtYSBhbmQgcG9saWN5LXNldC1iLiBJZiB3ZSAN Cj4gdHJlYXQgdGhlIEZXIGFzIGEgdHlwZSBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHdoZXJlIHBvbGlj eS1zZXQtYSBhbmQgDQo+IHBvbGljeS1zZXQtYiBhcmUgaW5zdGFuY2VzIG9mIHRoYXQgobB0eXBl IiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHRoZW4gDQo+IG15IHBvaW50IGlzIHRoYXQgZWFjaCBvZiB0 aG9zZSBjb3VsZCBiZSBsb2NhdGVkIGF0IG11bHRpcGxlIHBvaW50cyANCj4gaW4gdGhlIG5ldHdv cmsgdGhlcmVieSBnaXZpbmcgeW91IG11bHRpcGxlIKGwaW5zdGFuY2VzobEgb2YgdGhlIA0KPiBw b2xpY3ktc2V0LWEgobBpbnN0YW5jZaGxIGFuZCB0aGUgcG9saWN5LXNldC1iIKGwaW5zdGFuY2Uu IEkgd2lsbCBhcmd1ZQ0KPiB0aGF0IHRoYXQgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gbG9vayBh dCBpdC4uIExldCBtZSBleHBsYWluIG15IGxvZ2ljLg0KPiANCj4gTGV0oa9zIHRha2UgdGhlIEZX IGV4YW1wbGUgYWdhaW4uIFN1cHBvc2UgdGhhdCBJIG5vdyBoYXZlIHBvbGljeS1zZXShrw0KPiBz IGEsYixjLCAmIGQuIExldHMgZnVydGhlciBzdXBwb3NlIHRoYXQgcG9saWN5LXNldKGvcyBhJmIg YXJlIA0KPiBhdmFpbGFibGUgYXQgc2VydmljZSBub2RlcyAxLCAyLCAzICYgNCBhbmQgcG9saWN5 LXNldKGvcyBjJmQgYXJlIA0KPiBhdmFpbGFibGUgYXQgc2VydmljZSBub2RlcyA1LCA2ICYgNy4g R2l2ZW4gdGhpcywgd2hlbiBJIGluc3RhbnRpYXRlIA0KPiBhbiBTRkMgdGhhdCByZXF1aXJlcyBz YXkgcG9saWN5LXNldC1hLCBJIGNhbm5vdCBzZW5kIHRoZSB0cmFmZmljIHRvIA0KPiBzZXJ2aWNl IG5vZGVzIDUsIDYgb3IgNyBhcyB0aGV5IHdpbGwgbm90IGhhdmUgdGhlIG5lY2Vzc2FyeSBwb2xp Y3kgDQo+IHRvIHRyZWF0IHRoZSB0cmFmZmljIGV2ZW4gdGhvdWdoIHdlIGhhdmUgc2FpZCB0aGV5 IGFyZSBvZiB0aGUgc2FtZSANCj4gc2VydmljZSBmdW5jdGlvbiChsHR5cGUiLiBUaGlzIGdpdmVz IHVzIGEgZGlsZW1tYSB0aGF0IGNhbiBiZSB0YWNrbGVkDQo+IGluIDEgb2YgMyB3YXlzIGltaG86 DQo+IDEuIEkgY291bGQgc3BsaXQgdGhlbSBpbnRvIDIgc2VwYXJhdGUgc2VydmljZSBmdW5jdGlv bnM7IGxldKGvcyBjYWxsIA0KPiB0aGVtIEZXKGEsYikgJiBGVyhjLGQpLiBOb3cgdGhlIHByb2Js ZW0gd2l0aCB0aGlzIGlzIHRoYXQgbm93IEkgaGF2ZQ0KPiB0byByZWx5IHVwb24gdGhlIEZXIGl0 c2VsZiB0byBkZXRlcm1pbmUgd2hpY2ggb2YgdGhlIHBvbGljeS1zZXShr3MgdG8NCj4gYXBwbHkg dXNpbmcgc29tZSBvdXQtb2Ytc2NvcGUgZm9yIHRoZSBTRkMgV0cgbWVjaGFuaXNtLiANCj4gMi4g VG8gYXZvaWQgcmVjbGFzc2lmaWNhdGlvbiBhcyBpbmRpY2F0ZWQgaW4gKDEpIEkgY291bGQgc3Bs aXQgZWFjaCANCj4gRlcrcG9saWN5LXNldCBpbnRvIGl0cyBvd24gZGlzdGluY3Qgc2VydmljZSBm dW5jdGlvbjsgRlcoYSksIEZXKGIpLCANCj4gRlcoYyksIGFuZCBGVyhkKS4gVGhlIHByb2JsZW0g d2l0aCB0aGlzIGlzIHRoYXQgSSBjb3VsZCBlbmQgdXAgd2l0aCANCj4gYSBsYXJnZSBudW1iZXIg b2YgZGlzdGluY3Qgc2VydmljZSBmdW5jdGlvbnMuDQoNCg0KW01XXSAiVGhlIHByb2JsZW0gd2l0 aCB0aGlzIGlzIHRoYXQgSSBjb3VsZCBlbmQgdXAgd2l0aCBhIGxhcmdlIG51bWJlcg0Kb2YgZGlz dGluY3Qgc2VydmljZSBmdW5jdGlvbnMuICIgSG93IGxhcmdlID8gMTAwPyAxMDAwPyBJdCBtYXkg YmUgDQp3aXRoaW4gYWNjZXB0YWJsZSBsaW1pdHMuDQogICAgSXQgc2VlbXMgdG8gbWUgdGhhdCAi c3BsaXRpbmcgZWFjaCBGVytwb2xpY3ktc2V0IGludG8gaXRzIG93biBkaXN0aW5jdA0Kc2Vydmlj ZSBmdW5jdGlvbiIgaXMgYSBjb25jaXNlIHdheSB0byBkZWZpbmUgc2VydmljZSBmdW5jdGlvbi5G VyBPUiBOQVQgaXMgDQoNCmp1c3QgdGhlIHNlcnZpY2UgdHlwZSByYXRoZXIgdGhhbiBzZXJ2aWNl IGZ1bmN0aW9uLiANCg0KICAgIElNTywgc2VydmljZSBmdW5jdGlvbnMgYXJlIGNvbmZpZ3VyZWQg JiBkZXBsb3llZCBieSBvcGVyYXRvcnMuIFRoZQ0KZ3JhbnVsYXJpdHkgY291bGQgYmUgZGV0ZXJt aW5lZCBieSBvcGVyYXRvcnMgLg0KICAgIEFjdHVhbGx5LCBncmFudWxhcml0eSBvZiBTRnMgaXMg dGhlIGJvbmUgb2Ygb3VyIGNvbnRlbnRpb24uDQoNCiANCg0KDQoNCg0KDQoNCj4gMy4gSSBjb3Vs ZCBsZXQgdGhlIFNGQyBzZXJ2aWNlIGVuY2Fwc3VsYXRpb24gY2FycnkgZW5vdWdoIA0KPiBpbmZv cm1hdGlvbiBmb3IgdGhlIEZXIHRvIGRldGVybWluZSB3aGljaCBvZiB0aGUgcG9saWN5LXNldKGv cyBhLGIsYywNCj4gZCB0byBhcHBseSB0byBhIGdpdmVuIGZsb3cgd2l0aG91dCBuZWVkaW5nIHRv IHJlY2xhc3NpZnkgYXQgdGhlIEZXIG9yDQo+IHNwbGl0IGFsbCBvZiB0aGUgRlcrcG9saWN5LXNl dCBjb21iaW5hdGlvbnMgaW50byBzZXBhcmF0ZSBzZXJ2aWNlIA0KPiBmdW5jdGlvbnMuIEluIG90 aGVyIHdvcmRzIEkgY291bGQgc2ltcGx5IGhhdmUgYSBzZXJ2aWNlIGZ1bmN0aW9uIA0KPiB3aXRo IHR5cGUgobBGV6GxIGFuZCBpbmRpY2F0ZSB0aGUgcG9saWN5LXNldCB3aXRoaW4gdGhlIHNlcnZp Y2UgDQplbmNhcHN1bGF0aW9uLg0KPiANCj4gRm9yIG1lIHBvaW50ICgzKSBoaWdobGlnaHRzIHBy ZXR0eSBuaWNlbHkgb25lIG9mIHRoZSByZWFzb25zIGZvciANCj4gaGF2aW5nIGFuIFNGQyBzZXJ2 aWNlIGVuY2Fwc3VsYXRpb24uDQo+IA0KPiBGcm9tOiBDYXRoeSBaaGFuZyA8Q2F0aHkuSC5aaGFu Z0BodWF3ZWkuY29tPg0KPiBEYXRlOiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IGF0IDQ6MjMg UE0NCj4gVG86IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPg0KPiBDYzogIlJlaW5h bGRvIFBlbm5vIChyZXBlbm5vKSIgPHJlcGVubm9AY2lzY28uY29tPiwgUm9uIFBhcmtlciA8DQo+ IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+LCAibWVuZy53ZWkyQHp0ZS5jb20uY24i IA0KPG1lbmcud2VpMkB6dGUuY29tLmNuDQo+ID4sIFBhdWwgUXVpbm4gPHBhdWxxQGNpc2NvLmNv bT4sIHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+LCANCiJzZmNAaWV0Zi5vcmciIDwNCj4gc2Zj QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXF1aW5uLQ0KPiBzZmMtYXJjaC0wNC50eHQNCj4gDQo+IEhpIEppbSwN Cj4gDQo+IENvdWxkIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gYnkgYW4gaW5zdGFuY2Ugb2Yg YSBzZXJ2aWNlIA0KZnVuY3Rpb25pbnN0YW5jZT8NCj4gDQo+IFRoYW5rcywNCj4gQ2F0aHkNCj4g DQo+IEZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28u Y29tXSANCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAxOjA4IFBNDQo+IFRvOiBD YXRoeSBaaGFuZw0KPiBDYzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBSb24gUGFya2VyOyBt ZW5nLndlaTJAenRlLmNvbS5jbjsgUGF1bA0KPiBRdWlubiAocGF1bHEpOyBzZmM7IHNmY0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXF1aW5uLQ0KPiBzZmMtYXJjaC0wNC50eHQNCj4gDQo+IEhvdyB3b3VsZCB5b3Ug cmVwcmVzZW50IGFuIGluc3RhbmNlIG9mIGEgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZT8gDQo+ IFNlZW1zIG1vcmUgbG9naWNhbCB0byByZXByZXNlbnQgYSBzZXJ2aWNlIGZ1bmN0aW9uIHR5cGUg dGhhdCANCj4gcHJvdmlkZXMgZnVuY3Rpb24gYmFzZWQgb24gcG9saWN5IHNldCBhcyBhbiBpbmRl cGVuZGVudCBzZXJ2aWNlIA0KZnVuY3Rpb24uDQo+IA0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+ IA0KPiBPbiBGZWIgMTAsIDIwMTQsIGF0IDM6NTUgUE0sICJDYXRoeSBaaGFuZyIgPENhdGh5Lkgu WmhhbmdAaHVhd2VpLmNvbT4gDQp3cm90ZToNCj4gSSBzaGFyZSB0aGUgc2FtZSB2aWV3IGFzIFJl aW5hbGRvLiANCj4gSSB0aGluayBlYWNoIFNlcnZpY2UgRnVuY3Rpb24gaXMgYXNzb2NpYXRlZCB3 aXRoIGEgdHlwZSwgc3VjaCBhcyBGVyANCj4gU2VydmljZSBGdW5jdGlvbiBvciBOQVQgU2Vydmlj ZSBGdW5jdGlvbiANCj4gd2hpbGUgZWFjaCBTZXJ2aWNlIEluc3RhbmNlIGlzIGFuIGluc3RhbnRp YXRpb24gb2YgYSBTZXJ2aWNlIA0KPiBGdW5jdGlvbiBvbiBhIFNlcnZpY2UgTm9kZSBhbmQgaXMg IGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIHBvbGljeQ0KPiBwcm9maWxlL3NldCBvZiB0aGF0 IHR5cGUgb2YgU2VydmljZSBGdW5jdGlvbi4gDQo+IEluIGEgU0ZDIGFkbWluIGRvbWFpbiwgdGhl cmUgY291bGQgYmUgbXVsdGlwbGUgU2VydmljZSBOb2RlcyANCj4gKHBoeXNpY2FsL3ZpcnR1YWwp IHRoYXQgc3VwcG9ydCBhIHNwZWNpZmljIFNlcnZpY2UgRnVuY3Rpb24sIHN1Y2ggYXMgRlcsIA0K DQo+IGFuZCBhIHNlcnZpY2UgaW5zdGFuY2UgY291bGQgYmUgaW5zdGFudGlhdGVkIG9uIGFueSBv bmUgb2YgdGhlIA0KPiBTZXJ2aWNlIE5vZGVzIChhcyB0byB3aGljaCBTZXJ2aWNlIE5vZGUgdG8g aW5zdGFudGlhdGUgdGhlIHNlcnZpY2UgDQppbnN0YW5jZSwgDQo+IGl0IGRlcGVuZHMgb24gbG9h ZCBzdGF0dXMgb2YgdGhlIFNlcnZpY2UgTm9kZXMsIG5ldHdvcmsgcHJveGltaXR5IA0KPiBldGMu LCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUpIC4gDQo+IE11bHRpcGxlIGZsb3cgY2hhaW5zIGNhbiBi ZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgU2VydmljZSANCj4gSW5zdGFuY2Ugb24gYSBTZXJ2 aWNlIE5vZGUsIHdoaWNoIG1lYW5zIHRoZXNlIGZsb3dzIHdpbGwgYmUgYXBwbGllZCANCj4gdGhl IHNhbWUgcG9saWN5IHNldCANCj4gZm9yIHRoYXQgc3BlY2lmaWMgdHlwZSBvZiBzZXJ2aWNlIGZ1 bmN0aW9uLCBhcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIA0KZGlhZ3JhbS4NCj4gDQo+IEJUVywg SSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgZHJhZnQgYWRkcyBhIGRlZmluaXRpb24g Zm9yIA0KPiChsFNlcnZpY2UgSW5zdGFuY2WhsSB0byBicmluZyBldmVyeW9uZSBvbiB0aGUgc2Ft ZSBwYWdlIGFzIHRvIGl0cyANCnNlbWFudGljcy4gDQo+IA0KPiBUaGFua3MsDQo+IENhdGh5DQo+ IDxpbWFnZTAwMi5wbmc+DQo+IA0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJlaW5hbGRvIFBlbm5vIA0KKHJlcGVubm8pDQo+IFNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMTAsIDIwMTQgMTI6MjIgUE0NCj4gVG86IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBSb24gUGFya2VyOyBtZW5nLndlaTJAenRlLmNvbS5jbg0KPiBDYzogUGF1bCBRdWlu biAocGF1bHEpOyBzZmM7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLQ0KPiBzZmMtYXJjaC0wNC50 eHQNCj4gDQo+IEJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIEkgc2VlIHRoaXMgZGlmZmVyZW50bHku DQo+IA0KPiBUaGUgc2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGNvdWxkIGJlIGluc3RhbnRpYXRlZCB3 aXRoICBwb2xpY3ktc2V0LUEgDQo+IGFuZCBsYXRlciBpbnN0YW50aWF0ZWQgd2l0aCAgcG9saWN5 LXNldC1CLiBJdCBpcyBzdGlsbCB0aGUgc2FtZSANCj4gc2VydmljZSBmdW5jdGlvbiwgYnV0IGRp ZmZlcmVudCBpbnN0YW5jZXMuIA0KPiANCj4gVGhlcmVmb3JlIEkgd291bGQgY29uc2lkZXIgezEg YmVsb3d9IG9uZSBzZXJ2aWNlIGZ1bmN0aW9uIChzYXksIA0KPiBOQVQ0NCkgYW5kIHR3byBkaWZm ZXJlbnQgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMsIG9uZSB0aGF0IA0KPiBhcHBsaWVzICBw b2xpY3ktc2V0LUEgYW5kIG90aGVyIHRoYXQgYXBwbGllcyAgcG9saWN5LXNldC1BLg0KPiANCj4g RnJvbTogIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1aWNoYXJAY2lzY28uY29tPg0KPiBE YXRlOiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IGF0IDExOjEyIEFNDQo+IFRvOiBSb24gUGFy a2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiwgQ2lzY28gRW1wbG95ZWUgPA0K PiByZXBlbm5vQGNpc2NvLmNvbT4sICJtZW5nLndlaTJAenRlLmNvbS5jbiIgPG1lbmcud2VpMkB6 dGUuY29tLmNuPg0KPiBDYzogIlBhdWwgUXVpbm4gKHBhdWxxKSIgPHBhdWxxQGNpc2NvLmNvbT4s ICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmcNCj4gPiwgc2ZjIDxzZmMtYm91bmNlc0BpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1xdWlubi0NCj4gc2ZjLWFyY2gtMDQudHh0DQo+IA0KPiAxLiBBIHNlcnZpY2Ug ZnVuY3Rpb24gdGhhdCBhcHBsaWVzIHBvbGljeS1zZXQtQSBhbmQgYSBkaWZmZXJlbnQgDQo+IHNl cnZpY2UgZnVuY3Rpb24gdGhhdCBhcHBsaWVzIHBvbGljeS1zZXQtQiBlLmcuIFRoZXkgYXJlIHR3 byANCj4gZGlzdGluY3Qgc2VydmljZSBmdW5jdGlvbnMuDQo= --=_alternative 00354B0948257C7C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEppbSw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJbmxpbmUgd2l0aCBb TVddLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+V2VpIE1lbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mcXVvdDtKaW0gR3VpY2hhcmQgKGpndWljaGFyKSZxdW90OyAmbHQ7amd1aWNoYXJAY2lzY28u Y29tJmd0Ow0K0LTT2iAyMDE0LTAyLTExIDA3OjE3OjI3Ojxicj4NCjxicj4NCiZndDsgSGkgQ2F0 aHksPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbGV0 oa9zIHRha2UgdGhlIEZXIGV4YW1wbGUgd2l0aCBwb2xpY3ktc2V0LWEgYW5kIHBvbGljeS1zZXQt Yi4gSWYNCndlIDxicj4NCiZndDsgdHJlYXQgdGhlIEZXIGFzIGEgdHlwZSBvZiBzZXJ2aWNlIGZ1 bmN0aW9uIHdoZXJlIHBvbGljeS1zZXQtYSBhbmQNCjxicj4NCiZndDsgcG9saWN5LXNldC1iIGFy ZSBpbnN0YW5jZXMgb2YgdGhhdCChsHR5cGUmcXVvdDsgb2Ygc2VydmljZSBmdW5jdGlvbg0KdGhl biA8YnI+DQomZ3Q7IG15IHBvaW50IGlzIHRoYXQgZWFjaCBvZiB0aG9zZSBjb3VsZCBiZSBsb2Nh dGVkIGF0IG11bHRpcGxlIHBvaW50cw0KPGJyPg0KJmd0OyBpbiB0aGUgbmV0d29yayB0aGVyZWJ5 IGdpdmluZyB5b3UgbXVsdGlwbGUgobBpbnN0YW5jZXOhsSBvZiB0aGUNCjxicj4NCiZndDsgcG9s aWN5LXNldC1hIKGwaW5zdGFuY2WhsSBhbmQgdGhlIHBvbGljeS1zZXQtYiChsGluc3RhbmNlLiBJ IHdpbGwNCmFyZ3VlPGJyPg0KJmd0OyB0aGF0IHRoYXQgaXMgbm90IHRoZSByaWdodCB3YXkgdG8g bG9vayBhdCBpdC4uIExldCBtZSBleHBsYWluIG15IGxvZ2ljLjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IExldKGvcyB0YWtlIHRoZSBGVyBleGFtcGxl IGFnYWluLiBTdXBwb3NlIHRoYXQgSSBub3cgaGF2ZSBwb2xpY3ktc2V0oa88YnI+DQomZ3Q7IHMg YSxiLGMsICZhbXA7IGQuIExldHMgZnVydGhlciBzdXBwb3NlIHRoYXQgcG9saWN5LXNldKGvcyBh JmFtcDtiDQphcmUgPGJyPg0KJmd0OyBhdmFpbGFibGUgYXQgc2VydmljZSBub2RlcyAxLCAyLCAz ICZhbXA7IDQgYW5kIHBvbGljeS1zZXShr3MgYyZhbXA7ZA0KYXJlIDxicj4NCiZndDsgYXZhaWxh YmxlIGF0IHNlcnZpY2Ugbm9kZXMgNSwgNiAmYW1wOyA3LiBHaXZlbiB0aGlzLCB3aGVuIEkgaW5z dGFudGlhdGUNCjxicj4NCiZndDsgYW4gU0ZDIHRoYXQgcmVxdWlyZXMgc2F5IHBvbGljeS1zZXQt YSwgSSBjYW5ub3Qgc2VuZCB0aGUgdHJhZmZpYyB0bw0KPGJyPg0KJmd0OyBzZXJ2aWNlIG5vZGVz IDUsIDYgb3IgNyBhcyB0aGV5IHdpbGwgbm90IGhhdmUgdGhlIG5lY2Vzc2FyeSBwb2xpY3kNCjxi cj4NCiZndDsgdG8gdHJlYXQgdGhlIHRyYWZmaWMgZXZlbiB0aG91Z2ggd2UgaGF2ZSBzYWlkIHRo ZXkgYXJlIG9mIHRoZSBzYW1lDQo8YnI+DQomZ3Q7IHNlcnZpY2UgZnVuY3Rpb24gobB0eXBlJnF1 b3Q7LiBUaGlzIGdpdmVzIHVzIGEgZGlsZW1tYSB0aGF0IGNhbiBiZQ0KdGFja2xlZDxicj4NCiZn dDsgaW4gMSBvZiAzIHdheXMgaW1obzo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgMS4gSSBjb3VsZCBzcGxpdCB0aGVtIGludG8gMiBzZXBhcmF0ZSBzZXJ2aWNlDQpmdW5j dGlvbnM7IGxldKGvcyBjYWxsIDxicj4NCiZndDsgdGhlbSBGVyhhLGIpICZhbXA7IEZXKGMsZCku IE5vdyB0aGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGhhdCBub3cNCkkgaGF2ZTxicj4NCiZndDsg dG8gcmVseSB1cG9uIHRoZSBGVyBpdHNlbGYgdG8gZGV0ZXJtaW5lIHdoaWNoIG9mIHRoZSBwb2xp Y3ktc2V0oa9zDQp0bzxicj4NCiZndDsgYXBwbHkgdXNpbmcgc29tZSBvdXQtb2Ytc2NvcGUgZm9y IHRoZSBTRkMgV0cgbWVjaGFuaXNtLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgMi4gVG8gYXZvaWQgcmVjbGFzc2lmaWNhdGlvbiBhcyBpbmRpY2F0ZWQgaW4NCigxKSBJ IGNvdWxkIHNwbGl0IGVhY2ggPGJyPg0KJmd0OyBGVytwb2xpY3ktc2V0IGludG8gaXRzIG93biBk aXN0aW5jdCBzZXJ2aWNlIGZ1bmN0aW9uOyBGVyhhKSwgRlcoYiksDQo8YnI+DQomZ3Q7IEZXKGMp LCBhbmQgRlcoZCkuIFRoZSBwcm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IEkgY291bGQgZW5kIHVw IHdpdGgNCjxicj4NCiZndDsgYSBsYXJnZSBudW1iZXIgb2YgZGlzdGluY3Qgc2VydmljZSBmdW5j dGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bTVdd ICZxdW90O1RoZSBwcm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IEkgY291bGQgZW5kDQp1cCB3aXRo IGEgbGFyZ2UgbnVtYmVyPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vZiBkaXN0 aW5jdCBzZXJ2aWNlIGZ1bmN0aW9ucy4gJnF1b3Q7IEhvdyBsYXJnZSA/DQoxMDA/IDEwMDA/IEl0 IG1heSBiZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPndpdGhpbiBhY2NlcHRh YmxlIGxpbWl0cy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJz cDsgSXQgc2VlbXMgdG8gbWUgdGhhdCAmcXVvdDtzcGxpdGluZyBlYWNoDQpGVytwb2xpY3ktc2V0 IGludG8gaXRzIG93biBkaXN0aW5jdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ c2VydmljZSBmdW5jdGlvbiZxdW90OyBpcyBhIGNvbmNpc2Ugd2F5IHRvIGRlZmluZQ0Kc2Vydmlj ZSBmdW5jdGlvbi5GVyBPUiBOQVQgaXMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5qdXN0IHRoZSBzZXJ2aWNlIHR5cGUgcmF0aGVyIHRoYW4gc2VydmljZSBmdW5jdGlvbi4NCjwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyBJTU8s IHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBjb25maWd1cmVkDQomYW1wOyBkZXBsb3llZCBieSBvcGVy YXRvcnMuIFRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Z3JhbnVsYXJpdHkg Y291bGQgYmUgZGV0ZXJtaW5lZCBieSBvcGVyYXRvcnMgLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyBBY3R1YWxseSw8L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTI+IGdyYW51bGFyaXR5DQpvZiBTRnMgPC9mb250Pjx0dD48Zm9udCBzaXplPTI+aXMgdGhlIGJv bmUgb2Ygb3VyIGNvbnRlbnRpb24uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mbmJzcDsgJm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAzLiBJIGNvdWxkIGxldCB0aGUg U0ZDIHNlcnZpY2UgZW5jYXBzdWxhdGlvbg0KY2FycnkgZW5vdWdoIDxicj4NCiZndDsgaW5mb3Jt YXRpb24gZm9yIHRoZSBGVyB0byBkZXRlcm1pbmUgd2hpY2ggb2YgdGhlIHBvbGljeS1zZXShr3Mg YSxiLGMsPGJyPg0KJmd0OyBkIHRvIGFwcGx5IHRvIGEgZ2l2ZW4gZmxvdyB3aXRob3V0IG5lZWRp bmcgdG8gcmVjbGFzc2lmeSBhdCB0aGUgRlcNCm9yPGJyPg0KJmd0OyBzcGxpdCBhbGwgb2YgdGhl IEZXK3BvbGljeS1zZXQgY29tYmluYXRpb25zIGludG8gc2VwYXJhdGUgc2VydmljZQ0KPGJyPg0K Jmd0OyBmdW5jdGlvbnMuIEluIG90aGVyIHdvcmRzIEkgY291bGQgc2ltcGx5IGhhdmUgYSBzZXJ2 aWNlIGZ1bmN0aW9uIDxicj4NCiZndDsgd2l0aCB0eXBlIKGwRlehsSBhbmQgaW5kaWNhdGUgdGhl IHBvbGljeS1zZXQgd2l0aGluIHRoZSBzZXJ2aWNlDQplbmNhcHN1bGF0aW9uLjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEZvciBtZSBwb2ludCAoMykg aGlnaGxpZ2h0cyBwcmV0dHkgbmljZWx5IG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgPGJyPg0KJmd0 OyBoYXZpbmcgYW4gU0ZDIHNlcnZpY2UgZW5jYXBzdWxhdGlvbi48L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBGcm9tOiBDYXRoeSBaaGFuZyAmbHQ7Q2F0 aHkuSC5aaGFuZ0BodWF3ZWkuY29tJmd0Ozxicj4NCiZndDsgRGF0ZTogTW9uZGF5LCBGZWJydWFy eSAxMCwgMjAxNCBhdCA0OjIzIFBNPGJyPg0KJmd0OyBUbzogSmltIEd1aWNoYXJkICZsdDtqZ3Vp Y2hhckBjaXNjby5jb20mZ3Q7PGJyPg0KJmd0OyBDYzogJnF1b3Q7UmVpbmFsZG8gUGVubm8gKHJl cGVubm8pJnF1b3Q7ICZsdDtyZXBlbm5vQGNpc2NvLmNvbSZndDssDQpSb24gUGFya2VyICZsdDs8 YnI+DQomZ3Q7IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20mZ3Q7LCAmcXVvdDttZW5n LndlaTJAenRlLmNvbS5jbiZxdW90Ow0KJmx0O21lbmcud2VpMkB6dGUuY29tLmNuPGJyPg0KJmd0 OyAmZ3Q7LCBQYXVsIFF1aW5uICZsdDtwYXVscUBjaXNjby5jb20mZ3Q7LCBzZmMgJmx0O3NmYy1i b3VuY2VzQGlldGYub3JnJmd0OywNCiZxdW90O3NmY0BpZXRmLm9yZyZxdW90OyAmbHQ7PGJyPg0K Jmd0OyBzZmNAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW3NmY10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLTxicj4NCiZndDsgc2ZjLWFy Y2gtMDQudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn dDsgSGkgSmltLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ291bGQgeW91IGNsYXJpZnkg d2hhdCB5b3UgbWVhbiBieSBhbiBpbnN0YW5jZQ0Kb2YgYSBzZXJ2aWNlIGZ1bmN0aW9uaW5zdGFu Y2U/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGFua3MsPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENhdGh5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBG cm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0N Cjxicj4NCiZndDsgU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMCwgMjAxNCAxOjA4IFBNPGJyPg0K Jmd0OyBUbzogQ2F0aHkgWmhhbmc8YnI+DQomZ3Q7IENjOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u byk7IFJvbiBQYXJrZXI7IG1lbmcud2VpMkB6dGUuY29tLmNuOyBQYXVsPGJyPg0KJmd0OyBRdWlu biAocGF1bHEpOyBzZmM7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogUmU6IFtzZmNd IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1xdWlubi08YnI+DQomZ3Q7 IHNmYy1hcmNoLTA0LnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSG93IHdvdWxkIHlv dSByZXByZXNlbnQgYW4gaW5zdGFuY2Ugb2YgYSBzZXJ2aWNlDQpmdW5jdGlvbiBpbnN0YW5jZT8g PGJyPg0KJmd0OyBTZWVtcyBtb3JlIGxvZ2ljYWwgdG8gcmVwcmVzZW50IGEgc2VydmljZSBmdW5j dGlvbiB0eXBlIHRoYXQgPGJyPg0KJmd0OyBwcm92aWRlcyBmdW5jdGlvbiBiYXNlZCBvbiBwb2xp Y3kgc2V0IGFzIGFuIGluZGVwZW5kZW50IHNlcnZpY2UgZnVuY3Rpb24uPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFNlbnQgZnJvbSBteSBpUGhvbmU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBGZWIgMTAsIDIwMTQsIGF0IDM6NTUgUE0sICZxdW90O0Nh dGh5IFpoYW5nJnF1b3Q7ICZsdDtDYXRoeS5ILlpoYW5nQGh1YXdlaS5jb20mZ3Q7DQp3cm90ZTo8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSBzaGFyZSB0aGUgc2FtZSB2 aWV3IGFzIFJlaW5hbGRvLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg SSB0aGluayBlYWNoIFNlcnZpY2UgRnVuY3Rpb24gaXMgYXNzb2NpYXRlZCB3aXRoDQphIHR5cGUs IHN1Y2ggYXMgRlcgPGJyPg0KJmd0OyBTZXJ2aWNlIEZ1bmN0aW9uIG9yIE5BVCBTZXJ2aWNlIEZ1 bmN0aW9uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyB3aGlsZSBlYWNo IFNlcnZpY2UgSW5zdGFuY2UgaXMgYW4gaW5zdGFudGlhdGlvbg0Kb2YgYSBTZXJ2aWNlIDxicj4N CiZndDsgRnVuY3Rpb24gb24gYSBTZXJ2aWNlIE5vZGUgYW5kIGlzICZuYnNwO2Fzc29jaWF0ZWQg d2l0aCBhIHNwZWNpZmljDQpwb2xpY3k8YnI+DQomZ3Q7IHByb2ZpbGUvc2V0IG9mIHRoYXQgdHlw ZSBvZiBTZXJ2aWNlIEZ1bmN0aW9uLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgSW4gYSBTRkMgYWRtaW4gZG9tYWluLCB0aGVyZSBjb3VsZCBiZSBtdWx0aXBsZQ0KU2Vy dmljZSBOb2RlcyA8YnI+DQomZ3Q7IChwaHlzaWNhbC92aXJ0dWFsKSB0aGF0IHN1cHBvcnQgYSBz cGVjaWZpYyBTZXJ2aWNlIEZ1bmN0aW9uLCBzdWNoDQphcyBGVywgPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGFuZCBhIHNlcnZpY2UgaW5zdGFuY2UgY291bGQgYmUgaW5z dGFudGlhdGVkDQpvbiBhbnkgb25lIG9mIHRoZSA8YnI+DQomZ3Q7IFNlcnZpY2UgTm9kZXMgKGFz IHRvIHdoaWNoIFNlcnZpY2UgTm9kZSB0byBpbnN0YW50aWF0ZSB0aGUgc2VydmljZQ0KaW5zdGFu Y2UsIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBpdCBkZXBlbmRzIG9u IGxvYWQgc3RhdHVzIG9mIHRoZSBTZXJ2aWNlIE5vZGVzLA0KbmV0d29yayBwcm94aW1pdHkgPGJy Pg0KJmd0OyBldGMuLCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUpIC4gJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE11bHRpcGxlIGZsb3cgY2hhaW5zIGNhbiBiZSBh c3NvY2lhdGVkIHdpdGggdGhlDQpzYW1lIFNlcnZpY2UgPGJyPg0KJmd0OyBJbnN0YW5jZSBvbiBh IFNlcnZpY2UgTm9kZSwgd2hpY2ggbWVhbnMgdGhlc2UgZmxvd3Mgd2lsbCBiZSBhcHBsaWVkDQo8 YnI+DQomZ3Q7IHRoZSBzYW1lIHBvbGljeSBzZXQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IGZvciB0aGF0IHNwZWNpZmljIHR5cGUgb2Ygc2VydmljZSBmdW5jdGlvbiwg YXMNCnNob3duIGluIHRoZSBmb2xsb3dpbmcgZGlhZ3JhbS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IEJUVywgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgZHJhZnQgYWRkcw0K YSBkZWZpbml0aW9uIGZvciA8YnI+DQomZ3Q7IKGwU2VydmljZSBJbnN0YW5jZaGxIHRvIGJyaW5n IGV2ZXJ5b25lIG9uIHRoZSBzYW1lIHBhZ2UgYXMgdG8gaXRzDQpzZW1hbnRpY3MuIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhhbmtzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBDYXRoeTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bHQ7aW1hZ2UwMDIucG5nJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2YgUmVpbmFsZG8gUGVu bm8gKHJlcGVubm8pPGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDEwLCAyMDE0IDEy OjIyIFBNPGJyPg0KJmd0OyBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IFJvbiBQYXJrZXI7 IG1lbmcud2VpMkB6dGUuY29tLmNuPGJyPg0KJmd0OyBDYzogUGF1bCBRdWlubiAocGF1bHEpOyBz ZmM7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogUmU6IFtzZmNdIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1xdWlubi08YnI+DQomZ3Q7IHNmYy1hcmNoLTA0 LnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQmFzZWQgb24gdGhlIGRlZmluaXRpb24g SSBzZWUgdGhpcyBkaWZmZXJlbnRseS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoZSBz YW1lIHNlcnZpY2UgZnVuY3Rpb24gY291bGQgYmUgaW5zdGFudGlhdGVkDQp3aXRoICZuYnNwO3Bv bGljeS1zZXQtQSA8YnI+DQomZ3Q7IGFuZCBsYXRlciBpbnN0YW50aWF0ZWQgd2l0aCAmbmJzcDtw b2xpY3ktc2V0LUIuIEl0IGlzIHN0aWxsIHRoZSBzYW1lDQo8YnI+DQomZ3Q7IHNlcnZpY2UgZnVu Y3Rpb24sIGJ1dCBkaWZmZXJlbnQgaW5zdGFuY2VzLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFRoZXJlZm9yZSBJIHdvdWxkIGNvbnNpZGVyIHsxIGJlbG93fSBvbmUgc2VydmljZQ0KZnVu Y3Rpb24gKHNheSwgPGJyPg0KJmd0OyBOQVQ0NCkgYW5kIHR3byBkaWZmZXJlbnQgc2VydmljZSBm dW5jdGlvbiBpbnN0YW5jZXMsIG9uZSB0aGF0IDxicj4NCiZndDsgYXBwbGllcyAmbmJzcDtwb2xp Y3ktc2V0LUEgYW5kIG90aGVyIHRoYXQgYXBwbGllcyAmbmJzcDtwb2xpY3ktc2V0LUEuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiAmcXVvdDtKaW0gR3VpY2hhcmQgKGpndWljaGFy KSZxdW90OyAmbHQ7amd1aWNoYXJAY2lzY28uY29tJmd0Ozxicj4NCiZndDsgRGF0ZTogTW9uZGF5 LCBGZWJydWFyeSAxMCwgMjAxNCBhdCAxMToxMiBBTTxicj4NCiZndDsgVG86IFJvbiBQYXJrZXIg Jmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20mZ3Q7LCBDaXNjbyBFbXBsb3llZQ0K Jmx0Ozxicj4NCiZndDsgcmVwZW5ub0BjaXNjby5jb20mZ3Q7LCAmcXVvdDttZW5nLndlaTJAenRl LmNvbS5jbiZxdW90OyAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7PGJyPg0KJmd0OyBDYzog JnF1b3Q7UGF1bCBRdWlubiAocGF1bHEpJnF1b3Q7ICZsdDtwYXVscUBjaXNjby5jb20mZ3Q7LCAm cXVvdDtzZmNAaWV0Zi5vcmcmcXVvdDsNCiZsdDtzZmNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDss IHNmYyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTog W3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXF1aW5uLTxicj4N CiZndDsgc2ZjLWFyY2gtMDQudHh0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAxLiBBIHNl cnZpY2UgZnVuY3Rpb24gdGhhdCBhcHBsaWVzIHBvbGljeS1zZXQtQQ0KYW5kIGEgZGlmZmVyZW50 IDxicj4NCiZndDsgc2VydmljZSBmdW5jdGlvbiB0aGF0IGFwcGxpZXMgcG9saWN5LXNldC1CIGUu Zy4gVGhleSBhcmUgdHdvIDxicj4NCiZndDsgZGlzdGluY3Qgc2VydmljZSBmdW5jdGlvbnMuPC9m b250PjwvdHQ+DQo= --=_alternative 00354B0948257C7C_=-- From agoldner@allot.com Tue Feb 11 02:53:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFA91A07ED for ; Tue, 11 Feb 2014 02:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 CD89N5Trkhfo for ; Tue, 11 Feb 2014 02:53:01 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 08BBC1A06BF for ; Tue, 11 Feb 2014 02:53:00 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Tue, 11 Feb 2014 12:52:58 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 12:52:58 +0200 From: Alla Goldner To: "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPJwmwr4CF3fGr1U2UamRYQIgrPpqvxVzAgAAabLA= Date: Tue, 11 Feb 2014 10:52:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Tue, 11 Feb 2014 10:53:05 -0000 Dear Shucheng, With regard to this use case description, it would be useful, in my opini= on, referring to the existing 3GPP architecture as per 3GPP TS 23.203 whe= re Traffic Detection Function (TDF) is a standardized element residing on= =20Gi/SGi which implements DPI (detection) functionality along with enfor= cement and charging of the corresponding detected applications. This is m= issing from your use case description. I think such a comment was already= =20provided in a different email thread. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Tuesday, February 11, 2014 11:18 AM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-0= 1.txt Hi all, We've just updated our use case draft. The main change is in the section = of Use Case of Service Function Chain in Mobile Core Network. Looking for= ward to your comments. Regards, Shucheng (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, February 11, 2014 5:14 PM To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; Huang= yong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; Liu= shucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; Huangyong= =20(Oliver) Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfull= y submitted by Will(Shucheng) Liu and posted to the IETF repository. Name: draft-liu-sfc-use-cases Revision: 01 Title: Service Function Chaining (SFC) Use Cases Document date: 2014-02-11 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cas= es-01.txt Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/= Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-case= s-01 Abstract: =20 The delivery of value-added services relies on the invocation of =20 advanced Service Functions in a sequential order. This mechanism is= =20 called Service Function Chaining (SFC). The set of involved Service= =20 Functions and their order depends on the service context. =20 This document presents a set of use cases of Service Function =20 Chaining (SFC). =20 = =20 =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From jguichar@cisco.com Tue Feb 11 05:00:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFAD1A0086; Tue, 11 Feb 2014 05:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.449 X-Spam-Level: X-Spam-Status: No, score=-14.449 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_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXtFdHuDWEJ8; Tue, 11 Feb 2014 05:00:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 044B51A025E; Tue, 11 Feb 2014 05:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16202; q=dns/txt; s=iport; t=1392123628; x=1393333228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lKLkzNLg1702Or/hMeL2ZKoX+jvJxc6ZKXztqdrQ9Nc=; b=hOrk8UOjCnXq28AxH+mMUTBZs7OKDHaIYmnnbce/JhzsVpFf65Aowrp9 TWs3E4SnDpnh2sttCkvr0ms1P1nK1soZepDyMqN2oLRA9QE3wTdZSsaoP 9hVE1AHXPnlmAUspprI0aTQWl7VZReB7cqprR8zK6Oq6KkCBjhlpJO8YZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKIe+lKtJXHA/2dsb2JhbABZgww4vzyBDxZ0giUBAQEDAQEBAWsJAgULAgEIEQECAQEBAScHJwsUAwYIAgQOBYdxAwkIDcBGHYdVEwSORjMHAoMigRQBA5gqkiCDLQ X-IronPort-AV: E=Sophos;i="4.95,825,1384300800"; d="scan'208";a="303258934" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 11 Feb 2014 13:00:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1BD0MbD019061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 13:00:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 07:00:22 -0600 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" Thread-Topic: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt Thread-Index: AQHPJmiADi6TCMe7ZkKFCpVA1wN7eZqu+juA///xzICAAGcaAIAACXsA//+e1uyAAGj5gP//zAmAAAr0toAAAPQ7AAACWNAAAAPTwYAAAZ0PgAABXD0AAAWWw9U= Date: Tue, 11 Feb 2014 13:00:21 +0000 Message-ID: <5B2C12BA-F2FA-4E3F-B3F0-CB49A14BE8F7@cisco.com> References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> , <52F9A504.1090103@joelhalpern.com> In-Reply-To: <52F9A504.1090103@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sfc@ietf.org" , Cathy Zhang , sfc , "Paul Quinn \(paulq\)" , Ron Parker , "meng.wei2@zte.com.cn" , "Pham, Chuong D" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 13:00:52 -0000 I agree Joel; I tried to layout the options in previous emails and IMO all = options are valid and an implementer may do whichever they choose. Sent from my iPhone > On Feb 10, 2014, at 11:20 PM, "Joel M. Halpern" wro= te: >=20 > This seems to be a distinction which will be made differently in differen= t cases. We ought not mandate that there be different service instances fo= r different policies, but we also should not prohibit it. >=20 > The way we typically design IETF RFCs will lead naturally to the above re= sult. The general rule is taht as long as things interact properly, you ca= n do whatever you want. So one environment can have different service inst= ances, on different chains, for different policies. Another deployment may= have a collection of instances, each of which can apply all the policies, = and the collection may itself appear to service chaining as a single servic= e function instance (as long as the steering can steer traffic to it.) >=20 > Yours, > Joel >=20 >> On 2/10/14, 10:41 PM, Ron Parker wrote: >> Chuong, >>=20 >> The reason I used policy set was precisely as you described. Perhaps >> for tenant A there are a 1000 ACLs. For tenant B, there are also 1000 >> , but 100 are different. Just like in the 3gpp PCRF practical use >> cases, a "rulebase" is indicated for a subscriber, never the individual >> rules. In the case where there are relatively few distinct rulebases >> (perhaps the mythical gold silver and bronze users each receive distinct >> treatment), treating the sf function+rulebase as a distinct logical >> instance could simplify the overall service orchestration by >> concentrating the rulebase selection in one place. Another way to view >> this is that the policy may be evaluated at 2 levels -- first pick the >> set of classification rules using non-specified mechanisms, then apply >> the selected set of policy to the relevant traffic flows. Of course >> this 2 level approach would be optional. I'm not sure much needs to >> happen in the architecture except to ensure that multiple logical >> service functions, even of the same type, are allowed to have the same >> transport address (locator). >>=20 >> Ron >>=20 >>=20 >>=20 >> On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" >> > >> wrote: >>=20 >>> Ron, >>>=20 >>> I would just simply call the policy set =93policy=94 (the term used by = a >>> FW vendor we use in our network). There are many policies in the >>> firewall (1000=92s) of them. I don=92t think it is scalable for the >>> classifier to know all of these these policies. This would also >>> require integration between each firewall vendor and the classifier=92s >>> implementation for the two to understand the language. Note that a >>> flow may find matches among multiple policies and the policies can be >>> nested etc. What the classifier can do at a minimum is to have >>> information related to which FW SF (physical, logical or virtual) >>> should be included in the chain for a particular flow. If multiple FW >>> SFs i.e. multiple virtualised FWs hosting different sets of policies >>> designed for different tenant/networks reside at a same IP address >>> then I can see a benefit of the classifier to specify the correct >>> virtual firewall by name or similar semantics which is understood by >>> the front-end of the virtualised firewall SF complex. >>>=20 >>> In any case, pointing to the specific policies within the policies >>> configured on a FW (physical/logical/virtual) is not scalable or >>> workable, IMHO. >>>=20 >>> Regards, >>>=20 >>> Chuong >>>=20 >>> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> *Sent:* Tuesday, 11 February 2014 12:06 PM >>> *To:* Pham, Chuong D >>> *Cc:* Jim Guichard (jguichar); sfc@ietf.org ; >>> Cathy Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn >>> ; Reinaldo Penno (repenno) >>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> Chuong >>>=20 >>> A policy set is simply the configuration. What it means is service >>> function specific. For example, with NAT44, perhaps when some set of >>> clients access some particular remote subnet, they should be NAT'd >>> with a special pool of IP addresses, otherwise the generic pool of IP >>> addresses. But for some other set of clients, always use the generic >>> pool. This would be 2 policy sets (I'm open to better names for this)= . >>>=20 >>> Per our previous thread, you could chose to call this NAT44-A and >>> NAT44-B and create the classifier policy rules such that the correct >>> flows engage the correct chains and therefore the correct NAT >>> functionality. It may even be that both logical NAT instances are >>> located with the same transport address. >>>=20 >>> Or, you could 1/2 the number of distinct chains by requiring that the >>> NAT44 decide on its own, without an assist from the classifier, when >>> to use the special pool. >>>=20 >>> I believe that both use cases are entirely valid and both should be >>> supported. >>>=20 >>> Ron >>>=20 >>>=20 >>> On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" >>> >> > wrote: >>>=20 >>> What is a policy set? Is it a virtual/logical firewall? Or is it >>> what policies to apply to a traffic flow? >>>=20 >>> In any case, in approach 3, the classifier would need to know >>> which FW owns which policy sets anyway unless the idea is having >>> only one FW SF with all the policy sets in it. If the classifier >>> needs to know the individual FW SFs, I think approach 1 and 2 in >>> combination is more practical. >>>=20 >>> Effectively, there will be FW SF1, SF2=85SFn in a network, depends >>> on the need of that network. A FW SF may host multiple policy >>> sets. It=92s the local choice and in this case, the FW will need to >>> decide which policy set to use, just like the way it does today. >>>=20 >>> Regards, >>>=20 >>> Chuong >>>=20 >>> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> *Sent:* Tuesday, 11 February 2014 10:31 AM >>> *To:* Jim Guichard (jguichar) >>> *Cc:* sfc@ietf.org ; Cathy Zhang; sfc; Paul >>> Quinn (paulq); meng.wei2@zte.com.cn ; >>> Reinaldo Penno (repenno) >>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> Approach 3 is the most elegant, but also the most costly in terms >>> of the service header. Rather than deriving both sequence and >>> policy selection from the chain id that presumably appears in the >>> service header, we would now need a stack of policy set >>> identifiers that is pushed on by the classifier -- one for each >>> service function in the chain. >>>=20 >>> Ron >>>=20 >>>=20 >>> On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" >>> > wrote: >>>=20 >>> Hi Cathy, >>>=20 >>> let=92s take the FW example with policy-set-a and policy-set-b. >>> If we treat the FW as a type of service function where >>> policy-set-a and policy-set-b are instances of that =93type" of >>> service function then my point is that each of those could be >>> located at multiple points in the network thereby giving you >>> multiple =93instances=94 of the policy-set-a =93instance=94 and = the >>> policy-set-b =93instance. I will argue that that is not the >>> right way to look at it.. Let me explain my logic. >>>=20 >>> Let=92s take the FW example again. Suppose that I now have >>> policy-set=92s a,b,c, & d. Lets further suppose that >>> policy-set=92s a&b are available at service nodes 1, 2, 3 & 4 >>> and policy-set=92s c&d are available at service nodes 5, 6 & 7. >>> Given this, when I instantiate an SFC that requires say >>> policy-set-a, I cannot send the traffic to service nodes 5, 6 >>> or 7 as they will not have the necessary policy to treat the >>> traffic *even though* we have said they are of the same >>> service function =93type". This gives us a dilemma that can be >>> tackled in 1 of 3 ways imho: >>>=20 >>> 1. I could split them into 2 separate service functions; >>> let=92s call them FW(a,b) & FW(c,d). Now the problem with >>> this is that now I have to rely upon the FW itself to >>> determine which of the policy-set=92s to apply using some >>> out-of-scope for the SFC WG mechanism. >>> 2. To avoid reclassification as indicated in (1) I could >>> split each FW+policy-set into its own distinct service >>> function; FW(a), FW(b), FW(c), and FW(d). The problem with >>> this is that I could end up with a large number of >>> distinct service functions. >>> 3. I could let the SFC service encapsulation carry enough >>> information for the FW to determine which of the >>> policy-set=92s a,b,c,d to apply to a given flow >>> *without* needing to reclassify at the FW *or* split all >>> of the FW+policy-set combinations into separate service >>> functions. In other words I could simply have a service >>> function with type =93FW=94 and indicate the policy-set with= in >>> the service encapsulation. >>>=20 >>> For me point (3) highlights pretty nicely one of the reasons >>> for having an SFC service encapsulation. >>>=20 >>> *From: *Cathy Zhang >> > >>> *Date: *Monday, February 10, 2014 at 4:23 PM >>> *To: *Jim Guichard >> > >>> *Cc: *"Reinaldo Penno (repenno)" >> >, Ron Parker >>> >> >, >>> "meng.wei2@zte.com.cn " >>> >, Paul >>> Quinn >, sfc >>> >, >>> "sfc@ietf.org " >> > >>> *Subject: *RE: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> Hi Jim, >>>=20 >>> Could you clarify what you mean by an instance of a service >>> function instance? >>>=20 >>> Thanks, >>>=20 >>> Cathy >>>=20 >>> *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> *Sent:* Monday, February 10, 2014 1:08 PM >>> *To:* Cathy Zhang >>> *Cc:* Reinaldo Penno (repenno); Ron Parker; >>> meng.wei2@zte.com.cn ; Paul Quinn >>> (paulq); sfc; sfc@ietf.org >>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> How would you represent an instance of a service function >>> instance? Seems more logical to represent a service function >>> type that provides function based on policy set as an >>> independent service function. >>>=20 >>> Sent from my iPhone >>>=20 >>>=20 >>> On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" >>> > >>> wrote: >>>=20 >>> I share the same view as Reinaldo. >>>=20 >>> I think each Service Function is associated with a type, >>> such as FW Service Function or NAT Service Function >>>=20 >>> while each Service Instance is an instantiation of a >>> Service Function on a Service Node and is associated with >>> a specific policy profile/set of that type of Service >>> Function. >>>=20 >>> In a SFC admin domain, there could be multiple Service >>> Nodes (physical/virtual) that support a specific Service >>> Function, such as FW, >>>=20 >>> and a service instance could be instantiated on any one of >>> the Service Nodes (as to which Service Node to instantiate >>> the service instance, >>>=20 >>> it depends on load status of the Service Nodes, network >>> proximity etc., which is out of scope) . >>>=20 >>> Multiple flow chains can be associated with the same >>> Service Instance on a Service Node, which means these >>> flows will be applied the same policy set >>>=20 >>> for that specific type of service function, as shown in >>> the following diagram. >>>=20 >>> BTW, I would like to suggest that the draft adds a >>> definition for =93Service Instance=94 to bring everyone on t= he >>> same page as to its semantics. >>>=20 >>> Thanks, >>>=20 >>> Cathy >>>=20 >>> >>>=20 >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>> *Reinaldo Penno (repenno) >>> *Sent:* Monday, February 10, 2014 12:22 PM >>> *To:* Jim Guichard (jguichar); Ron Parker; >>> meng.wei2@zte.com.cn >>> *Cc:* Paul Quinn (paulq); sfc; sfc@ietf.org >>> >>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> Based on the definition I see this differently. >>>=20 >>> The same service function could be instantiated with >>> policy-set-A and later instantiated with policy-set-B. >>> It is still the same service function, but different >>> instances. >>>=20 >>> Therefore I would consider {1 below} one service function >>> (say, NAT44) and two different service function instances, >>> one that applies policy-set-A and other that applies >>> policy-set-A. >>>=20 >>> *From: *"Jim Guichard (jguichar)" >> > >>> *Date: *Monday, February 10, 2014 at 11:12 AM >>> *To: *Ron Parker >> >, Cisco Employee >>> >, >>> "meng.wei2@zte.com.cn " >>> > >>> *Cc: *"Paul Quinn (paulq)" >> >, "sfc@ietf.org >>> " >> >, sfc >> > >>> *Subject: *Re: [sfc] Fwd: New Version Notification for >>> draft-quinn-sfc-arch-04.txt >>>=20 >>> 1. A service function that applies policy-set-A and a >>> different service function that applies policy-set-B >>> e.g. They are two distinct service functions. >>>=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 From jguichar@cisco.com Tue Feb 11 07:34:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E251A050B for ; Tue, 11 Feb 2014 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3BiDqu0j9aN for ; Tue, 11 Feb 2014 07:34:23 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 2368A1A0502 for ; Tue, 11 Feb 2014 07:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2987; q=dns/txt; s=iport; t=1392132863; x=1393342463; h=from:to:cc:subject:date:message-id:mime-version; bh=FpTuwDO6dgsi28e8247dppvaY+chKE2zK0+frsGTtS4=; b=YPiPTg6LIa+gzdkxQpNElS4kKzbnPhkd7HnADYJ17bkzF9AohiCJkSF/ G+ESQpFpU8Hg5V53aMPAFGTdcdY2vURhqJqTuxwxEdC0jOdCOqSAVagJa o+H/u7It66udw45eFpt9YLq/0eVaO8Dk5X9VPregTCghGT6GO96I1g7cH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADxC+lKtJXHA/2dsb2JhbABagkhEgQ++ZoESFnSCLHkSAQx0JwQBDYgKyE4XjiVUhD8EmCqSIIMtgio X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208,217";a="19574409" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-8.cisco.com with ESMTP; 11 Feb 2014 15:34:22 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1BFYMFM022177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 15:34:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 09:34:22 -0600 From: "Jim Guichard (jguichar)" To: "Paul Quinn (paulq)" , Thomas Nadeau Thread-Topic: draft-ietf-sfc-problem-statement-00 Thread-Index: AQHPJz67kdfxoTZBCkqpBOKtO9B51A== Date: Tue, 11 Feb 2014 15:34:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.188] Content-Type: multipart/alternative; boundary="_000_CF1FAD2815496jguicharciscocom_" MIME-Version: 1.0 Cc: "sfc@ietf.org" Subject: [sfc] draft-ietf-sfc-problem-statement-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:34:25 -0000 --_000_CF1FAD2815496jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul/Thomas, Looking towards London, we would like the WG to close on the problem statem= ent as documented in draft-ietf-sfc-problem-statement-00 ASAP and ship it t= o the IESG. This is consistent with our charter, which has a milestone of A= pril for doing this. What do we need to do this? Per previous discussion, there seems to be agreement to eliminate the use c= ase section. One part is TBD, and the other part looks like it will be migr= ating into draft-liu-sfc-use-cases. Are there any other outstanding issues that you know of? Do you have any ot= her TODOs that you know of (e.g., comments from the WG?). Can you get a rev= ised ID out by the cutoff? It would be great if the London slot on this doc= ument was able to say there were no known issues and that the document is r= eady for WGLC. WG: Do you know of any gaps or other issues with the problem statement? If = so, can we get them flushed out on the list prior to London? Jim & Thomas --_000_CF1FAD2815496jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <721BC1D06334AB459D0547FFDFE4F7AE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Paul/Thomas,

Looking towards London, we would like the WG to close on the problem s= tatement as documented in draft-ietf-sfc-problem-statement-00 ASAP and ship= it to the IESG. This is consistent with our charter, which has a milestone= of April for doing this. 

What do we need to do this?

Per previous discussion, there seems to be agreement to eliminate the = use case section. One part is TBD, and the other part looks like it will be= migrating into draft-liu-sfc-use-cases. 

Are there any other outstanding issues that you know of? Do you have a= ny other TODOs that you know of (e.g., comments from the WG?). Can you get = a revised ID out by the cutoff? It would be great if the London slot on thi= s document was able to say there were no known issues and that the document is ready for WGLC. 

WG: Do you know of any gaps or other issues with the problem statement= ? If so, can we get them flushed out on the list prior to London?

Jim & Thomas



--_000_CF1FAD2815496jguicharciscocom_-- From tnadeau@lucidvision.com Tue Feb 11 07:52:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42391A0308 for ; Tue, 11 Feb 2014 07:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 12ZuZvElt0Lz for ; Tue, 11 Feb 2014 07:52:50 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 43B781A05D7 for ; Tue, 11 Feb 2014 07:52:50 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A6E6626E9DB2; Tue, 11 Feb 2014 10:52:49 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_B6B7A784-F6F5-483A-BAD6-B2A1CDB75537"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 11 Feb 2014 10:52:48 -0500 Message-Id: References: To: Guichard Jim X-Mailer: Apple Mail (2.1827) Cc: "Paul \(paulq\) Quinn" , "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-problem-statement-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:52:52 -0000 --Apple-Mail=_B6B7A784-F6F5-483A-BAD6-B2A1CDB75537 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B164322-B1B4-4070-A67F-4AE4F2479164" --Apple-Mail=_5B164322-B1B4-4070-A67F-4AE4F2479164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 11, 2014:10:34 AM, at 10:34 AM, Jim Guichard (jguichar) = wrote: > Hi Paul/Thomas, >=20 > Looking towards London, we would like the WG to close on the problem = statement as documented in draft-ietf-sfc-problem-statement-00 ASAP and = ship it to the IESG. This is consistent with our charter, which has a = milestone of April for doing this.=20 >=20 > What do we need to do this? >=20 > Per previous discussion, there seems to be agreement to eliminate the = use case section. One part is TBD, and the other part looks like it will = be migrating into draft-liu-sfc-use-cases.=20 Yes, we have already made this change. > Are there any other outstanding issues that you know of? Do you have = any other TODOs that you know of (e.g., comments from the WG?). Can you = get a revised ID out by the cutoff? It would be great if the London slot = on this document was able to say there were no known issues and that the = document is ready for WGLC.=20 There are a few comments from myself and Ken Gray that need to = be added to the next revision.=20 > WG: Do you know of any gaps or other issues with the problem = statement? If so, can we get them flushed out on the list prior to = London? Not that we know of.=20 We will turn around a new revision by the end of this week. --Tom >=20 > Jim & Thomas >=20 >=20 >=20 --Apple-Mail=_5B164322-B1B4-4070-A67F-4AE4F2479164 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Feb 11, 2014:10:34 AM, at 10:34 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Hi Paul/Thomas,

Looking towards London, we would like the WG to close on the problem statement as documented in draft-ietf-sfc-problem-statement-00 ASAP and ship it to the IESG. This is consistent with our charter, which has a milestone of April for doing this. 

What do we need to do this?

Per previous discussion, there seems to be agreement to eliminate the use case section. One part is TBD, and the other part looks like it will be migrating into draft-liu-sfc-use-cases. 

Yes, we have already made this change.

Are there any other outstanding issues that you know of? Do you have any other TODOs that you know of (e.g., comments from the WG?). Can you get a revised ID out by the cutoff? It would be great if the London slot on this document was able to say there were no known issues and that the document is ready for WGLC. 

There are a few comments from myself and Ken Gray that need to be added to the next revision. 

WG: Do you know of any gaps or other issues with the problem statement? If so, can we get them flushed out on the list prior to London?

Not that we know of. 

We will turn around a new revision by the end of this week.

--Tom



Jim & Thomas




--Apple-Mail=_5B164322-B1B4-4070-A67F-4AE4F2479164-- --Apple-Mail=_B6B7A784-F6F5-483A-BAD6-B2A1CDB75537 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+kdQAAoJEPcO+I7eiUJZDDoP/2jrFX1VMUwCmYvsIzYcZ40D hVM0IcUcE6Kl0t/+tAL1SwpIxnDdhZMpKnW1Beo4jOTWPEstZSWyiT0IFM++OaAO oQFTz6KwV2mPrQPkroXn1X3GOQRhqeW8nDEVisaEb7S8HkXBcv1cGxiOQp6cdiuA jYJKBiiVt1/gLqzeFaTZhntf58iS3u3sN/S9rmkB0cCPb4nFKQSPcUfs9FuR52Nn lMuDot05ysmrEVMBnSlp/VqZc8Tec573Ob9kEmGHKgL2vTHeH5JCO7B0GrYtU1tU JOAFm1Tlfirk01YcHJSNWisR4KcMjbWjgnt5LYR++cUteiTIQq9T/vmB/BeH7JNe jr749z82PgLGB4ZpgIcoyuovN1Vq6n7T6Kj9FpyFi/VyYxksNdSDI4ELjR9RmOrp c3hPvqQGhKsaenEXRsIdC6EdiSYKFuaaW6ffpJWnxvlm381uQUQwFBnm9oThTA5Q 5573TtIma7Q1GLnauHOj3ZL3UJRzgQOp6VrTLTJTK8d4s967hF03BiewMVh+aVfh rQWkCH7d91DRywaEq8vXKd2U2AEmUeQ5NqvOaSALsRTwSPLiGU0bke4ylnp47Rc1 jKQVuqUO86Ef0LZVo0BZh+zi6MuvJW+xPVPlWE9MGOjJYQnYaDpXjTK5jN+SxPHV Ke1guic5IOE01bjcqfK5 =sLd1 -----END PGP SIGNATURE----- --Apple-Mail=_B6B7A784-F6F5-483A-BAD6-B2A1CDB75537-- From smkumar@cisco.com Tue Feb 11 17:40:01 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B7C1A02CA for ; Tue, 11 Feb 2014 17:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9dMMvxrgN4J for ; Tue, 11 Feb 2014 17:39:59 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2F1A0033 for ; Tue, 11 Feb 2014 17:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1613; q=dns/txt; s=iport; t=1392169199; x=1393378799; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bmq37BOTJkCQNAC4TW7sEiZTr62zzR5MCqy8wCGbaMQ=; b=Of8ukqhOIVdx9rCVnlflP1PcwshpMuNAKCQSotWnydyR/6IaPa5NdcAE kWgh46DBEQnB04Ah1GYSIGMERNelGKloiqeFpgwI2Tk44711vPyo332rV enNj2u8IQiLMmCOQRntnH7wZ3y+K7dwkrI65Lr8L9SGUsnQkOg1yZbh8M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAL7P+lKtJXG8/2dsb2JhbABagww4V78hgRYWdIIlAQEBBDo9EgIBCDYQMhsBBgMCBAESCYd7AQ3KFBeOJVuEOASYKoEykG6DLYIq X-IronPort-AV: E=Sophos;i="4.95,829,1384300800"; d="scan'208";a="19732662" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 12 Feb 2014 01:39:58 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1C1dwUK016937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 01:39:58 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 19:39:57 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" , Thomas Narten , "Jim Guichard (jguichar)" Thread-Topic: New Version Notification for draft-kumar-sfc-dc-use-cases-00.txt Thread-Index: AQHPJ49cX++8n686NUqwcPNsEHhKfZqwtgQA Date: Wed, 12 Feb 2014 01:39:57 +0000 Message-ID: References: <20140212011124.30835.39925.idtracker@ietfa.amsl.com> In-Reply-To: <20140212011124.30835.39925.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.3.9.131030 x-originating-ip: [171.71.15.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <82F1BB8226431F4686F89F9C3BD65727@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-dc-use-cases-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 01:40:01 -0000 Hi folks, I uploaded a new draft specifically on DC use cases. Look forward to the your comments. Jim/Thomas, I would like to a slot in London for this. Thanks, Surendra. On 2/11/14 5:11 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kumar-sfc-dc-use-cases-00.txt >has been successfully submitted by Surendra Kumar and posted to the >IETF repository. > >Name: draft-kumar-sfc-dc-use-cases >Revision: 00 >Title: Service Function Chaining Use Cases In Data Centers >Document date: 2014-02-11 >Group: Individual Submission >Pages: 16 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kumar-sfc-dc-use-cases-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-kumar-sfc-dc-use-cases-00 > > >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. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From Chuong.D.Pham@team.telstra.com Tue Feb 11 17:59:07 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F201A079E for ; Tue, 11 Feb 2014 17:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rrDKAog7SmO for ; Tue, 11 Feb 2014 17:59:04 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 30E7C1A0795 for ; Tue, 11 Feb 2014 17:59:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,829,1384261200"; d="scan'208";a="172407428" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Feb 2014 12:59:01 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7346"; a="154314281" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdni.tcif.telstra.com.au with ESMTP; 12 Feb 2014 12:58:41 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 12 Feb 2014 12:58:41 +1100 From: "Pham, Chuong D" To: Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Wed, 12 Feb 2014 12:58:40 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8nPsI8wx0hXPcgRj6Hybf/H728gQAVehGQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 01:59:07 -0000 Hi Liushucheng, There is also the case where a service function is selected based on user s= ubscription. For example, steering traffic to a Parental Control (PC) only = for the flows belonging to users who have PC subscription. One way of doing= it is for the PCRF to notify the classifier about the correct flows to exp= ect prior to the arrival of these flows.=20 Other example is steering traffic to a DPI based on users with QoS subscrip= tions for the purpose of reporting and optionally enforcement. Another example is when a user wants to opt-out of service functions such a= s an Operator-mandate video optimisation platform for reasons such as the u= ser is a Gold user with QoS and requirements for high resolution video. To me, user subscription based traffic steering/servicing chaining is impor= tant for Mobile and at the same time, it poses great challenge on scalabili= ty therefore it is worthwhile to be included in your draft. Regards, Chuong -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com]=20 Sent: Tuesday, 11 February 2014 9:53 PM To: Liushucheng (Will); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Shucheng, With regard to this use case description, it would be useful, in my opinion= , referring to the existing 3GPP architecture as per 3GPP TS 23.203 where T= raffic Detection Function (TDF) is a standardized element residing on Gi/SG= i which implements DPI (detection) functionality along with enforcement and= charging of the corresponding detected applications. This is missing from = your use case description. I think such a comment was already provided in a= different email thread. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Tuesday, February 11, 2014 11:18 AM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.= txt Hi all, We've just updated our use case draft. The main change is in the section of= Use Case of Service Function Chain in Mobile Core Network. Looking forward= to your comments. Regards, Shucheng (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Tuesday, February 11, 2014 5:14 PM To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; Huangyo= ng (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; Liushuc= heng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; Huangyong (Oliv= er) Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfully = submitted by Will(Shucheng) Liu and posted to the IETF repository. Name: draft-liu-sfc-use-cases Revision: 01 Title: Service Function Chaining (SFC) Use Cases Document date: 2014-02-11 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases= -01.txt Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-= 01 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### From mohamed.boucadair@orange.com Wed Feb 12 01:22:47 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DE91A08C8 for ; Wed, 12 Feb 2014 01:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bGRRSNDd8VWm for ; Wed, 12 Feb 2014 01:22:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id EEFCD1A08C2 for ; Wed, 12 Feb 2014 01:22:44 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 00C351B857E; Wed, 12 Feb 2014 10:22:43 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D010D384057; Wed, 12 Feb 2014 10:22:42 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 12 Feb 2014 10:22:42 +0100 From: To: "Pham, Chuong D" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Wed, 12 Feb 2014 10:22:41 +0100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8nPsI8wx0hXPcgRj6Hybf/H728gQAVehGQAA+ZyCA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 09:22:47 -0000 Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 >=C0=A0: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Objet=A0: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es- >01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on user >subscription. For example, steering traffic to a Parental Control (PC) onl= y >for the flows belonging to users who have PC subscription. One way of doin= g >it is for the PCRF to notify the classifier about the correct flows to >expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions such >as an Operator-mandate video optimisation platform for reasons such as the >user is a Gold user with QoS and requirements for high resolution video. > >To me, user subscription based traffic steering/servicing chaining is >important for Mobile and at the same time, it poses great challenge on >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my >opinion, referring to the existing 3GPP architecture as per 3GPP TS 23.203 >where Traffic Detection Function (TDF) is a standardized element residing >on Gi/SGi which implements DPI (detection) functionality along with >enforcement and charging of the corresponding detected applications. This >is missing from your use case description. I think such a comment was >already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel +97= 2 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the section o= f >Use Case of Service Function Chain in Mobile Core Network. Looking forward >to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; >Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfully >submitted by Will(Shucheng) Liu and posted to the IETF repository. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Wed Feb 12 01:49:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5F1A08F3 for ; Wed, 12 Feb 2014 01:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yGLpGNswgbiV for ; Wed, 12 Feb 2014 01:49:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3261A08E1 for ; Wed, 12 Feb 2014 01:49:30 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 20D022AC815 for ; Wed, 12 Feb 2014 10:49:29 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0AD00384081 for ; Wed, 12 Feb 2014 10:49:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 12 Feb 2014 10:49:29 +0100 From: To: "sfc@ietf.org" Date: Wed, 12 Feb 2014 10:49:27 +0100 Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> In-Reply-To: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 12 Feb 2014 09:49:31 -0000 Dear all, This new version integrates inputs from NTT representatives.=20 The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=3Ddraft-bouc= adair-sfc-requirements-01&difftype=3D--html&submit=3DGo!&url2=3Ddraft-bouca= dair-sfc-requirements-03=20 Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 12 f=E9vrier 2014 10:46 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-requirements-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining Authors : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Kengo Naito Filename : draft-boucadair-sfc-requirements-03.txt Pages : 14 Date : 2014-02-12 Abstract: This document identifies the requirements for the Service Function Chaining (SFC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mohamed.boucadair@orange.com Wed Feb 12 07:01:33 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC421A03B4 for ; Wed, 12 Feb 2014 07:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qKpJ0qlxk50f for ; Wed, 12 Feb 2014 07:01:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 42C781A0310 for ; Wed, 12 Feb 2014 07:01:31 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 97D0D2AC920 for ; Wed, 12 Feb 2014 16:01:29 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 81FCFC80A0 for ; Wed, 12 Feb 2014 16:01:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 12 Feb 2014 16:01:29 +0100 From: To: "sfc@ietf.org" Date: Wed, 12 Feb 2014 16:01:28 +0100 Thread-Topic: I-D Action: draft-boucadair-sfc-framework-01.txt Thread-Index: Ac8oAttLoJSqEEI8SUmdY6avvgQzrwAAEBTA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4BFE3E32@PUEXCB1B.nanterre.francetelecom.fr> References: <20140212145734.7101.97926.idtracker@ietfa.amsl.com> In-Reply-To: <20140212145734.7101.97926.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-framework-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: Wed, 12 Feb 2014 15:01:33 -0000 Dear all, A new version of this draft is available online. This version integrates co= mments received from L. Dunbar and R. White.=20 Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 12 f=E9vrier 2014 15:58 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-framework-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining: Framework & Architectu= re Authors : Mohamed Boucadair Christian Jacquenet Ron Parker Diego R. Lopez Jim Guichard Carlos Pignataro Filename : draft-boucadair-sfc-framework-01.txt Pages : 25 Date : 2014-02-12 Abstract: IP networks rely more and more on the combination of advanced functions (besides the basic routing and forwarding functions) for the delivery of added value services. This document defines a reference architecture and a framework to enforce Service Function Chaining (SFC) with minimum requirements on the physical topology of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-sfc-framework-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-framework-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jmh@joelhalpern.com Wed Feb 12 08:20:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CD51A0974 for ; Wed, 12 Feb 2014 08:20:11 -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 K5VZE2Fy20ha for ; Wed, 12 Feb 2014 08:20:02 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 198CC1A0458 for ; Wed, 12 Feb 2014 08:19:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8E4413A09BB for ; Wed, 12 Feb 2014 08:19:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 237413A09B7 for ; Wed, 12 Feb 2014 08:19:57 -0800 (PST) Message-ID: <52FB9F32.4000005@joelhalpern.com> Date: Wed, 12 Feb 2014 11:20:02 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:20:12 -0000 I was looking at the framework proposal. The proposal has a very specific model of the scope of the transport header (that it is derived from, and relates only to, the first service function to which the packet will be directed. That is clearly an operational model we need to support. However, I would like to allow other transport operational models, such as the use of a VLAN to direct traffic along a chain. Or the use of an MPLS label, or an MPLS label stack. Yours, Joel M. Halpern From jmh@joelhalpern.com Wed Feb 12 08:35:30 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B31A0473 for ; Wed, 12 Feb 2014 08:35:30 -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_21=0.6, 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 xWettg8O1mzb for ; Wed, 12 Feb 2014 08:35:27 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E51A03B4 for ; Wed, 12 Feb 2014 08:35:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BD6233A0C14 for ; Wed, 12 Feb 2014 08:35:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 54E263A0C1E for ; Wed, 12 Feb 2014 08:35:24 -0800 (PST) Message-ID: <52FBA2D1.1010801@joelhalpern.com> Date: Wed, 12 Feb 2014 11:35:29 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: , <31B7FA43-FC33-419C-B020-DD810B80CAB8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7C8C0@WSMSG3154V.srv.dir.telstra.com> <2A715232-CE76-4378-A250-79D620AA4DE8@affirmednetworks.com>, <5602569641FB314FB4D9AD5659D41B9C2983B7CD5E@WSMSG3154V.srv.dir.telstra.com> , <52F9A504.1090103@joelhalpern.com> <5B2C12BA-F2FA-4E3F-B3F0-CB49A14BE8F7@cisco.com> In-Reply-To: <5B2C12BA-F2FA-4E3F-B3F0-CB49A14BE8F7@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-04.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, 12 Feb 2014 16:35:30 -0000 Thank you Jim. If folks think that the definitions in the archtiecture document (or any of our other documents) prohibit this degree of flexibility, then I would suggest that we fix the definitions. For me, this seems to be supported by the definitions we are using. Yours, Joel On 2/11/14, 8:00 AM, Jim Guichard (jguichar) wrote: > I agree Joel; I tried to layout the options in previous emails and > IMO all options are valid and an implementer may do whichever they > choose. > > Sent from my iPhone > >> On Feb 10, 2014, at 11:20 PM, "Joel M. Halpern" >> wrote: >> >> This seems to be a distinction which will be made differently in >> different cases. We ought not mandate that there be different >> service instances for different policies, but we also should not >> prohibit it. >> >> The way we typically design IETF RFCs will lead naturally to the >> above result. The general rule is taht as long as things interact >> properly, you can do whatever you want. So one environment can >> have different service instances, on different chains, for >> different policies. Another deployment may have a collection of >> instances, each of which can apply all the policies, and the >> collection may itself appear to service chaining as a single >> service function instance (as long as the steering can steer >> traffic to it.) >> >> Yours, Joel >> >>> On 2/10/14, 10:41 PM, Ron Parker wrote: Chuong, >>> >>> The reason I used policy set was precisely as you described. >>> Perhaps for tenant A there are a 1000 ACLs. For tenant B, there >>> are also 1000 , but 100 are different. Just like in the 3gpp >>> PCRF practical use cases, a "rulebase" is indicated for a >>> subscriber, never the individual rules. In the case where there >>> are relatively few distinct rulebases (perhaps the mythical gold >>> silver and bronze users each receive distinct treatment), >>> treating the sf function+rulebase as a distinct logical instance >>> could simplify the overall service orchestration by concentrating >>> the rulebase selection in one place. Another way to view this >>> is that the policy may be evaluated at 2 levels -- first pick >>> the set of classification rules using non-specified mechanisms, >>> then apply the selected set of policy to the relevant traffic >>> flows. Of course this 2 level approach would be optional. I'm >>> not sure much needs to happen in the architecture except to >>> ensure that multiple logical service functions, even of the same >>> type, are allowed to have the same transport address (locator). >>> >>> Ron >>> >>> >>> >>> On Feb 10, 2014, at 9:55 PM, "Pham, Chuong D" >>> >> > wrote: >>> >>>> Ron, >>>> >>>> I would just simply call the policy set “policy” (the term used >>>> by a FW vendor we use in our network). There are many policies >>>> in the firewall (1000’s) of them. I don’t think it is scalable >>>> for the classifier to know all of these these policies. This >>>> would also require integration between each firewall vendor and >>>> the classifier’s implementation for the two to understand the >>>> language. Note that a flow may find matches among multiple >>>> policies and the policies can be nested etc. What the >>>> classifier can do at a minimum is to have information related >>>> to which FW SF (physical, logical or virtual) should be >>>> included in the chain for a particular flow. If multiple FW SFs >>>> i.e. multiple virtualised FWs hosting different sets of >>>> policies designed for different tenant/networks reside at a >>>> same IP address then I can see a benefit of the classifier to >>>> specify the correct virtual firewall by name or similar >>>> semantics which is understood by the front-end of the >>>> virtualised firewall SF complex. >>>> >>>> In any case, pointing to the specific policies within the >>>> policies configured on a FW (physical/logical/virtual) is not >>>> scalable or workable, IMHO. >>>> >>>> Regards, >>>> >>>> Chuong >>>> >>>> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>> *Sent:* Tuesday, 11 February 2014 12:06 PM *To:* Pham, Chuong >>>> D *Cc:* Jim Guichard (jguichar); sfc@ietf.org >>>> ; Cathy Zhang; sfc; Paul Quinn (paulq); >>>> meng.wei2@zte.com.cn ; Reinaldo >>>> Penno (repenno) *Subject:* Re: [sfc] Fwd: New Version >>>> Notification for draft-quinn-sfc-arch-04.txt >>>> >>>> Chuong >>>> >>>> A policy set is simply the configuration. What it means is >>>> service function specific. For example, with NAT44, perhaps >>>> when some set of clients access some particular remote subnet, >>>> they should be NAT'd with a special pool of IP addresses, >>>> otherwise the generic pool of IP addresses. But for some >>>> other set of clients, always use the generic pool. This would >>>> be 2 policy sets (I'm open to better names for this). >>>> >>>> Per our previous thread, you could chose to call this NAT44-A >>>> and NAT44-B and create the classifier policy rules such that >>>> the correct flows engage the correct chains and therefore the >>>> correct NAT functionality. It may even be that both logical >>>> NAT instances are located with the same transport address. >>>> >>>> Or, you could 1/2 the number of distinct chains by requiring >>>> that the NAT44 decide on its own, without an assist from the >>>> classifier, when to use the special pool. >>>> >>>> I believe that both use cases are entirely valid and both >>>> should be supported. >>>> >>>> Ron >>>> >>>> >>>> On Feb 10, 2014, at 7:01 PM, "Pham, Chuong D" >>>> >>> > wrote: >>>> >>>> What is a policy set? Is it a virtual/logical firewall? Or is >>>> it what policies to apply to a traffic flow? >>>> >>>> In any case, in approach 3, the classifier would need to know >>>> which FW owns which policy sets anyway unless the idea is >>>> having only one FW SF with all the policy sets in it. If the >>>> classifier needs to know the individual FW SFs, I think >>>> approach 1 and 2 in combination is more practical. >>>> >>>> Effectively, there will be FW SF1, SF2…SFn in a network, >>>> depends on the need of that network. A FW SF may host multiple >>>> policy sets. It’s the local choice and in this case, the FW >>>> will need to decide which policy set to use, just like the way >>>> it does today. >>>> >>>> Regards, >>>> >>>> Chuong >>>> >>>> *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>> *Sent:* Tuesday, 11 February 2014 10:31 AM *To:* Jim Guichard >>>> (jguichar) *Cc:* sfc@ietf.org ; Cathy >>>> Zhang; sfc; Paul Quinn (paulq); meng.wei2@zte.com.cn >>>> ; Reinaldo Penno (repenno) >>>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>>> draft-quinn-sfc-arch-04.txt >>>> >>>> Approach 3 is the most elegant, but also the most costly in >>>> terms of the service header. Rather than deriving both >>>> sequence and policy selection from the chain id that presumably >>>> appears in the service header, we would now need a stack of >>>> policy set identifiers that is pushed on by the classifier -- >>>> one for each service function in the chain. >>>> >>>> Ron >>>> >>>> >>>> On Feb 10, 2014, at 6:17 PM, "Jim Guichard (jguichar)" >>>> > wrote: >>>> >>>> Hi Cathy, >>>> >>>> let’s take the FW example with policy-set-a and policy-set-b. >>>> If we treat the FW as a type of service function where >>>> policy-set-a and policy-set-b are instances of that “type" of >>>> service function then my point is that each of those could be >>>> located at multiple points in the network thereby giving you >>>> multiple “instances” of the policy-set-a “instance” and the >>>> policy-set-b “instance. I will argue that that is not the right >>>> way to look at it.. Let me explain my logic. >>>> >>>> Let’s take the FW example again. Suppose that I now have >>>> policy-set’s a,b,c, & d. Lets further suppose that policy-set’s >>>> a&b are available at service nodes 1, 2, 3 & 4 and policy-set’s >>>> c&d are available at service nodes 5, 6 & 7. Given this, when I >>>> instantiate an SFC that requires say policy-set-a, I cannot >>>> send the traffic to service nodes 5, 6 or 7 as they will not >>>> have the necessary policy to treat the traffic *even though* we >>>> have said they are of the same service function “type". This >>>> gives us a dilemma that can be tackled in 1 of 3 ways imho: >>>> >>>> 1. I could split them into 2 separate service functions; let’s >>>> call them FW(a,b) & FW(c,d). Now the problem with this is that >>>> now I have to rely upon the FW itself to determine which of the >>>> policy-set’s to apply using some out-of-scope for the SFC WG >>>> mechanism. 2. To avoid reclassification as indicated in (1) I >>>> could split each FW+policy-set into its own distinct service >>>> function; FW(a), FW(b), FW(c), and FW(d). The problem with this >>>> is that I could end up with a large number of distinct service >>>> functions. 3. I could let the SFC service encapsulation carry >>>> enough information for the FW to determine which of the >>>> policy-set’s a,b,c,d to apply to a given flow *without* needing >>>> to reclassify at the FW *or* split all of the FW+policy-set >>>> combinations into separate service functions. In other words I >>>> could simply have a service function with type “FW” and >>>> indicate the policy-set within the service encapsulation. >>>> >>>> For me point (3) highlights pretty nicely one of the reasons >>>> for having an SFC service encapsulation. >>>> >>>> *From: *Cathy Zhang >>> > *Date: *Monday, February 10, >>>> 2014 at 4:23 PM *To: *Jim Guichard >>> > *Cc: *"Reinaldo Penno (repenno)" >>>> >, Ron Parker >>>> >>> >, >>>> "meng.wei2@zte.com.cn " >>>> >, Paul >>>> Quinn >, sfc >>>> >, >>>> "sfc@ietf.org " >>> > *Subject: *RE: [sfc] Fwd: New Version >>>> Notification for draft-quinn-sfc-arch-04.txt >>>> >>>> Hi Jim, >>>> >>>> Could you clarify what you mean by an instance of a service >>>> function instance? >>>> >>>> Thanks, >>>> >>>> Cathy >>>> >>>> *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> *Sent:* Monday, February 10, 2014 1:08 PM *To:* Cathy Zhang >>>> *Cc:* Reinaldo Penno (repenno); Ron Parker; >>>> meng.wei2@zte.com.cn ; Paul Quinn >>>> (paulq); sfc; sfc@ietf.org *Subject:* Re: >>>> [sfc] Fwd: New Version Notification for >>>> draft-quinn-sfc-arch-04.txt >>>> >>>> How would you represent an instance of a service function >>>> instance? Seems more logical to represent a service function >>>> type that provides function based on policy set as an >>>> independent service function. >>>> >>>> Sent from my iPhone >>>> >>>> >>>> On Feb 10, 2014, at 3:55 PM, "Cathy Zhang" >>>> > >>>> wrote: >>>> >>>> I share the same view as Reinaldo. >>>> >>>> I think each Service Function is associated with a type, such >>>> as FW Service Function or NAT Service Function >>>> >>>> while each Service Instance is an instantiation of a Service >>>> Function on a Service Node and is associated with a specific >>>> policy profile/set of that type of Service Function. >>>> >>>> In a SFC admin domain, there could be multiple Service Nodes >>>> (physical/virtual) that support a specific Service Function, >>>> such as FW, >>>> >>>> and a service instance could be instantiated on any one of the >>>> Service Nodes (as to which Service Node to instantiate the >>>> service instance, >>>> >>>> it depends on load status of the Service Nodes, network >>>> proximity etc., which is out of scope) . >>>> >>>> Multiple flow chains can be associated with the same Service >>>> Instance on a Service Node, which means these flows will be >>>> applied the same policy set >>>> >>>> for that specific type of service function, as shown in the >>>> following diagram. >>>> >>>> BTW, I would like to suggest that the draft adds a definition >>>> for “Service Instance” to bring everyone on the same page as to >>>> its semantics. >>>> >>>> Thanks, >>>> >>>> Cathy >>>> >>>> >>>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>> *Reinaldo Penno (repenno) *Sent:* Monday, February 10, 2014 >>>> 12:22 PM *To:* Jim Guichard (jguichar); Ron Parker; >>>> meng.wei2@zte.com.cn *Cc:* Paul >>>> Quinn (paulq); sfc; sfc@ietf.org >>>> *Subject:* Re: [sfc] Fwd: New Version Notification for >>>> draft-quinn-sfc-arch-04.txt >>>> >>>> Based on the definition I see this differently. >>>> >>>> The same service function could be instantiated with >>>> policy-set-A and later instantiated with policy-set-B. It is >>>> still the same service function, but different instances. >>>> >>>> Therefore I would consider {1 below} one service function (say, >>>> NAT44) and two different service function instances, one that >>>> applies policy-set-A and other that applies policy-set-A. >>>> >>>> *From: *"Jim Guichard (jguichar)" >>> > *Date: *Monday, February 10, 2014 >>>> at 11:12 AM *To: *Ron Parker >>> >, Cisco Employee >>>> >, >>>> "meng.wei2@zte.com.cn " >>>> > *Cc: >>>> *"Paul Quinn (paulq)" >>> >, "sfc@ietf.org " >>>> >, sfc >>>> > *Subject: >>>> *Re: [sfc] Fwd: New Version Notification for >>>> draft-quinn-sfc-arch-04.txt >>>> >>>> 1. A service function that applies policy-set-A and a different >>>> service function that applies policy-set-B e.g. They are two >>>> distinct service functions. >>>> >>>> _______________________________________________ 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 linda.dunbar@huawei.com Wed Feb 12 09:01:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC681A05D3 for ; Wed, 12 Feb 2014 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 8Yuvqg66LN-v for ; Wed, 12 Feb 2014 09:00:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 63E621A0974 for ; Wed, 12 Feb 2014 09:00:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB07584; Wed, 12 Feb 2014 17:00:57 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 16:59:58 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 17:00:57 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml705-chm.china.huawei.com ([169.254.7.245]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 09:00:52 -0800 From: Linda Dunbar To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5erGoSE8UFskudetbNVt6AL5qx1MWA Date: Wed, 12 Feb 2014 17:00:50 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> References: <52FB9F32.4000005@joelhalpern.com> In-Reply-To: <52FB9F32.4000005@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:01:03 -0000 Agree with Joel's statement.=20 I think a simple sentence below should be added Section 5.2 (SFC Classifier= ) to emphasize this point.=20 "A Service Chain Classifier node can associate a unique Layer 2 or 3 Label= (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer 2 or 3 La= bel makes it easier for subsequent nodes along the flow path to steer the f= low to the service functions specified by the flow's service chain." Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] Framework I was looking at the framework proposal. The proposal has a very specific model of the scope of the transport header= (that it is derived from, and relates only to, the first service function = to which the packet will be directed. That is clearly an operational model we need to support. However, I would like to allow other transport operational models, such as = the use of a VLAN to direct traffic along a chain. Or the use of an MPLS l= abel, or an MPLS label stack. Yours, Joel M. Halpern _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Wed Feb 12 11:32:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55AB1A0631 for ; Wed, 12 Feb 2014 11:32:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrQ-ULQHrJ3M for ; Wed, 12 Feb 2014 11:32:02 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 67B2F1A0696 for ; Wed, 12 Feb 2014 11:32:02 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 11:32:01 -0800 From: Ron Parker To: Linda Dunbar , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziA= Date: Wed, 12 Feb 2014 19:32:00 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:32:05 -0000 Linda, My interpretation of the architecture docs is that the service function cha= in is built in an abstract manner (i.e., SF-A then SF-B then SF-C). Sepa= rately, a locator table provides network location for each of those service= functions. In this way, you can locate the service functions in a manner= appropriate to the type of transport you are using. If you want that to = be interface+VLAN, gateway-IP+MPLS label stack, IP address, GRE tunnel remo= te IP + key, etc., you can do that. You can even potentially locate diff= erent service functions that reside in the same chain with different flavor= s of network locators. Another justification to separate the identity of= a service function from its network location is load balancing. If, for = example, SF-A had 3 IP addresses, that would imply load balancing to 3 inst= ances using IP as a transport layer. For all of those reasons, I strongly support a canonical service header tha= t is independent of the transport methodology. At a particular node, the= decision as to where to go next should be based solely on information carr= ied in the canonical service header and not on the fields in the transport = header. That is, the SFC node discards the transport header and extracts = the chain ID from the service header. Through mechanisms we have not yet= begun to discuss, the SFC node knows how to interpret the chain ID and ult= imately how to progress the packet. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework Agree with Joel's statement.=20 I think a simple sentence below should be added Section 5.2 (SFC Classifier= ) to emphasize this point.=20 "A Service Chain Classifier node can associate a unique Layer 2 or 3 Label= (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer 2 or 3 La= bel makes it easier for subsequent nodes along the flow path to steer the f= low to the service functions specified by the flow's service chain." Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] Framework I was looking at the framework proposal. The proposal has a very specific model of the scope of the transport header= (that it is derived from, and relates only to, the first service function = to which the packet will be directed. That is clearly an operational model we need to support. However, I would like to allow other transport operational models, such as = the use of a VLAN to direct traffic along a chain. Or the use of an MPLS l= abel, or an MPLS label stack. Yours, Joel M. Halpern _______________________________________________ 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 jmh@joelhalpern.com Wed Feb 12 11:37:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98721A0502 for ; Wed, 12 Feb 2014 11:37:23 -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 vdKYdMw120Oh for ; Wed, 12 Feb 2014 11:37:20 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id B6C6B1A04E0 for ; Wed, 12 Feb 2014 11:37:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2C0193A0F8B; Wed, 12 Feb 2014 11:37:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 250F93A0F77; Wed, 12 Feb 2014 11:37:08 -0800 (PST) Message-ID: <52FBCD6F.1020703@joelhalpern.com> Date: Wed, 12 Feb 2014 14:37:19 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ron Parker , Linda Dunbar , "sfc@ietf.org" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:37:23 -0000 Ron, I think the architecture document (quinn) describes these issues in a fashion taht is sufficiently flexible. And I support the definition of the service header. Some of the other individual drafts however refer to process that mandate transport behavior. And do so in ways that are, in my view, too restrictive. Since I don't know how much or little other people agree with those drafts, I wanted to raise the issue of the treatment of the transport in those drafts. Yours, Joel On 2/12/14, 2:32 PM, Ron Parker wrote: > Linda, > > My interpretation of the architecture docs is that the service > function chain is built in an abstract manner (i.e., SF-A then SF-B > then SF-C). Separately, a locator table provides network location > for each of those service functions. In this way, you can locate > the service functions in a manner appropriate to the type of > transport you are using. If you want that to be interface+VLAN, > gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, > etc., you can do that. You can even potentially locate different > service functions that reside in the same chain with different > flavors of network locators. Another justification to separate the > identity of a service function from its network location is load > balancing. If, for example, SF-A had 3 IP addresses, that would > imply load balancing to 3 instances using IP as a transport layer. > > For all of those reasons, I strongly support a canonical service > header that is independent of the transport methodology. At a > particular node, the decision as to where to go next should be based > solely on information carried in the canonical service header and not > on the fields in the transport header. That is, the SFC node > discards the transport header and extracts the chain ID from the > service header. Through mechanisms we have not yet begun to > discuss, the SFC node knows how to interpret the chain ID and > ultimately how to progress the packet. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM > To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework > > Agree with Joel's statement. > > I think a simple sentence below should be added Section 5.2 (SFC > Classifier) to emphasize this point. > > "A Service Chain Classifier node can associate a unique Layer 2 or 3 > Label (e.g. VLAN, MPLS label) to the packets in the flow. Those > Layer 2 or 3 Label makes it easier for subsequent nodes along the > flow path to steer the flow to the service functions specified by the > flow's service chain." > > > Linda -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: > Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] > Framework > > I was looking at the framework proposal. The proposal has a very > specific model of the scope of the transport header (that it is > derived from, and relates only to, the first service function to > which the packet will be directed. That is clearly an operational > model we need to support. > > However, I would like to allow other transport operational models, > such as the use of a VLAN to direct traffic along a chain. Or the > use of an MPLS label, or an MPLS label stack. > > Yours, Joel M. Halpern > > _______________________________________________ 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 Ron_Parker@affirmednetworks.com Wed Feb 12 11:40:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4AC1A0631 for ; Wed, 12 Feb 2014 11:40:53 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q9dVUDePSXM for ; Wed, 12 Feb 2014 11:40:50 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48A1A04E0 for ; Wed, 12 Feb 2014 11:40:50 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 11:40:49 -0800 From: Ron Parker To: "Joel M. Halpern" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAInrgP//ep0g Date: Wed, 12 Feb 2014 19:40:49 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBCD6F.1020703@joelhalpern.com> In-Reply-To: <52FBCD6F.1020703@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:40:53 -0000 Thanks, Joel. To be clear, do you support the strict separation of the service header and= the transport header that I tried to describe in my response to Linda? Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, February 12, 2014 2:37 PM To: Ron Parker; Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework Ron, I think the architecture document (quinn) describes these issues in a = fashion taht is sufficiently flexible. And I support the definition of the service header. Some of the other individual drafts however refer to process that mandate t= ransport behavior. And do so in ways that are, in my view, too restrictive= . Since I don't know how much or little other people agree with those draf= ts, I wanted to raise the issue of the treatment of the transport in those = drafts. Yours, Joel On 2/12/14, 2:32 PM, Ron Parker wrote: > Linda, > > My interpretation of the architecture docs is that the service=20 > function chain is built in an abstract manner (i.e., SF-A then SF-B > then SF-C). Separately, a locator table provides network location > for each of those service functions. In this way, you can locate > the service functions in a manner appropriate to the type of > transport you are using. If you want that to be interface+VLAN, > gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, > etc., you can do that. You can even potentially locate different > service functions that reside in the same chain with different > flavors of network locators. Another justification to separate the > identity of a service function from its network location is load > balancing. If, for example, SF-A had 3 IP addresses, that would > imply load balancing to 3 instances using IP as a transport layer. > > For all of those reasons, I strongly support a canonical service > header that is independent of the transport methodology. At a > particular node, the decision as to where to go next should be based=20 > solely on information carried in the canonical service header and not > on the fields in the transport header. That is, the SFC node > discards the transport header and extracts the chain ID from the > service header. Through mechanisms we have not yet begun to > discuss, the SFC node knows how to interpret the chain ID and=20 > ultimately how to progress the packet. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM > To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework > > Agree with Joel's statement. > > I think a simple sentence below should be added Section 5.2 (SFC > Classifier) to emphasize this point. > > "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 > Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer=20 > 2 or 3 Label makes it easier for subsequent nodes along the flow path=20 > to steer the flow to the service functions specified by the flow's=20 > service chain." > > > Linda -----Original Message----- From: sfc=20 > [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: > Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc]=20 > Framework > > I was looking at the framework proposal. The proposal has a very=20 > specific model of the scope of the transport header (that it is=20 > derived from, and relates only to, the first service function to which=20 > the packet will be directed. That is clearly an operational model we=20 > need to support. > > However, I would like to allow other transport operational models,=20 > such as the use of a VLAN to direct traffic along a chain. Or the use=20 > of an MPLS label, or an MPLS label stack. > > Yours, Joel M. Halpern > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing list=20 > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > From jmh@joelhalpern.com Wed Feb 12 11:43:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E711A062C for ; Wed, 12 Feb 2014 11:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VPZc9W_sOL7L for ; Wed, 12 Feb 2014 11:43:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D97A51A04E0 for ; Wed, 12 Feb 2014 11:43:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 52F5F3A0F8B; Wed, 12 Feb 2014 11:43:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 378A63A0EE0; Wed, 12 Feb 2014 11:43:01 -0800 (PST) Message-ID: <52FBCED0.9070405@joelhalpern.com> Date: Wed, 12 Feb 2014 14:43:12 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ron Parker , Linda Dunbar , "sfc@ietf.org" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBCD6F.1020703@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:43:06 -0000 Yes, I support a strict separation of the transport and service headers. Yours, Joel On 2/12/14, 2:40 PM, Ron Parker wrote: > Thanks, Joel. > > To be clear, do you support the strict separation of the service header and the transport header that I tried to describe in my response to Linda? > > Ron > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, February 12, 2014 2:37 PM > To: Ron Parker; Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] Framework > > Ron, I think the architecture document (quinn) describes these issues in a fashion taht is sufficiently flexible. > And I support the definition of the service header. > > Some of the other individual drafts however refer to process that mandate transport behavior. And do so in ways that are, in my view, too restrictive. Since I don't know how much or little other people agree with those drafts, I wanted to raise the issue of the treatment of the transport in those drafts. > > Yours, > Joel > > On 2/12/14, 2:32 PM, Ron Parker wrote: >> Linda, >> >> My interpretation of the architecture docs is that the service >> function chain is built in an abstract manner (i.e., SF-A then SF-B >> then SF-C). Separately, a locator table provides network location >> for each of those service functions. In this way, you can locate >> the service functions in a manner appropriate to the type of >> transport you are using. If you want that to be interface+VLAN, >> gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, >> etc., you can do that. You can even potentially locate different >> service functions that reside in the same chain with different >> flavors of network locators. Another justification to separate the >> identity of a service function from its network location is load >> balancing. If, for example, SF-A had 3 IP addresses, that would >> imply load balancing to 3 instances using IP as a transport layer. >> >> For all of those reasons, I strongly support a canonical service >> header that is independent of the transport methodology. At a >> particular node, the decision as to where to go next should be based >> solely on information carried in the canonical service header and not >> on the fields in the transport header. That is, the SFC node >> discards the transport header and extracts the chain ID from the >> service header. Through mechanisms we have not yet begun to >> discuss, the SFC node knows how to interpret the chain ID and >> ultimately how to progress the packet. >> >> Ron >> >> >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On >> Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >> >> Agree with Joel's statement. >> >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >> >> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >> 2 or 3 Label makes it easier for subsequent nodes along the flow path >> to steer the flow to the service functions specified by the flow's >> service chain." >> >> >> Linda -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >> Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] >> Framework >> >> I was looking at the framework proposal. The proposal has a very >> specific model of the scope of the transport header (that it is >> derived from, and relates only to, the first service function to which >> the packet will be directed. That is clearly an operational model we >> need to support. >> >> However, I would like to allow other transport operational models, >> such as the use of a VLAN to direct traffic along a chain. Or the use >> of an MPLS label, or an MPLS label stack. >> >> Yours, Joel M. Halpern >> >> _______________________________________________ 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 S.Majee@f5.com Wed Feb 12 12:04:01 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3BD1A0654 for ; Wed, 12 Feb 2014 12:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 KxJIFflnWPGj for ; Wed, 12 Feb 2014 12:03:58 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8651A0631 for ; Wed, 12 Feb 2014 12:03:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="101043653" X-IPAS-Result: AqIEAFDS+1LAqArr/2dsb2JhbABRCYNEV78tgS90giUBAQEBAwEBATctBxcEAgEIDQQBAwEBHwkHJwsUAwYIAgQBEogSyGoTBI4eMDICBIQyBJ8Zjl+CKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Feb 2014 20:03:57 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 12:03:56 -0800 From: Sumandra Majee To: Ron Parker , Linda Dunbar , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5RGY7dwqyrkEqwF+S/DRQfV5qyXfUAgAAqPQD//4LNAA== Date: Wed, 12 Feb 2014 20:03:55 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:04:01 -0000 >>For all of those reasons, I strongly support a canonical service header >>that is independent of the transport methodology. I agree. However the format of service header should be standardized in a way that is flexible. Some of us would like to see variable length header that is also HW friendly. The service header can be represented as a mandotory fixed length header (like IP header) along with an optional variable length attribute field. Different services can be interested in different metadata, for example subscriber ID could be of interest in the mobile core service chain only. Sumandra On 2/12/14, 11:32 AM, "Ron Parker" wrote: >Linda, > >My interpretation of the architecture docs is that the service function >chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >Separately, a locator table provides network location for each of those >service functions. In this way, you can locate the service functions in >a manner appropriate to the type of transport you are using. If you >want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >GRE tunnel remote IP + key, etc., you can do that. You can even >potentially locate different service functions that reside in the same >chain with different flavors of network locators. Another >justification to separate the identity of a service function from its >network location is load balancing. If, for example, SF-A had 3 IP >addresses, that would imply load balancing to 3 instances using IP as a >transport layer. > >For all of those reasons, I strongly support a canonical service header >that is independent of the transport methodology. At a particular >node, the decision as to where to go next should be based solely on >information carried in the canonical service header and not on the fields >in the transport header. That is, the SFC node discards the transport >header and extracts the chain ID from the service header. Through >mechanisms we have not yet begun to discuss, the SFC node knows how to >interpret the chain ID and ultimately how to progress the packet. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Wednesday, February 12, 2014 12:01 PM >To: Joel M. Halpern; sfc@ietf.org >Subject: Re: [sfc] Framework > >Agree with Joel's statement. > >I think a simple sentence below should be added Section 5.2 (SFC >Classifier) to emphasize this point. > > "A Service Chain Classifier node can associate a unique Layer 2 or 3 >Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer 2 >or 3 Label makes it easier for subsequent nodes along the flow path to >steer the flow to the service functions specified by the flow's service >chain." > > >Linda >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 12, 2014 10:20 AM >To: sfc@ietf.org >Subject: [sfc] Framework > >I was looking at the framework proposal. >The proposal has a very specific model of the scope of the transport >header (that it is derived from, and relates only to, the first service >function to which the packet will be directed. >That is clearly an operational model we need to support. > >However, I would like to allow other transport operational models, such >as the use of a VLAN to direct traffic along a chain. Or the use of an >MPLS label, or an MPLS label stack. > >Yours, >Joel M. Halpern > >_______________________________________________ >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 Ron_Parker@affirmednetworks.com Wed Feb 12 12:10:56 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5592C1A0694 for ; Wed, 12 Feb 2014 12:10: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYAjGdShBBwc for ; Wed, 12 Feb 2014 12:10:52 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 95E491A0647 for ; Wed, 12 Feb 2014 12:10:52 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 12:10:51 -0800 From: Ron Parker To: Sumandra Majee , Linda Dunbar , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxw Date: Wed, 12 Feb 2014 20:10:51 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:10:56 -0000 Hi, Sumandra. Regarding service header flexibility, I completely agree. I might suggest= a compromise between hardware friendliness and software flexibility. If= the header had the ability to add extensions (perhaps similar to IPv6) but= also had the header length encoded in the mandatory part (like IPv4), then= a hardware implementation would be free to skip over the extensions (in ca= ses where the deployment justifies ignoring the extensions). Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Wednesday, February 12, 2014 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>For all of those reasons, I strongly support a canonical service=20 >>header that is independent of the transport methodology. I agree. However the format of service header should be standardized in a w= ay that is flexible. Some of us would like to see variable length header th= at is also HW friendly. The service header can be represented as a mandotor= y fixed length header (like IP header) along with an optional variable leng= th attribute field. Different services can be interested in different metad= ata, for example subscriber ID could be of interest in the mobile core serv= ice chain only. Sumandra On 2/12/14, 11:32 AM, "Ron Parker" wrote: >Linda, > >My interpretation of the architecture docs is that the service function=20 >chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >Separately, a locator table provides network location for each of those >service functions. In this way, you can locate the service functions in >a manner appropriate to the type of transport you are using. If you >want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >GRE tunnel remote IP + key, etc., you can do that. You can even >potentially locate different service functions that reside in the same >chain with different flavors of network locators. Another >justification to separate the identity of a service function from its >network location is load balancing. If, for example, SF-A had 3 IP >addresses, that would imply load balancing to 3 instances using IP as a=20 >transport layer. > >For all of those reasons, I strongly support a canonical service header >that is independent of the transport methodology. At a particular >node, the decision as to where to go next should be based solely on=20 >information carried in the canonical service header and not on the fields >in the transport header. That is, the SFC node discards the transport >header and extracts the chain ID from the service header. Through >mechanisms we have not yet begun to discuss, the SFC node knows how to=20 >interpret the chain ID and ultimately how to progress the packet. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Wednesday, February 12, 2014 12:01 PM >To: Joel M. Halpern; sfc@ietf.org >Subject: Re: [sfc] Framework > >Agree with Joel's statement. > >I think a simple sentence below should be added Section 5.2 (SFC >Classifier) to emphasize this point. > > "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer=20 >2 or 3 Label makes it easier for subsequent nodes along the flow path=20 >to steer the flow to the service functions specified by the flow's=20 >service chain." > > >Linda >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 12, 2014 10:20 AM >To: sfc@ietf.org >Subject: [sfc] Framework > >I was looking at the framework proposal. >The proposal has a very specific model of the scope of the transport=20 >header (that it is derived from, and relates only to, the first service=20 >function to which the packet will be directed. >That is clearly an operational model we need to support. > >However, I would like to allow other transport operational models, such=20 >as the use of a VLAN to direct traffic along a chain. Or the use of an=20 >MPLS label, or an MPLS label stack. > >Yours, >Joel M. Halpern > >_______________________________________________ >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 paulq@cisco.com Wed Feb 12 12:39:54 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B421A06CA for ; Wed, 12 Feb 2014 12:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZLOOZJlUaWg for ; Wed, 12 Feb 2014 12:39:52 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id D2CEB1A06E2 for ; Wed, 12 Feb 2014 12:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5559; q=dns/txt; s=iport; t=1392237590; x=1393447190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bmF6DhkDlsNzLQdn8R1U7mPGsrDSIM3LNZemnDAOWu0=; b=fSaazqeC0XCis8aDtYGqIKIx+ZUuV8dlzoagQJKbBNEd5X7TPgVZM4Ea ++yHyqn/tKcgOJnOHRr/qidGLck2iZZJ5mSyVucZqr7ioEpyo+BbOCkQF CPnuW8AgpRgEns5tcdMgy0CEyxAChP+1SjYqgZ9MrvOSN6+IPmnoT8j6i Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHnb+1KtJV2Y/2dsb2JhbABRCYMMOFe/LoEZFnSCJQEBAQMBAQEBNy0HCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgWHfQgNyGcTBI4eKAgrBwIEgx6BFASYKpIhgy2CKg X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="19977938" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 12 Feb 2014 20:39:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1CKdn2w008926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 20:39:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 14:39:49 -0600 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5WFJACJOTPA06mxnRSvHwJFZqyPG4AgAAqPQCAAAjqgIAAAfCAgAAICIA= Date: Wed, 12 Feb 2014 20:39:48 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joel M. Halpern" , Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:39:54 -0000 Hi, We certainly need to be very careful with variable length headers when hard= ware platform are in play. =20 Ron, your examples of IP options and v6 EH have both suffered from signific= ant implementation and deployment hurdles due to the complexity and cost as= sociated with hardware support for the option/EH. Paul On Feb 12, 2014, at 3:10 PM, Ron Parker w= rote: > Hi, Sumandra. >=20 > Regarding service header flexibility, I completely agree. I might sugge= st a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) b= ut also had the header length encoded in the mandatory part (like IPv4), th= en a hardware implementation would be free to skip over the extensions (in = cases where the deployment justifies ignoring the extensions). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com]=20 > Sent: Wednesday, February 12, 2014 3:04 PM > To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 >>> For all of those reasons, I strongly support a canonical service=20 >>> header that is independent of the transport methodology. >=20 >=20 > I agree. However the format of service header should be standardized in a= way that is flexible. Some of us would like to see variable length header = that is also HW friendly. The service header can be represented as a mandot= ory fixed length header (like IP header) along with an optional variable le= ngth attribute field. Different services can be interested in different met= adata, for example subscriber ID could be of interest in the mobile core se= rvice chain only. >=20 > Sumandra >=20 > On 2/12/14, 11:32 AM, "Ron Parker" wrot= e: >=20 >> Linda, >>=20 >> My interpretation of the architecture docs is that the service function= =20 >> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >> Separately, a locator table provides network location for each of those >> service functions. In this way, you can locate the service functions i= n >> a manner appropriate to the type of transport you are using. If you >> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >> GRE tunnel remote IP + key, etc., you can do that. You can even >> potentially locate different service functions that reside in the same >> chain with different flavors of network locators. Another >> justification to separate the identity of a service function from its >> network location is load balancing. If, for example, SF-A had 3 IP >> addresses, that would imply load balancing to 3 instances using IP as a= =20 >> transport layer. >>=20 >> For all of those reasons, I strongly support a canonical service header >> that is independent of the transport methodology. At a particular >> node, the decision as to where to go next should be based solely on=20 >> information carried in the canonical service header and not on the field= s >> in the transport header. That is, the SFC node discards the transport >> header and extracts the chain ID from the service header. Through >> mechanisms we have not yet begun to discuss, the SFC node knows how to=20 >> interpret the chain ID and ultimately how to progress the packet. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >>=20 >> Agree with Joel's statement. >>=20 >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >>=20 >> "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer=20 >> 2 or 3 Label makes it easier for subsequent nodes along the flow path=20 >> to steer the flow to the service functions specified by the flow's=20 >> service chain." >>=20 >>=20 >> Linda >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 10:20 AM >> To: sfc@ietf.org >> Subject: [sfc] Framework >>=20 >> I was looking at the framework proposal. >> The proposal has a very specific model of the scope of the transport=20 >> header (that it is derived from, and relates only to, the first service= =20 >> function to which the packet will be directed. >> That is clearly an operational model we need to support. >>=20 >> However, I would like to allow other transport operational models, such= =20 >> as the use of a VLAN to direct traffic along a chain. Or the use of an= =20 >> MPLS label, or an MPLS label stack. >>=20 >> Yours, >> Joel M. Halpern >>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From S.Majee@f5.com Wed Feb 12 12:42:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC71A06DE for ; Wed, 12 Feb 2014 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 CwhyLRucQUKq for ; Wed, 12 Feb 2014 12:42:48 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 927AD1A0450 for ; Wed, 12 Feb 2014 12:42:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="101048415" X-IPAS-Result: AqIEAN3b+1LAqArr/2dsb2JhbABRCYNEV78ugS90giUBAQEBAwEBATctBxcEAgEIDQQBAwEBHwkHJwsUAwYIAgQBEogSyGcTBI4eMDICBIQyBJ8Zjl+CKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Feb 2014 20:42:45 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 12:42:44 -0800 From: Sumandra Majee To: Ron Parker , Linda Dunbar , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5RGY7dwqyrkEqwF+S/DRQfV5qyXfUAgAAqPQD//4LNAIAAiA2A//+Cy4A= Date: Wed, 12 Feb 2014 20:42:44 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F7DBCB944B6C249A766F6BD9AF925B0@F5.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:42:51 -0000 Yep, that is possible. I would hope to see the header format captured in the architecture document itself. On 2/12/14, 12:10 PM, "Ron Parker" wrote: >Hi, Sumandra. > >Regarding service header flexibility, I completely agree. I might >suggest a compromise between hardware friendliness and software >flexibility. If the header had the ability to add extensions (perhaps >similar to IPv6) but also had the header length encoded in the mandatory >part (like IPv4), then a hardware implementation would be free to skip >over the extensions (in cases where the deployment justifies ignoring the >extensions). > > Ron > > >-----Original Message----- >From: Sumandra Majee [mailto:S.Majee@F5.com] >Sent: Wednesday, February 12, 2014 3:04 PM >To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >Subject: Re: [sfc] Framework > >>>For all of those reasons, I strongly support a canonical service >>>header that is independent of the transport methodology. > > >I agree. However the format of service header should be standardized in a >way that is flexible. Some of us would like to see variable length header >that is also HW friendly. The service header can be represented as a >mandotory fixed length header (like IP header) along with an optional >variable length attribute field. Different services can be interested in >different metadata, for example subscriber ID could be of interest in the >mobile core service chain only. > >Sumandra > >On 2/12/14, 11:32 AM, "Ron Parker" >wrote: > >>Linda, >> >>My interpretation of the architecture docs is that the service function >>chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>Separately, a locator table provides network location for each of those >>service functions. In this way, you can locate the service functions in >>a manner appropriate to the type of transport you are using. If you >>want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >>GRE tunnel remote IP + key, etc., you can do that. You can even >>potentially locate different service functions that reside in the same >>chain with different flavors of network locators. Another >>justification to separate the identity of a service function from its >>network location is load balancing. If, for example, SF-A had 3 IP >>addresses, that would imply load balancing to 3 instances using IP as a >>transport layer. >> >>For all of those reasons, I strongly support a canonical service header >>that is independent of the transport methodology. At a particular >>node, the decision as to where to go next should be based solely on >>information carried in the canonical service header and not on the fields >>in the transport header. That is, the SFC node discards the transport >>header and extracts the chain ID from the service header. Through >>mechanisms we have not yet begun to discuss, the SFC node knows how to >>interpret the chain ID and ultimately how to progress the packet. >> >> Ron >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>Sent: Wednesday, February 12, 2014 12:01 PM >>To: Joel M. Halpern; sfc@ietf.org >>Subject: Re: [sfc] Framework >> >>Agree with Joel's statement. >> >>I think a simple sentence below should be added Section 5.2 (SFC >>Classifier) to emphasize this point. >> >> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>2 or 3 Label makes it easier for subsequent nodes along the flow path >>to steer the flow to the service functions specified by the flow's >>service chain." >> >> >>Linda >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>Sent: Wednesday, February 12, 2014 10:20 AM >>To: sfc@ietf.org >>Subject: [sfc] Framework >> >>I was looking at the framework proposal. >>The proposal has a very specific model of the scope of the transport >>header (that it is derived from, and relates only to, the first service >>function to which the packet will be directed. >>That is clearly an operational model we need to support. >> >>However, I would like to allow other transport operational models, such >>as the use of a VLAN to direct traffic along a chain. Or the use of an >>MPLS label, or an MPLS label stack. >> >>Yours, >>Joel M. Halpern >> >>_______________________________________________ >>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 jmh@joelhalpern.com Wed Feb 12 12:53:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527781A0694 for ; Wed, 12 Feb 2014 12:53:32 -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 Xta2XThh93I6 for ; Wed, 12 Feb 2014 12:53:23 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 728ED1A0665 for ; Wed, 12 Feb 2014 12:53:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DB6933A0F8B; Wed, 12 Feb 2014 12:53:22 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8AAC23A0F8C; Wed, 12 Feb 2014 12:53:21 -0800 (PST) Message-ID: <52FBDF4E.5000400@joelhalpern.com> Date: Wed, 12 Feb 2014 15:53:34 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Paul Quinn (paulq)" , Ron Parker References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Metadata structure X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:53:32 -0000 Paul, I agree that the various extension headers / options have not seen uptake. This is in aprt due to it being somewhat more complex for the hardware. But mostly because the initial need was not there. In this case, we need variable metadata. The range of metadata that people have discussed with me is so high that I can not imagine a fixed length header handling even 80% of the cases well. Yours, Joel On 2/12/14, 3:39 PM, Paul Quinn (paulq) wrote: > Hi, > > We certainly need to be very careful with variable length headers when hardware platform are in play. > > Ron, your examples of IP options and v6 EH have both suffered from significant implementation and deployment hurdles due to the complexity and cost associated with hardware support for the option/EH. > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might suggest a compromise between hardware friendliness and software flexibility. If the header had the ability to add extensions (perhaps similar to IPv6) but also had the header length encoded in the mandatory part (like IPv4), then a hardware implementation would be free to skip over the extensions (in cases where the deployment justifies ignoring the extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in a way that is flexible. Some of us would like to see variable length header that is also HW friendly. The service header can be represented as a mandotory fixed length header (like IP header) along with an optional variable length attribute field. Different services can be interested in different metadata, for example subscriber ID could be of interest in the mobile core service chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" wrote: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service function >>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP as a >>> transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on >>> information carried in the canonical service header and not on the fields >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how to >>> interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>> to steer the flow to the service functions specified by the flow's >>> service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport >>> header (that it is derived from, and relates only to, the first service >>> function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models, such >>> as the use of a VLAN to direct traffic along a chain. Or the use of an >>> MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 jmh@joelhalpern.com Wed Feb 12 12:54:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9B01A06CE for ; Wed, 12 Feb 2014 12:54:39 -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 TE6NdTU8NAew for ; Wed, 12 Feb 2014 12:54:37 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8461A0694 for ; Wed, 12 Feb 2014 12:54:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B6B0A3A0F8B; Wed, 12 Feb 2014 12:54:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1B3E33A0F77; Wed, 12 Feb 2014 12:54:34 -0800 (PST) Message-ID: <52FBDF98.3090206@joelhalpern.com> Date: Wed, 12 Feb 2014 15:54:48 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sumandra Majee , Ron Parker , Linda Dunbar , "sfc@ietf.org" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:54:40 -0000 Sumandra, I would have to dsiagree with you. The structure of the transport-independent service header (which will be carrying the metadata) is very important, but not architectural. The existence of such a header is very much architectural. Yours, Joel On 2/12/14, 3:42 PM, Sumandra Majee wrote: > Yep, that is possible. I would hope to see the header format captured in > the architecture document itself. > > On 2/12/14, 12:10 PM, "Ron Parker" wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might >> suggest a compromise between hardware friendliness and software >> flexibility. If the header had the ability to add extensions (perhaps >> similar to IPv6) but also had the header length encoded in the mandatory >> part (like IPv4), then a hardware implementation would be free to skip >> over the extensions (in cases where the deployment justifies ignoring the >> extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in a >> way that is flexible. Some of us would like to see variable length header >> that is also HW friendly. The service header can be represented as a >> mandotory fixed length header (like IP header) along with an optional >> variable length attribute field. Different services can be interested in >> different metadata, for example subscriber ID could be of interest in the >> mobile core service chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" >> wrote: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service function >>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP as a >>> transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on >>> information carried in the canonical service header and not on the fields >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how to >>> interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>> to steer the flow to the service functions specified by the flow's >>> service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport >>> header (that it is derived from, and relates only to, the first service >>> function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models, such >>> as the use of a VLAN to direct traffic along a chain. Or the use of an >>> MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 smkumar@cisco.com Wed Feb 12 13:04:19 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DD81A06BC for ; Wed, 12 Feb 2014 13:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4-xZ1M1esjY for ; Wed, 12 Feb 2014 13:04:17 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 31B811A06AE for ; Wed, 12 Feb 2014 13:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5974; q=dns/txt; s=iport; t=1392239056; x=1393448656; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2IvrI2RazDc9ymYqT84RgX5QeaW/tXLVShw8NZfdQSQ=; b=P+5VBvwuHgYqax+AycbkJQ4WG9pb2h2LppzS63Vvu2Mjf0BNWyPTV2rm +Cy9xZxyfKMKFfRpCtZ3xkZenVQPed2GA+FOpFYK7AD3dQW5HkR/aIYRy r9L8ZUL+Q5xrESCKAaGVrfG2kuuZOTEXQ9NNh6pjNNXhhFPnJ2ox4nGKg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAFfh+1KtJV2c/2dsb2JhbABRCYMMOFe/LoEZFnSCJQEBAQQBAQE3LQcXBAIBCBEBAwEBAR4JBycLFAMGCAIEARKIBAENyHETBI4eMDICBIQyBJgqkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="303674267" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 12 Feb 2014 21:04:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1CL4FhG001273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 21:04:16 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 15:04:15 -0600 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , Sumandra Majee , Ron Parker , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T9QcfaE2BvUyAObGffF4A4JqyPG4AgAAqPQCAAAjqgIAAAfCAgAAI6QCAAANfAP//fIWA Date: Wed, 12 Feb 2014 21:04:15 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBDF98.3090206@joelhalpern.com> In-Reply-To: <52FBDF98.3090206@joelhalpern.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: [171.71.15.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <681A689D524F6643B7567643D82D558C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:04:20 -0000 +1 I complete agree with Joel's assessment. Surendra. On 2/12/14 12:54 PM, "Joel M. Halpern" wrote: >Sumandra, I would have to dsiagree with you. The structure of the >transport-independent service header (which will be carrying the >metadata) is very important, but not architectural. The existence of >such a header is very much architectural. > >Yours, >Joel > >On 2/12/14, 3:42 PM, Sumandra Majee wrote: >> Yep, that is possible. I would hope to see the header format captured in >> the architecture document itself. >> >> On 2/12/14, 12:10 PM, "Ron Parker" >>wrote: >> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I completely agree. I might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>>(perhaps >>> similar to IPv6) but also had the header length encoded in the >>>mandatory >>> part (like IPv4), then a hardware implementation would be free to skip >>> over the extensions (in cases where the deployment justifies ignoring >>>the >>> extensions). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>> >>> >>> I agree. However the format of service header should be standardized >>>in a >>> way that is flexible. Some of us would like to see variable length >>>header >>> that is also HW friendly. The service header can be represented as a >>> mandotory fixed length header (like IP header) along with an optional >>> variable length attribute field. Different services can be interested >>>in >>> different metadata, for example subscriber ID could be of interest in >>>the >>> mobile core service chain only. >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >>> wrote: >>> >>>> Linda, >>>> >>>> My interpretation of the architecture docs is that the service >>>>function >>>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>>> Separately, a locator table provides network location for each of >>>>those >>>> service functions. In this way, you can locate the service >>>>functions in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >>>>address, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP as >>>>a >>>> transport layer. >>>> >>>> For all of those reasons, I strongly support a canonical service >>>>header >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the >>>>fields >>>> in the transport header. That is, the SFC node discards the >>>>transport >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how to >>>> interpret the chain ID and ultimately how to progress the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>>> to steer the flow to the service functions specified by the flow's >>>> service chain." >>>> >>>> >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first >>>>service >>>> function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>> >>>> However, I would like to allow other transport operational models, >>>>such >>>> as the use of a VLAN to direct traffic along a chain. Or the use of >>>>an >>>> MPLS label, or an MPLS label stack. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> _______________________________________________ >>>> 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 Ron_Parker@affirmednetworks.com Wed Feb 12 13:05:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2DC1A06B7 for ; Wed, 12 Feb 2014 13:05:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3fQPZNUVJCM for ; Wed, 12 Feb 2014 13:05:12 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id D530F1A06AE for ; Wed, 12 Feb 2014 13:05:12 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 13:05:12 -0800 From: Ron Parker To: "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48A== Date: Wed, 12 Feb 2014 21:05:10 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joel M. Halpern" , Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:05:16 -0000 Paul,=20 That is why I am proposing a hybrid where extensions or options can be adde= d but the total length is contained in the fixed portion. I can envision = certain deployments (e.g., Enterprise) where perhaps extensions are not nee= ded and the SFC functionality is realized in hardware. And, I can envisio= n certain other deployments (e.g., 3gpp) where the extension headers add su= fficient value to justify software based implementations. Ron -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, February 12, 2014 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework Hi, We certainly need to be very careful with variable length headers when hard= ware platform are in play. =20 Ron, your examples of IP options and v6 EH have both suffered from signific= ant implementation and deployment hurdles due to the complexity and cost as= sociated with hardware support for the option/EH. Paul On Feb 12, 2014, at 3:10 PM, Ron Parker w= rote: > Hi, Sumandra. >=20 > Regarding service header flexibility, I completely agree. I might sugge= st a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) b= ut also had the header length encoded in the mandatory part (like IPv4), th= en a hardware implementation would be free to skip over the extensions (in = cases where the deployment justifies ignoring the extensions). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, February 12, 2014 3:04 PM > To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 >>> For all of those reasons, I strongly support a canonical service=20 >>> header that is independent of the transport methodology. >=20 >=20 > I agree. However the format of service header should be standardized in a= way that is flexible. Some of us would like to see variable length header = that is also HW friendly. The service header can be represented as a mandot= ory fixed length header (like IP header) along with an optional variable le= ngth attribute field. Different services can be interested in different met= adata, for example subscriber ID could be of interest in the mobile core se= rvice chain only. >=20 > Sumandra >=20 > On 2/12/14, 11:32 AM, "Ron Parker" wrot= e: >=20 >> Linda, >>=20 >> My interpretation of the architecture docs is that the service=20 >> function chain is built in an abstract manner (i.e., SF-A then SF-B then= SF-C). >> Separately, a locator table provides network location for each of those >> service functions. In this way, you can locate the service functions i= n >> a manner appropriate to the type of transport you are using. If you >> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >> GRE tunnel remote IP + key, etc., you can do that. You can even >> potentially locate different service functions that reside in the same >> chain with different flavors of network locators. Another >> justification to separate the identity of a service function from its >> network location is load balancing. If, for example, SF-A had 3 IP >> addresses, that would imply load balancing to 3 instances using IP as=20 >> a transport layer. >>=20 >> For all of those reasons, I strongly support a canonical service header >> that is independent of the transport methodology. At a particular >> node, the decision as to where to go next should be based solely on=20 >> information carried in the canonical service header and not on the field= s >> in the transport header. That is, the SFC node discards the transport >> header and extracts the chain ID from the service header. Through >> mechanisms we have not yet begun to discuss, the SFC node knows how=20 >> to interpret the chain ID and ultimately how to progress the packet. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >>=20 >> Agree with Joel's statement. >>=20 >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >>=20 >> "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those =20 >> Layer >> 2 or 3 Label makes it easier for subsequent nodes along the flow path=20 >> to steer the flow to the service functions specified by the flow's=20 >> service chain." >>=20 >>=20 >> Linda >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 10:20 AM >> To: sfc@ietf.org >> Subject: [sfc] Framework >>=20 >> I was looking at the framework proposal. >> The proposal has a very specific model of the scope of the transport=20 >> header (that it is derived from, and relates only to, the first=20 >> service function to which the packet will be directed. >> That is clearly an operational model we need to support. >>=20 >> However, I would like to allow other transport operational models,=20 >> such as the use of a VLAN to direct traffic along a chain. Or the=20 >> use of an MPLS label, or an MPLS label stack. >>=20 >> Yours, >> Joel M. Halpern >>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From ddolson@sandvine.com Wed Feb 12 13:10:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F0E1A0647 for ; Wed, 12 Feb 2014 13:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 j2WTehVcl9Kn for ; Wed, 12 Feb 2014 13:10:01 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id F26EF1A0591 for ; Wed, 12 Feb 2014 13:10:00 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Wed, 12 Feb 2014 16:09:59 -0500 From: Dave Dolson To: Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQ Date: Wed, 12 Feb 2014 21:09:59 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.7.137.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joel M. Halpern" , Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:10:04 -0000 I think a good approach would be: The information required for forwarding (the SF Identifier) should be in a = mandatory fixed-size header. Optional information (if any) is NOT to be used for forwarding, but is for = consumption by one or more of the applications in the chain. Then the forwarding plane, and even the PDP, can be agnostic about the meta= -data. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework Paul,=20 That is why I am proposing a hybrid where extensions or options can be adde= d but the total length is contained in the fixed portion. I can envision = certain deployments (e.g., Enterprise) where perhaps extensions are not nee= ded and the SFC functionality is realized in hardware. And, I can envisio= n certain other deployments (e.g., 3gpp) where the extension headers add su= fficient value to justify software based implementations. Ron -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, February 12, 2014 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework Hi, We certainly need to be very careful with variable length headers when hard= ware platform are in play. =20 Ron, your examples of IP options and v6 EH have both suffered from signific= ant implementation and deployment hurdles due to the complexity and cost as= sociated with hardware support for the option/EH. Paul On Feb 12, 2014, at 3:10 PM, Ron Parker w= rote: > Hi, Sumandra. >=20 > Regarding service header flexibility, I completely agree. I might sugge= st a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) b= ut also had the header length encoded in the mandatory part (like IPv4), th= en a hardware implementation would be free to skip over the extensions (in = cases where the deployment justifies ignoring the extensions). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, February 12, 2014 3:04 PM > To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 >>> For all of those reasons, I strongly support a canonical service=20 >>> header that is independent of the transport methodology. >=20 >=20 > I agree. However the format of service header should be standardized in a= way that is flexible. Some of us would like to see variable length header = that is also HW friendly. The service header can be represented as a mandot= ory fixed length header (like IP header) along with an optional variable le= ngth attribute field. Different services can be interested in different met= adata, for example subscriber ID could be of interest in the mobile core se= rvice chain only. >=20 > Sumandra >=20 > On 2/12/14, 11:32 AM, "Ron Parker" wrot= e: >=20 >> Linda, >>=20 >> My interpretation of the architecture docs is that the service=20 >> function chain is built in an abstract manner (i.e., SF-A then SF-B then= SF-C). >> Separately, a locator table provides network location for each of those >> service functions. In this way, you can locate the service functions i= n >> a manner appropriate to the type of transport you are using. If you >> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >> GRE tunnel remote IP + key, etc., you can do that. You can even >> potentially locate different service functions that reside in the same >> chain with different flavors of network locators. Another >> justification to separate the identity of a service function from its >> network location is load balancing. If, for example, SF-A had 3 IP >> addresses, that would imply load balancing to 3 instances using IP as=20 >> a transport layer. >>=20 >> For all of those reasons, I strongly support a canonical service header >> that is independent of the transport methodology. At a particular >> node, the decision as to where to go next should be based solely on=20 >> information carried in the canonical service header and not on the field= s >> in the transport header. That is, the SFC node discards the transport >> header and extracts the chain ID from the service header. Through >> mechanisms we have not yet begun to discuss, the SFC node knows how=20 >> to interpret the chain ID and ultimately how to progress the packet. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >>=20 >> Agree with Joel's statement. >>=20 >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >>=20 >> "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those =20 >> Layer >> 2 or 3 Label makes it easier for subsequent nodes along the flow path=20 >> to steer the flow to the service functions specified by the flow's=20 >> service chain." >>=20 >>=20 >> Linda >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 10:20 AM >> To: sfc@ietf.org >> Subject: [sfc] Framework >>=20 >> I was looking at the framework proposal. >> The proposal has a very specific model of the scope of the transport=20 >> header (that it is derived from, and relates only to, the first=20 >> service function to which the packet will be directed. >> That is clearly an operational model we need to support. >>=20 >> However, I would like to allow other transport operational models,=20 >> such as the use of a VLAN to direct traffic along a chain. Or the=20 >> use of an MPLS label, or an MPLS label stack. >>=20 >> Yours, >> Joel M. Halpern >>=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 >=20 > _______________________________________________ > 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 Ron_Parker@affirmednetworks.com Wed Feb 12 13:24:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA911A06CE for ; Wed, 12 Feb 2014 13:24:31 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TilEMy2_KUY1 for ; Wed, 12 Feb 2014 13:24:27 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8D57A1A066B for ; Wed, 12 Feb 2014 13:24:27 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 13:24:27 -0800 From: Ron Parker To: Dave Dolson , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgA= Date: Wed, 12 Feb 2014 21:24:26 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joel M. Halpern" , Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:24:32 -0000 Hi, Dave. I Agree with your statement. And if the total length of the header is c= ontained in the mandatory portion, the hardware implementation can easily l= ocate the encapsulated packet. Ron -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, February 12, 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] Framework I think a good approach would be: The information required for forwarding (the SF Identifier) should be in a = mandatory fixed-size header. Optional information (if any) is NOT to be used for forwarding, but is for = consumption by one or more of the applications in the chain. Then the forwarding plane, and even the PDP, can be agnostic about the meta= -data. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework Paul,=20 That is why I am proposing a hybrid where extensions or options can be adde= d but the total length is contained in the fixed portion. I can envision = certain deployments (e.g., Enterprise) where perhaps extensions are not nee= ded and the SFC functionality is realized in hardware. And, I can envisio= n certain other deployments (e.g., 3gpp) where the extension headers add su= fficient value to justify software based implementations. Ron -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework Hi, We certainly need to be very careful with variable length headers when hard= ware platform are in play. =20 Ron, your examples of IP options and v6 EH have both suffered from signific= ant implementation and deployment hurdles due to the complexity and cost as= sociated with hardware support for the option/EH. Paul On Feb 12, 2014, at 3:10 PM, Ron Parker w= rote: > Hi, Sumandra. >=20 > Regarding service header flexibility, I completely agree. I might sugge= st a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) b= ut also had the header length encoded in the mandatory part (like IPv4), th= en a hardware implementation would be free to skip over the extensions (in = cases where the deployment justifies ignoring the extensions). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, February 12, 2014 3:04 PM > To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 >>> For all of those reasons, I strongly support a canonical service=20 >>> header that is independent of the transport methodology. >=20 >=20 > I agree. However the format of service header should be standardized in a= way that is flexible. Some of us would like to see variable length header = that is also HW friendly. The service header can be represented as a mandot= ory fixed length header (like IP header) along with an optional variable le= ngth attribute field. Different services can be interested in different met= adata, for example subscriber ID could be of interest in the mobile core se= rvice chain only. >=20 > Sumandra >=20 > On 2/12/14, 11:32 AM, "Ron Parker" wrot= e: >=20 >> Linda, >>=20 >> My interpretation of the architecture docs is that the service=20 >> function chain is built in an abstract manner (i.e., SF-A then SF-B then= SF-C). >> Separately, a locator table provides network location for each of those >> service functions. In this way, you can locate the service functions i= n >> a manner appropriate to the type of transport you are using. If you >> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >> GRE tunnel remote IP + key, etc., you can do that. You can even >> potentially locate different service functions that reside in the same >> chain with different flavors of network locators. Another >> justification to separate the identity of a service function from its >> network location is load balancing. If, for example, SF-A had 3 IP >> addresses, that would imply load balancing to 3 instances using IP as=20 >> a transport layer. >>=20 >> For all of those reasons, I strongly support a canonical service header >> that is independent of the transport methodology. At a particular >> node, the decision as to where to go next should be based solely on=20 >> information carried in the canonical service header and not on the field= s >> in the transport header. That is, the SFC node discards the transport >> header and extracts the chain ID from the service header. Through >> mechanisms we have not yet begun to discuss, the SFC node knows how=20 >> to interpret the chain ID and ultimately how to progress the packet. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >>=20 >> Agree with Joel's statement. >>=20 >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >>=20 >> "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >> 2 or 3 Label makes it easier for subsequent nodes along the flow path=20 >> to steer the flow to the service functions specified by the flow's=20 >> service chain." >>=20 >>=20 >> Linda >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 10:20 AM >> To: sfc@ietf.org >> Subject: [sfc] Framework >>=20 >> I was looking at the framework proposal. >> The proposal has a very specific model of the scope of the transport=20 >> header (that it is derived from, and relates only to, the first=20 >> service function to which the packet will be directed. >> That is clearly an operational model we need to support. >>=20 >> However, I would like to allow other transport operational models,=20 >> such as the use of a VLAN to direct traffic along a chain. Or the=20 >> use of an MPLS label, or an MPLS label stack. >>=20 >> Yours, >> Joel M. Halpern >>=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 >=20 > _______________________________________________ > 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 jmh@joelhalpern.com Wed Feb 12 13:30:17 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7F31A066B for ; Wed, 12 Feb 2014 13:30:17 -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 TSpBZrF6o_4t for ; Wed, 12 Feb 2014 13:30:14 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C75181A0647 for ; Wed, 12 Feb 2014 13:30:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3B5193A0F77; Wed, 12 Feb 2014 13:30:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9A16E3A0F86; Wed, 12 Feb 2014 13:30:12 -0800 (PST) Message-ID: <52FBE7F3.1050605@joelhalpern.com> Date: Wed, 12 Feb 2014 16:30:27 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ron Parker , Dave Dolson , "Paul Quinn (paulq)" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:30:18 -0000 I agree as well. Yours, Joel On 2/12/14, 4:24 PM, Ron Parker wrote: > Hi, Dave. > > I Agree with your statement. And if the total length of the header is contained in the mandatory portion, the hardware implementation can easily locate the encapsulated packet. > > Ron > > > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 12, 2014 4:10 PM > To: Ron Parker; Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: RE: [sfc] Framework > > I think a good approach would be: > > The information required for forwarding (the SF Identifier) should be in a mandatory fixed-size header. > > Optional information (if any) is NOT to be used for forwarding, but is for consumption by one or more of the applications in the chain. > > Then the forwarding plane, and even the PDP, can be agnostic about the meta-data. > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Wednesday, February 12, 2014 4:05 PM > To: Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework > > Paul, > > That is why I am proposing a hybrid where extensions or options can be added but the total length is contained in the fixed portion. I can envision certain deployments (e.g., Enterprise) where perhaps extensions are not needed and the SFC functionality is realized in hardware. And, I can envision certain other deployments (e.g., 3gpp) where the extension headers add sufficient value to justify software based implementations. > > Ron > > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, February 12, 2014 3:40 PM > To: Ron Parker > Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework > > Hi, > > We certainly need to be very careful with variable length headers when hardware platform are in play. > > Ron, your examples of IP options and v6 EH have both suffered from significant implementation and deployment hurdles due to the complexity and cost associated with hardware support for the option/EH. > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might suggest a compromise between hardware friendliness and software flexibility. If the header had the ability to add extensions (perhaps similar to IPv6) but also had the header length encoded in the mandatory part (like IPv4), then a hardware implementation would be free to skip over the extensions (in cases where the deployment justifies ignoring the extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in a way that is flexible. Some of us would like to see variable length header that is also HW friendly. The service header can be represented as a mandotory fixed length header (like IP header) along with an optional variable length attribute field. Different services can be interested in different metadata, for example subscriber ID could be of interest in the mobile core service chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" wrote: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service >>> function chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP as >>> a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on >>> information carried in the canonical service header and not on the fields >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how >>> to interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>> to steer the flow to the service functions specified by the flow's >>> service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport >>> header (that it is derived from, and relates only to, the first >>> service function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models, >>> such as the use of a VLAN to direct traffic along a chain. Or the >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From Chuong.D.Pham@team.telstra.com Wed Feb 12 14:10:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14A81A0005 for ; Wed, 12 Feb 2014 14:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCKrvXLrzVjW for ; Wed, 12 Feb 2014 14:10:23 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD51A0002 for ; Wed, 12 Feb 2014 14:10:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,834,1384261200"; d="scan'208";a="182927812" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 13 Feb 2014 09:10:20 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="195387979" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 13 Feb 2014 09:09:54 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 13 Feb 2014 09:09:54 +1100 From: "Pham, Chuong D" To: "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 09:09:52 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8nPsI8wx0hXPcgRj6Hybf/H728gQAVehGQAA+ZyCAAGqORUA== Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 22:10:26 -0000 Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for= =20 >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control=20 >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS=20 >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network.=20 >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From linda.dunbar@huawei.com Wed Feb 12 14:13:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C401A0015 for ; Wed, 12 Feb 2014 14:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 CCl2gLvNNnxI for ; Wed, 12 Feb 2014 14:13:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B976A1A0002 for ; Wed, 12 Feb 2014 14:13:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDN42271; Wed, 12 Feb 2014 22:13:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 22:13:01 +0000 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 22:13:16 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml703-chm.china.huawei.com ([169.254.5.188]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:13:13 -0800 From: Linda Dunbar To: "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAAmPrAIADhxoAgAROqDA= Date: Wed, 12 Feb 2014 22:13:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:13:25 -0000 Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID?=20 I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good.=20 Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions.=20 =20 | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF | | |Network| =20 | | < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 | | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com]=20 Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password"=20 >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF =20 >paragraph in -01. Possibly we will consider 2 sections: most simple=20 >case (with APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not=20 >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 ddolson@sandvine.com Wed Feb 12 14:18:11 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE381A0020 for ; Wed, 12 Feb 2014 14:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 vd94wJN8451I for ; Wed, 12 Feb 2014 14:18:03 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC021A001E for ; Wed, 12 Feb 2014 14:18:01 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Wed, 12 Feb 2014 17:18:00 -0500 From: Dave Dolson To: "Joel M. Halpern" , Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQgABYqACAAAGugP//uNTg Date: Wed, 12 Feb 2014 22:17:59 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBE7F3.1050605@joelhalpern.com> In-Reply-To: <52FBE7F3.1050605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.7.137.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:18:11 -0000 The forwarding plane might not even need to look at the encapsulated packet= . For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can f= orward packets of the form: Ether | VLAN | BLOB. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework I agree as well. Yours, Joel On 2/12/14, 4:24 PM, Ron Parker wrote: > Hi, Dave. > > I Agree with your statement. And if the total length of the header is= contained in the mandatory portion, the hardware implementation can easily= locate the encapsulated packet. > > Ron > > > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 12, 2014 4:10 PM > To: Ron Parker; Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: RE: [sfc] Framework > > I think a good approach would be: > > The information required for forwarding (the SF Identifier) should be in = a mandatory fixed-size header. > > Optional information (if any) is NOT to be used for forwarding, but is fo= r consumption by one or more of the applications in the chain. > > Then the forwarding plane, and even the PDP, can be agnostic about the me= ta-data. > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Wednesday, February 12, 2014 4:05 PM > To: Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework > > Paul, > > That is why I am proposing a hybrid where extensions or options can be ad= ded but the total length is contained in the fixed portion. I can envisio= n certain deployments (e.g., Enterprise) where perhaps extensions are not n= eeded and the SFC functionality is realized in hardware. And, I can envis= ion certain other deployments (e.g., 3gpp) where the extension headers add = sufficient value to justify software based implementations. > > Ron > > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, February 12, 2014 3:40 PM > To: Ron Parker > Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework > > Hi, > > We certainly need to be very careful with variable length headers when ha= rdware platform are in play. > > Ron, your examples of IP options and v6 EH have both suffered from signif= icant implementation and deployment hurdles due to the complexity and cost = associated with hardware support for the option/EH. > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker = wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might sugg= est a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) = but also had the header length encoded in the mandatory part (like IPv4), t= hen a hardware implementation would be free to skip over the extensions (in= cases where the deployment justifies ignoring the extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in = a way that is flexible. Some of us would like to see variable length header= that is also HW friendly. The service header can be represented as a mando= tory fixed length header (like IP header) along with an optional variable l= ength attribute field. Different services can be interested in different me= tadata, for example subscriber ID could be of interest in the mobile core s= ervice chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" wro= te: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service >>> function chain is built in an abstract manner (i.e., SF-A then SF-B the= n SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions = in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address= , >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP as >>> a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on >>> information carried in the canonical service header and not on the fiel= ds >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how >>> to interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>> to steer the flow to the service functions specified by the flow's >>> service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport >>> header (that it is derived from, and relates only to, the first >>> service function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models, >>> such as the use of a VLAN to direct traffic along a chain. Or the >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 Ron_Parker@affirmednetworks.com Wed Feb 12 14:25:37 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3472D1A000B for ; Wed, 12 Feb 2014 14:25: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxMuiyO7xtTv for ; Wed, 12 Feb 2014 14:25:34 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 87C691A0015 for ; Wed, 12 Feb 2014 14:25:34 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:25:33 -0800 From: Ron Parker To: Dave Dolson , "Joel M. Halpern" , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFA= Date: Wed, 12 Feb 2014 22:25:32 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBE7F3.1050605@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:25:37 -0000 Dave, Yes, that is a good point if we logically separate the forwarding function = from the SFC-aware service function, as we should. The forwarding functio= n is concerned with only the inbound transport header, the fixed portion of= the service header containing the chain information, and the outbound tran= sport header. The service function may look at the entirety of the servi= ce header and would look at the encapsulated packet. Ron -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, February 12, 2014 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] Framework The forwarding plane might not even need to look at the encapsulated packet= . For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can f= orward packets of the form: Ether | VLAN | BLOB. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework I agree as well. Yours, Joel On 2/12/14, 4:24 PM, Ron Parker wrote: > Hi, Dave. > > I Agree with your statement. And if the total length of the header is= contained in the mandatory portion, the hardware implementation can easily= locate the encapsulated packet. > > Ron > > > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 12, 2014 4:10 PM > To: Ron Parker; Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: RE: [sfc] Framework > > I think a good approach would be: > > The information required for forwarding (the SF Identifier) should be in = a mandatory fixed-size header. > > Optional information (if any) is NOT to be used for forwarding, but is fo= r consumption by one or more of the applications in the chain. > > Then the forwarding plane, and even the PDP, can be agnostic about the me= ta-data. > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Wednesday, February 12, 2014 4:05 PM > To: Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework > > Paul, > > That is why I am proposing a hybrid where extensions or options can be ad= ded but the total length is contained in the fixed portion. I can envisio= n certain deployments (e.g., Enterprise) where perhaps extensions are not n= eeded and the SFC functionality is realized in hardware. And, I can envis= ion certain other deployments (e.g., 3gpp) where the extension headers add = sufficient value to justify software based implementations. > > Ron > > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, February 12, 2014 3:40 PM > To: Ron Parker > Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework > > Hi, > > We certainly need to be very careful with variable length headers when ha= rdware platform are in play. > > Ron, your examples of IP options and v6 EH have both suffered from signif= icant implementation and deployment hurdles due to the complexity and cost = associated with hardware support for the option/EH. > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker = wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might sugg= est a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) = but also had the header length encoded in the mandatory part (like IPv4), t= hen a hardware implementation would be free to skip over the extensions (in= cases where the deployment justifies ignoring the extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service=20 >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in = a way that is flexible. Some of us would like to see variable length header= that is also HW friendly. The service header can be represented as a mando= tory fixed length header (like IP header) along with an optional variable l= ength attribute field. Different services can be interested in different me= tadata, for example subscriber ID could be of interest in the mobile core s= ervice chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" wro= te: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service=20 >>> function chain is built in an abstract manner (i.e., SF-A then SF-B the= n SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions = in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address= , >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP=20 >>> as a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on=20 >>> information carried in the canonical service header and not on the fiel= ds >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how=20 >>> to interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or=20 >>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those=20 >>> Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow=20 >>> path to steer the flow to the service functions specified by the=20 >>> flow's service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport=20 >>> header (that it is derived from, and relates only to, the first=20 >>> service function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models,=20 >>> such as the use of a VLAN to direct traffic along a chain. Or the=20 >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 S.Majee@f5.com Wed Feb 12 14:27:17 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30F1A000B for ; Wed, 12 Feb 2014 14:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 YP0zgkArmeTy for ; Wed, 12 Feb 2014 14:27:14 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FA1A0013 for ; Wed, 12 Feb 2014 14:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1392244034; x=1423780034; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qZGtuVjA8m3VX5ISVLY96o4+D0Hw/o3xy3jbOzqcUlM=; b=Tmc26rQDktWubM+c6kFl05x43wKKpUjBv+04Ud0KsRbHgU+5JTZ6AY15 wDEdj/NeFD+uD+9scecit/54TfNGrLAyga0RMry7vqjNdgsNRzzvYA6cS Lec8t/BCXe3NHz7Ym6pgqxa69m1wqOfEzUnuBURRfCKCsr3cb3/2vTuw6 8=; X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="scan'208";a="100212162" X-IPAS-Result: AqMEABr0+1LAqArr/2dsb2JhbABRCYNEV78vgS90giUBAQEBAwEBATctBxcEAgEIDQQBAwEBAQoUCQcnCxQDBggCBAESCIgKyGITBI4eKgYyAgSDHoEUBJ8Zjl+CKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 12 Feb 2014 22:27:14 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:27:13 -0800 From: Sumandra Majee To: "Joel M. Halpern" , Ron Parker , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5RGY7dwqyrkEqwF+S/DRQfV5qyXfUAgAAqPQD//4LNAIAAiA2A//+Cy4CAAIl9AP//ktnw Date: Wed, 12 Feb 2014 22:27:12 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884A0426F@SEAEMBX01.olympus.F5Net.com> References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> ,<52FBDF98.3090206@joelhalpern.com> In-Reply-To: <52FBDF98.3090206@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:27:18 -0000 Are you suggesting a different document? =0A= =0A= This would be required for interoperability so it is still part of *a* docu= ment. =0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Wednesday, February 12, 2014 12:54 PM=0A= To: Sumandra Majee; Ron Parker; Linda Dunbar; sfc@ietf.org=0A= Subject: Re: [sfc] Framework=0A= =0A= Sumandra, I would have to dsiagree with you. The structure of the=0A= transport-independent service header (which will be carrying the=0A= metadata) is very important, but not architectural. The existence of=0A= such a header is very much architectural.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 2/12/14, 3:42 PM, Sumandra Majee wrote:=0A= > Yep, that is possible. I would hope to see the header format captured in= =0A= > the architecture document itself.=0A= >=0A= > On 2/12/14, 12:10 PM, "Ron Parker" wrot= e:=0A= >=0A= >> Hi, Sumandra.=0A= >>=0A= >> Regarding service header flexibility, I completely agree. I might=0A= >> suggest a compromise between hardware friendliness and software=0A= >> flexibility. If the header had the ability to add extensions (perhaps= =0A= >> similar to IPv6) but also had the header length encoded in the mandatory= =0A= >> part (like IPv4), then a hardware implementation would be free to skip= =0A= >> over the extensions (in cases where the deployment justifies ignoring th= e=0A= >> extensions).=0A= >>=0A= >> Ron=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >> Sent: Wednesday, February 12, 2014 3:04 PM=0A= >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org=0A= >> Subject: Re: [sfc] Framework=0A= >>=0A= >>>> For all of those reasons, I strongly support a canonical service=0A= >>>> header that is independent of the transport methodology.=0A= >>=0A= >>=0A= >> I agree. However the format of service header should be standardized in = a=0A= >> way that is flexible. Some of us would like to see variable length heade= r=0A= >> that is also HW friendly. The service header can be represented as a=0A= >> mandotory fixed length header (like IP header) along with an optional=0A= >> variable length attribute field. Different services can be interested in= =0A= >> different metadata, for example subscriber ID could be of interest in th= e=0A= >> mobile core service chain only.=0A= >>=0A= >> Sumandra=0A= >>=0A= >> On 2/12/14, 11:32 AM, "Ron Parker" =0A= >> wrote:=0A= >>=0A= >>> Linda,=0A= >>>=0A= >>> My interpretation of the architecture docs is that the service function= =0A= >>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C).= =0A= >>> Separately, a locator table provides network location for each of those= =0A= >>> service functions. In this way, you can locate the service functions = in=0A= >>> a manner appropriate to the type of transport you are using. If you= =0A= >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address= ,=0A= >>> GRE tunnel remote IP + key, etc., you can do that. You can even=0A= >>> potentially locate different service functions that reside in the same= =0A= >>> chain with different flavors of network locators. Another=0A= >>> justification to separate the identity of a service function from its= =0A= >>> network location is load balancing. If, for example, SF-A had 3 IP=0A= >>> addresses, that would imply load balancing to 3 instances using IP as a= =0A= >>> transport layer.=0A= >>>=0A= >>> For all of those reasons, I strongly support a canonical service header= =0A= >>> that is independent of the transport methodology. At a particular=0A= >>> node, the decision as to where to go next should be based solely on=0A= >>> information carried in the canonical service header and not on the fiel= ds=0A= >>> in the transport header. That is, the SFC node discards the transport= =0A= >>> header and extracts the chain ID from the service header. Through=0A= >>> mechanisms we have not yet begun to discuss, the SFC node knows how to= =0A= >>> interpret the chain ID and ultimately how to progress the packet.=0A= >>>=0A= >>> Ron=0A= >>>=0A= >>>=0A= >>> -----Original Message-----=0A= >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar=0A= >>> Sent: Wednesday, February 12, 2014 12:01 PM=0A= >>> To: Joel M. Halpern; sfc@ietf.org=0A= >>> Subject: Re: [sfc] Framework=0A= >>>=0A= >>> Agree with Joel's statement.=0A= >>>=0A= >>> I think a simple sentence below should be added Section 5.2 (SFC=0A= >>> Classifier) to emphasize this point.=0A= >>>=0A= >>> "A Service Chain Classifier node can associate a unique Layer 2 or = 3=0A= >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer= =0A= >>> 2 or 3 Label makes it easier for subsequent nodes along the flow path= =0A= >>> to steer the flow to the service functions specified by the flow's=0A= >>> service chain."=0A= >>>=0A= >>>=0A= >>> Linda=0A= >>> -----Original Message-----=0A= >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= >>> Sent: Wednesday, February 12, 2014 10:20 AM=0A= >>> To: sfc@ietf.org=0A= >>> Subject: [sfc] Framework=0A= >>>=0A= >>> I was looking at the framework proposal.=0A= >>> The proposal has a very specific model of the scope of the transport=0A= >>> header (that it is derived from, and relates only to, the first service= =0A= >>> function to which the packet will be directed.=0A= >>> That is clearly an operational model we need to support.=0A= >>>=0A= >>> However, I would like to allow other transport operational models, such= =0A= >>> as the use of a VLAN to direct traffic along a chain. Or the use of an= =0A= >>> MPLS label, or an MPLS label stack.=0A= >>>=0A= >>> Yours,=0A= >>> Joel M. Halpern=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >=0A= From Ron_Parker@affirmednetworks.com Wed Feb 12 14:29:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517A21A0015 for ; Wed, 12 Feb 2014 14:29:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAMnPGf-za05 for ; Wed, 12 Feb 2014 14:29:48 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8EB1A000B for ; Wed, 12 Feb 2014 14:29:48 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:29:47 -0800 From: Ron Parker To: "Pham, Chuong D" , "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPJ9QEcblK+6pjLEmXPle1ppKH4ZqytMIA//9+aoA= Date: Wed, 12 Feb 2014 22:29:46 +0000 Message-ID: References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 22:29:51 -0000 Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 jmh@joelhalpern.com Wed Feb 12 14:42:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B41A001A for ; Wed, 12 Feb 2014 14:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bGf3Fw2Waqpq for ; Wed, 12 Feb 2014 14:42:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3E1A000B for ; Wed, 12 Feb 2014 14:42:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DB18E3A0F86; Wed, 12 Feb 2014 14:42:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9D95C3A0EE0; Wed, 12 Feb 2014 14:42:01 -0800 (PST) Message-ID: <52FBF8BE.8020508@joelhalpern.com> Date: Wed, 12 Feb 2014 17:42:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sumandra Majee , Ron Parker , Linda Dunbar , "sfc@ietf.org" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> , <52FBDF98.3090206@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A0426F@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884A0426F@SEAEMBX01.olympus.F5Net.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:42:07 -0000 Protocol descriptions are usually done in documents separate from architecture documents. So yes, I am suggesting a different document. Whether the service header ends up in its own document, as it is now in the quinn nsh draft, or ends up folded into a document with other protocol behavior work, if such is needed, is up to the WG. Yours, Joel On 2/12/14, 5:27 PM, Sumandra Majee wrote: > Are you suggesting a different document? > > This would be required for interoperability so it is still part of *a* document. > ________________________________________ > From: Joel M. Halpern [jmh@joelhalpern.com] > Sent: Wednesday, February 12, 2014 12:54 PM > To: Sumandra Majee; Ron Parker; Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] Framework > > Sumandra, I would have to dsiagree with you. The structure of the > transport-independent service header (which will be carrying the > metadata) is very important, but not architectural. The existence of > such a header is very much architectural. > > Yours, > Joel > > On 2/12/14, 3:42 PM, Sumandra Majee wrote: >> Yep, that is possible. I would hope to see the header format captured in >> the architecture document itself. >> >> On 2/12/14, 12:10 PM, "Ron Parker" wrote: >> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I completely agree. I might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions (perhaps >>> similar to IPv6) but also had the header length encoded in the mandatory >>> part (like IPv4), then a hardware implementation would be free to skip >>> over the extensions (in cases where the deployment justifies ignoring the >>> extensions). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>> >>> >>> I agree. However the format of service header should be standardized in a >>> way that is flexible. Some of us would like to see variable length header >>> that is also HW friendly. The service header can be represented as a >>> mandotory fixed length header (like IP header) along with an optional >>> variable length attribute field. Different services can be interested in >>> different metadata, for example subscriber ID could be of interest in the >>> mobile core service chain only. >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >>> wrote: >>> >>>> Linda, >>>> >>>> My interpretation of the architecture docs is that the service function >>>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>>> Separately, a locator table provides network location for each of those >>>> service functions. In this way, you can locate the service functions in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP as a >>>> transport layer. >>>> >>>> For all of those reasons, I strongly support a canonical service header >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the fields >>>> in the transport header. That is, the SFC node discards the transport >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how to >>>> interpret the chain ID and ultimately how to progress the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>>> to steer the flow to the service functions specified by the flow's >>>> service chain." >>>> >>>> >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first service >>>> function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>> >>>> However, I would like to allow other transport operational models, such >>>> as the use of a VLAN to direct traffic along a chain. Or the use of an >>>> MPLS label, or an MPLS label stack. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> _______________________________________________ >>>> 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 Chuong.D.Pham@team.telstra.com Wed Feb 12 14:44:19 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC01A001D for ; Wed, 12 Feb 2014 14:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng7TbIUeAZtN for ; Wed, 12 Feb 2014 14:44:17 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7713A1A000B for ; Wed, 12 Feb 2014 14:44:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,835,1384261200"; d="scan'208";a="182933842" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 13 Feb 2014 09:44:13 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="192050998" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 13 Feb 2014 09:44:13 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 13 Feb 2014 09:44:13 +1100 From: "Pham, Chuong D" To: Ron Parker , "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 09:44:13 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPJ9QEcblK+6pjLEmXPle1ppKH4ZqytMIA//9+aoCAAAGRMA== Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 22:44:19 -0000 Ron, Yes, your interpretation of my example is correct. Did you agree that in th= is example, there will not be million's of SFCs? The classifier however will need to classify flows from million's of subscr= ibers. It needs to use packet fields AND out-of-band knowledge. In Mobile n= etwork, the IP address is allocated dynamically therefore it cannot be used= to identify users and associated services. Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, 13 February 2014 9:30 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 Ron_Parker@affirmednetworks.com Wed Feb 12 14:54:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92911A0019 for ; Wed, 12 Feb 2014 14:54:53 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHC2DbJ13iK0 for ; Wed, 12 Feb 2014 14:54:50 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id D54A11A001D for ; Wed, 12 Feb 2014 14:54:50 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 14:54:49 -0800 From: Ron Parker To: "Pham, Chuong D" , "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKEP6jSQGN0sNA0OmHawPMJweYZqyN7NA Date: Wed, 12 Feb 2014 22:54:49 +0000 Message-ID: References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 22:54:53 -0000 Chuong, Agree that there could be huge number of flows from huge number of subscrib= ers. The classifier's job is to figure out how to map each and every one = of them. =20 I'd like to make a distinction between the abstract chain, the actual chain= , and the ultimate path (I could use help on terminology, here). For a particular subscriber, the classifier has determined, using local mea= ns, that the subscriber shall be subject, in a general manner, to {SF-A, SF= -B, SF-C}. This is my "abstract chain" using my poor terminology. The= classifier has additional policy to say that SF-A need only be invoked for= UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of S= FC -- eliminate the need to bypass at the service function). So, we get t= he following possibilities after the classifier identifies the subscriber A= ND looks at the flow: UDP: { SF-A } TCP/80: {SF-B, SF-C} TCP/!80: {SF-C} Then, we consult the locator table and find that SF-A is located with IP-A,= SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2. When we finally reduce this to a set of paths, we get: { SF-A (IP-A) } {SF-B (IP-B1), SF-C (IP-C1)} {SF-B (IP-B2), SF-C (IP-C1)} {SF-B (IP-B1), SF-C (IP-C2)} {SF-B (IP-B2), SF-C (IP-C2)} {SF-C (IP-C1)} {SF-C (IP-C2)} Thoughts on the above? Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:44 PM To: Ron Parker; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Wi= ll); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, Yes, your interpretation of my example is correct. Did you agree that in th= is example, there will not be million's of SFCs? The classifier however will need to classify flows from million's of subscr= ibers. It needs to use packet fields AND out-of-band knowledge. In Mobile n= etwork, the IP address is allocated dynamically therefore it cannot be used= to identify users and associated services. Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, 13 February 2014 9:30 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 Chuong.D.Pham@team.telstra.com Wed Feb 12 15:07:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F261A000B for ; Wed, 12 Feb 2014 15:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozgVJBrqui81 for ; Wed, 12 Feb 2014 15:07:49 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DC3641A0024 for ; Wed, 12 Feb 2014 15:07:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,835,1384261200"; d="scan'208";a="172576259" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 13 Feb 2014 10:07:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="154493716" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdni.tcif.telstra.com.au with ESMTP; 13 Feb 2014 10:07:17 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 13 Feb 2014 10:07:16 +1100 From: "Pham, Chuong D" To: Ron Parker , "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 10:07:14 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKEP6jSQGN0sNA0OmHawPMJweYZqyN7NAgAAEPsA= Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983CCF4DA@WSMSG3154V.srv.dir.telstra.com> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 23:07:52 -0000 Ron, I only wanted to discuss the requirement for per-subscriber awareness in Mo= bile network. I guess you are taking this discussion further to aspects suc= h as how to apply local application-awareness, how to resolve SFs to IP add= resses in the classifier etc? I am not in a best position to comment on this as I believe the front-end c= lassifier should not have that much intelligence aka approaching the functi= onality of a DPI. The front-end should be simple, fast and scalable. Furthe= r application layer classification should be carried out in a SF node i.e. = forking etc. Regards, Chuong =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, 13 February 2014 9:55 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, Agree that there could be huge number of flows from huge number of subscrib= ers. The classifier's job is to figure out how to map each and every one = of them. =20 I'd like to make a distinction between the abstract chain, the actual chain= , and the ultimate path (I could use help on terminology, here). For a particular subscriber, the classifier has determined, using local mea= ns, that the subscriber shall be subject, in a general manner, to {SF-A, SF= -B, SF-C}. This is my "abstract chain" using my poor terminology. The= classifier has additional policy to say that SF-A need only be invoked for= UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of S= FC -- eliminate the need to bypass at the service function). So, we get t= he following possibilities after the classifier identifies the subscriber A= ND looks at the flow: UDP: { SF-A } TCP/80: {SF-B, SF-C} TCP/!80: {SF-C} Then, we consult the locator table and find that SF-A is located with IP-A,= SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2. When we finally reduce this to a set of paths, we get: { SF-A (IP-A) } {SF-B (IP-B1), SF-C (IP-C1)} {SF-B (IP-B2), SF-C (IP-C1)} {SF-B (IP-B1), SF-C (IP-C2)} {SF-B (IP-B2), SF-C (IP-C2)} {SF-C (IP-C1)} {SF-C (IP-C2)} Thoughts on the above? Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:44 PM To: Ron Parker; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Wi= ll); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, Yes, your interpretation of my example is correct. Did you agree that in th= is example, there will not be million's of SFCs? The classifier however will need to classify flows from million's of subscr= ibers. It needs to use packet fields AND out-of-band knowledge. In Mobile n= etwork, the IP address is allocated dynamically therefore it cannot be used= to identify users and associated services. Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, 13 February 2014 9:30 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 ddolson@sandvine.com Wed Feb 12 15:32:26 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406801A0039 for ; Wed, 12 Feb 2014 15:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 NPl2wY2LEgb8 for ; Wed, 12 Feb 2014 15:32:22 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 31C781A001F for ; Wed, 12 Feb 2014 15:32:22 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Wed, 12 Feb 2014 18:32:20 -0500 From: Dave Dolson To: "'Chuong.D.Pham@team.telstra.com'" , "'Ron_Parker@affirmednetworks.com'" , "'mohamed.boucadair@orange.com'" , "'agoldner@allot.com'" , "'liushucheng@huawei.com'" , "'sfc@ietf.org'" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKEWbK8DDKz1Ft02KW2hPg+JgiZqykZsA//+zMwQ= Date: Wed, 12 Feb 2014 23:32:20 +0000 Message-ID: In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983CCF4DA@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 23:32:26 -0000 On the contrary, a device that is subscriber-aware and capable of DPI is ve= ry good to have in the role of Classifier. ----- Original Message ----- From: Pham, Chuong D [mailto:Chuong.D.Pham@team.telstra.com] Sent: Wednesday, February 12, 2014 06:07 PM=0A= To: Ron Parker ; mohamed.boucadair@orange.= com ; Alla Goldner ; Lius= hucheng (Will) ; sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, I only wanted to discuss the requirement for per-subscriber awareness in Mo= bile network. I guess you are taking this discussion further to aspects suc= h as how to apply local application-awareness, how to resolve SFs to IP add= resses in the classifier etc? I am not in a best position to comment on this as I believe the front-end c= lassifier should not have that much intelligence aka approaching the functi= onality of a DPI. The front-end should be simple, fast and scalable. Furthe= r application layer classification should be carried out in a SF node i.e. = forking etc. Regards, Chuong =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, 13 February 2014 9:55 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, Agree that there could be huge number of flows from huge number of subscrib= ers. The classifier's job is to figure out how to map each and every one = of them. =20 I'd like to make a distinction between the abstract chain, the actual chain= , and the ultimate path (I could use help on terminology, here). For a particular subscriber, the classifier has determined, using local mea= ns, that the subscriber shall be subject, in a general manner, to {SF-A, SF= -B, SF-C}. This is my "abstract chain" using my poor terminology. The= classifier has additional policy to say that SF-A need only be invoked for= UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of S= FC -- eliminate the need to bypass at the service function). So, we get t= he following possibilities after the classifier identifies the subscriber A= ND looks at the flow: UDP: { SF-A } TCP/80: {SF-B, SF-C} TCP/!80: {SF-C} Then, we consult the locator table and find that SF-A is located with IP-A,= SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2. When we finally reduce this to a set of paths, we get: { SF-A (IP-A) } {SF-B (IP-B1), SF-C (IP-C1)} {SF-B (IP-B2), SF-C (IP-C1)} {SF-B (IP-B1), SF-C (IP-C2)} {SF-B (IP-B2), SF-C (IP-C2)} {SF-C (IP-C1)} {SF-C (IP-C2)} Thoughts on the above? Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:44 PM To: Ron Parker; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Wi= ll); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, Yes, your interpretation of my example is correct. Did you agree that in th= is example, there will not be million's of SFCs? The classifier however will need to classify flows from million's of subscr= ibers. It needs to use packet fields AND out-of-band knowledge. In Mobile n= etwork, the IP address is allocated dynamically therefore it cannot be used= to identify users and associated services. Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, 13 February 2014 9:30 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 Chuong.D.Pham@team.telstra.com Wed Feb 12 15:40:20 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141EA1A0040 for ; Wed, 12 Feb 2014 15:40:20 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...A7A58BE@MBX021-W3-CA-2.exch021.domain.local>\n X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0fsnwkfF4WZ for ; Wed, 12 Feb 2014 15:40:17 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id C51921A001F for ; Wed, 12 Feb 2014 15:40:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,835,1384261200"; d="scan'208";a="185054661" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 13 Feb 2014 10:40:14 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7347"; a="197647966" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 13 Feb 2014 10:40:14 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 13 Feb 2014 10:40:13 +1100 From: "Pham, Chuong D" To: Ron Parker , "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 10:40:12 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKEP6jSQGN0sNA0OmHawPMJweYZqyN7NAgAAEPsCAAAdWMA== Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983CCF5A8@WSMSG3154V.srv.dir.telstra.com> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Wed, 12 Feb 2014 23:40:20 -0000 Ron, Correction on my comment: Your discussion was not necessarily about application layer intelligence as= such. I think you were discussing additional local policies in the classif= ier (layer 4 information in your email below but I am not sure if you have = layer 7 in mind as well) in addition to subscription information which all = together will be used to steer traffic to the correct SFC. I don't have any= issue with your suggestion. Additionally I see three distinct "categories" of services (or more in the = future). Category A is subscription-based services such as Parental Control= , category B is traffic management based such as TCP optimisation or video = optimisation, category C is Service Provider's mandate SF such Gi FW. How t= o take flows through services in these three categories is tricky and your = example of using layer 4 information in steering seems to indicate to me yo= u were thinking about category B? Regards, Chuong =20 -----Original Message----- From: Pham, Chuong D=20 Sent: Thursday, 13 February 2014 10:07 AM To: 'Ron Parker'; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (= Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, I only wanted to discuss the requirement for per-subscriber awareness in Mo= bile network. I guess you are taking this discussion further to aspects suc= h as how to apply local application-awareness, how to resolve SFs to IP add= resses in the classifier etc? I am not in a best position to comment on this as I believe the front-end c= lassifier should not have that much intelligence aka approaching the functi= onality of a DPI. The front-end should be simple, fast and scalable. Furthe= r application layer classification should be carried out in a SF node i.e. = forking etc. Regards, Chuong =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, 13 February 2014 9:55 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, Agree that there could be huge number of flows from huge number of subscrib= ers. The classifier's job is to figure out how to map each and every one = of them. =20 I'd like to make a distinction between the abstract chain, the actual chain= , and the ultimate path (I could use help on terminology, here). For a particular subscriber, the classifier has determined, using local mea= ns, that the subscriber shall be subject, in a general manner, to {SF-A, SF= -B, SF-C}. This is my "abstract chain" using my poor terminology. The= classifier has additional policy to say that SF-A need only be invoked for= UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of S= FC -- eliminate the need to bypass at the service function). So, we get t= he following possibilities after the classifier identifies the subscriber A= ND looks at the flow: UDP: { SF-A } TCP/80: {SF-B, SF-C} TCP/!80: {SF-C} Then, we consult the locator table and find that SF-A is located with IP-A,= SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2. When we finally reduce this to a set of paths, we get: { SF-A (IP-A) } {SF-B (IP-B1), SF-C (IP-C1)} {SF-B (IP-B2), SF-C (IP-C1)} {SF-B (IP-B1), SF-C (IP-C2)} {SF-B (IP-B2), SF-C (IP-C2)} {SF-C (IP-C1)} {SF-C (IP-C2)} Thoughts on the above? Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:44 PM To: Ron Parker; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Wi= ll); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Ron, Yes, your interpretation of my example is correct. Did you agree that in th= is example, there will not be million's of SFCs? The classifier however will need to classify flows from million's of subscr= ibers. It needs to use packet fields AND out-of-band knowledge. In Mobile n= etwork, the IP address is allocated dynamically therefore it cannot be used= to identify users and associated services. Regards, Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, 13 February 2014 9:30 AM To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Chuong, In your example, I would expect 3 chains: Chain_Child =3D { content-filter } Chain_Qos =3D { qos } Chain_Child_Qos { content-filter, qos } The classifier, using packet fields like source-ip and dest-ip, or using so= me out-of-band knowledge, would assign all of the flows to/from the child s= ubscribers to Chain_Child, all flows to/from the child_qos subscribers to C= hain_Child_Qos, etc. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Wednesday, February 12, 2014 5:10 PM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Hi Med, Actually the scalability issue is pertaining to the need to have subscriber= -awareness so that subscribers are assigned to the correct groups. For exam= ple, subscriber-A belongs to Parental Control group, subscriber-B belongs t= o QoS-enabled group, subscriber-C belongs to a group which has both Parenta= l Control and QoS-enabled. The number of SFCs will be the same (permutation of service functions are t= he same), however the need to have visibility of subscriber's IP address (d= ynamically assigned in Mobile network), subscriber identity i.e. the phone = number and the services that the subscriber have subscribed to is where the= scalability concern is IMHO.=20 So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-6= is still valid and my input adds the ability to recognise flows from indiv= idual mobile users and assign them to a correct group of subscribers who sh= are a same SFC. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, 12 February 2014 8:23 PM To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Chuong, Thank you for the inputs. The draft will be updated to reflect most of your= points.=20 As for the per-subscriber SFC, the scalability discussion is already record= ed here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#sec= tion-6. Beside considerations on scalability, what is really helpful is to = identify *** concrete *** use cases that would require such per-subscriber = SFCs (that would lead to instantiating millions of SFCs in a domain): i.e.,= are there real business motivations to configure customized service chains= for each subscriber? Wouldn't be realistic to assume chains for groups of = subscribers? Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liushu= cheng=20 >(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi Liushucheng, > >There is also the case where a service function is selected based on=20 >user subscription. For example, steering traffic to a Parental Control >(PC) only for the flows belonging to users who have PC subscription.=20 >One way of doing it is for the PCRF to notify the classifier about the=20 >correct flows to expect prior to the arrival of these flows. > >Other example is steering traffic to a DPI based on users with QoS=20 >subscriptions for the purpose of reporting and optionally enforcement. > >Another example is when a user wants to opt-out of service functions=20 >such as an Operator-mandate video optimisation platform for reasons=20 >such as the user is a Gold user with QoS and requirements for high resolut= ion video. > >To me, user subscription based traffic steering/servicing chaining is=20 >important for Mobile and at the same time, it poses great challenge on=20 >scalability therefore it is worthwhile to be included in your draft. > > >Regards, >Chuong > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Tuesday, 11 February 2014 9:53 PM >To: Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS >23.203 where Traffic Detection Function (TDF) is a standardized element=20 >residing on Gi/SGi which implements DPI (detection) functionality along=20 >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 >9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the=20 >section of Use Case of Service Function Chain in Mobile Core Network. >Looking forward to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie=20 >Hu; Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >successfully submitted by Will(Shucheng) Liu and posted to the IETF reposi= tory. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### > > >_______________________________________________ >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 Ron_Parker@affirmednetworks.com Wed Feb 12 16:20:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DC1A0051 for ; Wed, 12 Feb 2014 16:20:53 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgdCq0DMTF-0 for ; Wed, 12 Feb 2014 16:20:49 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 575DA1A0054 for ; Wed, 12 Feb 2014 16:20:48 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 16:20:47 -0800 From: Ron Parker To: "Pham, Chuong D" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKEP6jSQGN0sNA0OmHawPMJweYZqyN7NAgAAEPsCAAAdWMIAADxMu Date: Thu, 13 Feb 2014 00:20:46 +0000 Message-ID: References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> <5602569641FB314FB4D9AD5659D41B9C2983CCF41C@WSMSG3154V.srv.dir.telstra.com> ,<5602569641FB314FB4D9AD5659D41B9C2983CCF5A8@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983CCF5A8@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alla Goldner , "mohamed.boucadair@orange.com" , "Liushucheng \(Will\)" , "sfc@ietf.org" Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 00:20:53 -0000 Chuong,=20 My example was based on out of band subscriber knowledge plus shallow packe= t inspection. In general, steering via layer 7 heuristic DPI conclusions = doesn't work because the conclusions come on packet n of the flow (I'm not = talking about history-based heuristic steering mechanisms here). However, y= ou should look at the recently posted draft-ma-sfc for a discussion of tran= saction oriented SFC which I feel is a very important (and complex) aspect = that has not received discussion yet.=20 Regarding your categorization of service functions, I think that is outside= of SFC scope -- the classifier is free to incorporate any knowledge it has= and apply any business logic it is capable of.=20 Ron > On Feb 12, 2014, at 6:40 PM, "Pham, Chuong D" wrote: >=20 > Ron, > Correction on my comment: > Your discussion was not necessarily about application layer intelligence = as such. I think you were discussing additional local policies in the class= ifier (layer 4 information in your email below but I am not sure if you hav= e layer 7 in mind as well) in addition to subscription information which al= l together will be used to steer traffic to the correct SFC. I don't have a= ny issue with your suggestion. >=20 > Additionally I see three distinct "categories" of services (or more in th= e future). Category A is subscription-based services such as Parental Contr= ol, category B is traffic management based such as TCP optimisation or vide= o optimisation, category C is Service Provider's mandate SF such Gi FW. How= to take flows through services in these three categories is tricky and you= r example of using layer 4 information in steering seems to indicate to me = you were thinking about category B? >=20 > Regards, > Chuong =20 >=20 > -----Original Message----- > From: Pham, Chuong D=20 > Sent: Thursday, 13 February 2014 10:07 AM > To: 'Ron Parker'; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng= (Will); sfc@ietf.org > Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Ron, > I only wanted to discuss the requirement for per-subscriber awareness in = Mobile network. I guess you are taking this discussion further to aspects s= uch as how to apply local application-awareness, how to resolve SFs to IP a= ddresses in the classifier etc? > I am not in a best position to comment on this as I believe the front-end= classifier should not have that much intelligence aka approaching the func= tionality of a DPI. The front-end should be simple, fast and scalable. Furt= her application layer classification should be carried out in a SF node i.e= . forking etc. > Regards, > Chuong >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, 13 February 2014 9:55 AM > To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushuche= ng (Will); sfc@ietf.org > Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Chuong, >=20 > Agree that there could be huge number of flows from huge number of subscr= ibers. The classifier's job is to figure out how to map each and every on= e of them. =20 >=20 > I'd like to make a distinction between the abstract chain, the actual cha= in, and the ultimate path (I could use help on terminology, here). >=20 > For a particular subscriber, the classifier has determined, using local m= eans, that the subscriber shall be subject, in a general manner, to {SF-A, = SF-B, SF-C}. This is my "abstract chain" using my poor terminology. T= he classifier has additional policy to say that SF-A need only be invoked f= or UDP, SF-B for TCP and SF-C for TCP/80 (this being one of the benefits of= SFC -- eliminate the need to bypass at the service function). So, we get= the following possibilities after the classifier identifies the subscriber= AND looks at the flow: >=20 > UDP: { SF-A } > TCP/80: {SF-B, SF-C} > TCP/!80: {SF-C} >=20 > Then, we consult the locator table and find that SF-A is located with IP-= A, SF-B with IP-B1 and IP-B2, SF-C with IP-C1 and IP-C2. >=20 > When we finally reduce this to a set of paths, we get: >=20 > { SF-A (IP-A) } > {SF-B (IP-B1), SF-C (IP-C1)} > {SF-B (IP-B2), SF-C (IP-C1)} > {SF-B (IP-B1), SF-C (IP-C2)} > {SF-B (IP-B2), SF-C (IP-C2)} > {SF-C (IP-C1)} > {SF-C (IP-C2)} >=20 > Thoughts on the above? >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 12, 2014 5:44 PM > To: Ron Parker; mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (= Will); sfc@ietf.org > Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Ron, > Yes, your interpretation of my example is correct. Did you agree that in = this example, there will not be million's of SFCs? > The classifier however will need to classify flows from million's of subs= cribers. It needs to use packet fields AND out-of-band knowledge. In Mobile= network, the IP address is allocated dynamically therefore it cannot be us= ed to identify users and associated services. > Regards, > Chuong >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Thursday, 13 February 2014 9:30 AM > To: Pham, Chuong D; mohamed.boucadair@orange.com; Alla Goldner; Liushuche= ng (Will); sfc@ietf.org > Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Chuong, >=20 > In your example, I would expect 3 chains: >=20 > Chain_Child =3D { content-filter } > Chain_Qos =3D { qos } > Chain_Child_Qos { content-filter, qos } >=20 >=20 > The classifier, using packet fields like source-ip and dest-ip, or using = some out-of-band knowledge, would assign all of the flows to/from the child= subscribers to Chain_Child, all flows to/from the child_qos subscribers to= Chain_Child_Qos, etc. >=20 >=20 > Ron >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D > Sent: Wednesday, February 12, 2014 5:10 PM > To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@i= etf.org > Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Hi Med, >=20 > Actually the scalability issue is pertaining to the need to have subscrib= er-awareness so that subscribers are assigned to the correct groups. For ex= ample, subscriber-A belongs to Parental Control group, subscriber-B belongs= to QoS-enabled group, subscriber-C belongs to a group which has both Paren= tal Control and QoS-enabled. >=20 > The number of SFCs will be the same (permutation of service functions are= the same), however the need to have visibility of subscriber's IP address = (dynamically assigned in Mobile network), subscriber identity i.e. the phon= e number and the services that the subscriber have subscribed to is where t= he scalability concern is IMHO.=20 >=20 > So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section= -6 is still valid and my input adds the ability to recognise flows from ind= ividual mobile users and assign them to a correct group of subscribers who = share a same SFC. >=20 > Regards, > Chuong >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, 12 February 2014 8:23 PM > To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org > Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt >=20 > Dear Chuong, >=20 > Thank you for the inputs. The draft will be updated to reflect most of yo= ur points.=20 >=20 > As for the per-subscriber SFC, the scalability discussion is already reco= rded here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#s= ection-6. Beside considerations on scalability, what is really helpful is t= o identify *** concrete *** use cases that would require such per-subscribe= r SFCs (that would lead to instantiating millions of SFCs in a domain): i.e= ., are there real business motivations to configure customized service chai= ns for each subscriber? Wouldn't be realistic to assume chains for groups o= f subscribers? >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D=20 >> Envoy=E9 : mercredi 12 f=E9vrier 2014 02:59 =C0 : Alla Goldner; Liushuch= eng=20 >> (Will); sfc@ietf.org Objet : Re: [sfc] FW: New Version Notification for >> draft-liu-sfc-use-cases- 01.txt >>=20 >> Hi Liushucheng, >>=20 >> There is also the case where a service function is selected based on=20 >> user subscription. For example, steering traffic to a Parental Control >> (PC) only for the flows belonging to users who have PC subscription.=20 >> One way of doing it is for the PCRF to notify the classifier about the=20 >> correct flows to expect prior to the arrival of these flows. >>=20 >> Other example is steering traffic to a DPI based on users with QoS=20 >> subscriptions for the purpose of reporting and optionally enforcement. >>=20 >> Another example is when a user wants to opt-out of service functions=20 >> such as an Operator-mandate video optimisation platform for reasons=20 >> such as the user is a Gold user with QoS and requirements for high resol= ution video. >>=20 >> To me, user subscription based traffic steering/servicing chaining is=20 >> important for Mobile and at the same time, it poses great challenge on=20 >> scalability therefore it is worthwhile to be included in your draft. >>=20 >>=20 >> Regards, >> Chuong >>=20 >> -----Original Message----- >> From: Alla Goldner [mailto:agoldner@allot.com] >> Sent: Tuesday, 11 February 2014 9:53 PM >> To: Liushucheng (Will); sfc@ietf.org >> Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >> cases-01.txt >>=20 >> Dear Shucheng, >>=20 >> With regard to this use case description, it would be useful, in my=20 >> opinion, referring to the existing 3GPP architecture as per 3GPP TS >> 23.203 where Traffic Detection Function (TDF) is a standardized element= =20 >> residing on Gi/SGi which implements DPI (detection) functionality along= =20 >> with enforcement and charging of the corresponding detected=20 >> applications. This is missing from your use case description. I think=20 >> such a comment was already provided in a different email thread. >>=20 >> Best Regards, >>=20 >>=20 >> Alla Goldner >> Director of Mobile Technologies and Standards Allot Communications Tel >> +972 >> 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 >> www.allot.com >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >> Sent: Tuesday, February 11, 2014 11:18 AM >> To: sfc@ietf.org >> Subject: [sfc] FW: New Version Notification for >> draft-liu-sfc-use-cases- 01.txt >>=20 >> Hi all, >>=20 >> We've just updated our use case draft. The main change is in the=20 >> section of Use Case of Service Function Chain in Mobile Core Network. >> Looking forward to your comments. >>=20 >> Regards, >> Shucheng (Will) >>=20 >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, February 11, 2014 5:14 PM >> To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >> Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai=20 >> Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie= =20 >> Hu; Huangyong (Oliver) >> Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>=20 >>=20 >> A new version of I-D, draft-liu-sfc-use-cases-01.txt has been=20 >> successfully submitted by Will(Shucheng) Liu and posted to the IETF repo= sitory. >>=20 >> Name: draft-liu-sfc-use-cases >> Revision: 01 >> Title: Service Function Chaining (SFC) Use Cases >> Document date: 2014-02-11 >> Group: Individual Submission >> Pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >> cases-01.txt >> Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >> Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es-01 >>=20 >> Abstract: >> The delivery of value-added services relies on the invocation of >> advanced Service Functions in a sequential order. This mechanism is >> called Service Function Chaining (SFC). The set of involved Service >> Functions and their order depends on the service context. >>=20 >> This document presents a set of use cases of Service Function >> Chaining (SFC). >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> ####################################################################### >> #### >> ################### >> This message is intended only for the designated recipient(s).It may=20 >> contain confidential or proprietary information. >> If you are not the designated recipient, you may not review, copy or=20 >> distribute this message. >> If you have mistakenly received this message, please notify the sender=20 >> by a reply e-mail and delete this message. >> Thank you. >> ####################################################################### >> #### >> ################### >>=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 agoldner@allot.com Wed Feb 12 22:17:42 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6541A00F5 for ; Wed, 12 Feb 2014 22:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 3g1LJ-w8DNp7 for ; Wed, 12 Feb 2014 22:17:37 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 227551A010E for ; Wed, 12 Feb 2014 22:17:36 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 08:17:33 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:17:33 +0200 From: Alla Goldner To: Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf1aUaggCMCUS7T9nUlmVBtJqmCQKAgAH2hQCAAmPrAIADhxoAgAROqDCAAI+EoA== Date: Thu, 13 Feb 2014 06:17:32 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 06:17:42 -0000 Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Functi= on) for providing ADC (Application Detection and Control) Rules for appli= cation detection, enforcement and also charging starting from R12. Please= =20see architecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with = the GGSN (via Diameter), not the service functions, do you mean "for the = GGSN (or the flow classifier) to carry the data passed down from PCRF to = packets' metadata field to service functions on the chain"?" Furthermore, also the claim that=20 "The P-GW/PCEF (per 3GPP terminology) determines the desired service trea= tment, i.e. desired sequence of service functions, to specific flows base= d on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions." is not correct as we= ll as PGW/PCEF is not the only element which enforces different support p= er different flows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architect= ure and make assumptions and conclusions about potential 3GPP elements fu= nctionality which are not in scope of IETF. If we want to define use case= s for 3GPP networks, then we should show correct picture of 3GPP archite= cture without redesigning it and leave 3GPP Network Elements functionalit= y potential extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson= ; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and = service related metadata delivered from mobile control plane function lik= e PCRF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the = service functions, do you mean "for the GGSN (or the flow classifier) to = carry the data passed down from PCRF to packets' metadata field to servic= e functions on the chain"? Since the policies passed down by PCRF usually can't be understood by ser= vice functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related i= nformation, that are either embedded in packets as metadata or passed dow= n from control plane, to process the flows according to service related = policies" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" = used in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN ha= s a VLAN-ID?=20 I understand that some common classification scheme could be encoding a c= ertain QoS to a specific flow, applying some security functions to some f= lows, etc. The classification node can use simple VLAN-ID to mark differe= nt classification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC = BOF is very good.=20 Walter's wireless example is described in the Section 3.2 of https://data= tracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the sugge= sted text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treat= ment, i.e. desired sequence of service functions, to specific flows based= =20on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions.=20 =20 =20 | Mobile backhaul Network =20 =20 +-----+ | +---+---+ =20 =20 |PCRF | | |Network| =20 =20 | | < ---- > |Ctrller| =20 =20 +-----+ | +----+--+=20 =20 | | =20 =20 | | =20 =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> =20 | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> =20 | [PCEF]| | |Optimizer| | |=20 =20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> =20 | | | | | | |=20 =20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Hi Linda, First, thanks for the feedback. While it may look like a lot of component= s, we still have simplified 3GPP quite a lot. For example, in the first d= raft we left out the TDF that appears in recent standards. We=B9ll be add= ing that in response to other comments. I believe the overview section is= =20still quite short, but we will try to shorten it a bit further if it i= s too long. If you feel anything in particular is missing or extraneous, = please let us know. Yes, it is probably overkill to have two example APNs. The User & Pass ar= e important for example in cases of hot-lining where the user must first = be authenticated (for various reasons) before data services are provided/= continued. It is just another example of the important relationship betwe= en Classification (in an SFC sense) and Policy and Charging (in a 3GPP se= nse). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave = Dolson , Martin Stiemerling , "= draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph = >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not = >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile= >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statement= s > of the working group. > > Service function chains typically reside in a LAN segment which link= s > the mobile access network to the actual application platforms locate= d > in the carrier's datacenters or somewhere else in the Internet. > Service function chains ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy o= r > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From prvs=114c97483=Nicolas.BOUTHORS@qosmos.com Thu Feb 13 01:13:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A621A018B for ; Thu, 13 Feb 2014 01:13:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVEBL9VmATk1 for ; Thu, 13 Feb 2014 01:13:46 -0800 (PST) Received: from smtp-ft1.fr.colt.net (smtp-ft1.fr.colt.net [213.41.78.210]) by ietfa.amsl.com (Postfix) with ESMTP id B33671A00FA for ; Thu, 13 Feb 2014 01:13:45 -0800 (PST) Received: from smtp-ex5.fr.colt.net (smtp-ex5.fr.colt.net [213.41.78.121]) by smtp-ft1.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1D9DhkT028621 for ; Thu, 13 Feb 2014 10:13:43 +0100 Received: from mx3.qosmos.eu ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex5.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WDsMX-0001Bc-1l for ; Thu, 13 Feb 2014 10:13:42 +0100 X-IronPort-AV: E=Sophos;i="4.95,837,1384297200"; d="scan'208";a="849748" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 13 Feb 2014 10:13:36 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Thu, 13 Feb 2014 10:13:40 +0100 From: Nicolas BOUTHORS To: Ron Parker , Dave Dolson , "Joel M. Halpern" , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKEH5XiHhbmNdIkmkarO0TCcKBJqy5XDv Date: Thu, 13 Feb 2014 09:13:35 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBE7F3.1050605@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:13:51 -0000 If we do not enforce a fix header size we have other implication.=0A= =0A= There is the question of segmentation and reassembly responsibility as well= .=0A= =0A= If adding length to the service header forces segmentation, then whose resp= onsibility is it=0A= to reassemble the payload before passing it to the SF. =0A= =0A= Similar question for packet re-ordering.=0A= =0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Wednesday, February 12, 2014 11:25 PM=0A= To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq)=0A= Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar=0A= Subject: Re: [sfc] Framework=0A= =0A= Dave,=0A= =0A= Yes, that is a good point if we logically separate the forwarding function = from the SFC-aware service function, as we should. The forwarding functio= n is concerned with only the inbound transport header, the fixed portion of= the service header containing the chain information, and the outbound tran= sport header. The service function may look at the entirety of the servi= ce header and would look at the encapsulated packet.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Dave Dolson [mailto:ddolson@sandvine.com]=0A= Sent: Wednesday, February 12, 2014 5:18 PM=0A= To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq)=0A= Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar=0A= Subject: RE: [sfc] Framework=0A= =0A= The forwarding plane might not even need to look at the encapsulated packet= .=0A= =0A= For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can f= orward packets of the form: Ether | VLAN | BLOB.=0A= =0A= =0A= =0A= -----Original Message-----=0A= From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= Sent: Wednesday, February 12, 2014 4:30 PM=0A= To: Ron Parker; Dave Dolson; Paul Quinn (paulq)=0A= Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar=0A= Subject: Re: [sfc] Framework=0A= =0A= I agree as well.=0A= Yours,=0A= Joel=0A= =0A= On 2/12/14, 4:24 PM, Ron Parker wrote:=0A= > Hi, Dave.=0A= >=0A= > I Agree with your statement. And if the total length of the header is= contained in the mandatory portion, the hardware implementation can easily= locate the encapsulated packet.=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Dave Dolson [mailto:ddolson@sandvine.com]=0A= > Sent: Wednesday, February 12, 2014 4:10 PM=0A= > To: Ron Parker; Paul Quinn (paulq)=0A= > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar=0A= > Subject: RE: [sfc] Framework=0A= >=0A= > I think a good approach would be:=0A= >=0A= > The information required for forwarding (the SF Identifier) should be in = a mandatory fixed-size header.=0A= >=0A= > Optional information (if any) is NOT to be used for forwarding, but is fo= r consumption by one or more of the applications in the chain.=0A= >=0A= > Then the forwarding plane, and even the PDP, can be agnostic about the me= ta-data.=0A= >=0A= > -Dave=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker=0A= > Sent: Wednesday, February 12, 2014 4:05 PM=0A= > To: Paul Quinn (paulq)=0A= > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar=0A= > Subject: Re: [sfc] Framework=0A= >=0A= > Paul,=0A= >=0A= > That is why I am proposing a hybrid where extensions or options can be ad= ded but the total length is contained in the fixed portion. I can envisio= n certain deployments (e.g., Enterprise) where perhaps extensions are not n= eeded and the SFC functionality is realized in hardware. And, I can envis= ion certain other deployments (e.g., 3gpp) where the extension headers add = sufficient value to justify software based implementations.=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=0A= > Sent: Wednesday, February 12, 2014 3:40 PM=0A= > To: Ron Parker=0A= > Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org=0A= > Subject: Re: [sfc] Framework=0A= >=0A= > Hi,=0A= >=0A= > We certainly need to be very careful with variable length headers when ha= rdware platform are in play.=0A= >=0A= > Ron, your examples of IP options and v6 EH have both suffered from signif= icant implementation and deployment hurdles due to the complexity and cost = associated with hardware support for the option/EH.=0A= >=0A= > Paul=0A= >=0A= > On Feb 12, 2014, at 3:10 PM, Ron Parker = wrote:=0A= >=0A= >> Hi, Sumandra.=0A= >>=0A= >> Regarding service header flexibility, I completely agree. I might sugg= est a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) = but also had the header length encoded in the mandatory part (like IPv4), t= hen a hardware implementation would be free to skip over the extensions (in= cases where the deployment justifies ignoring the extensions).=0A= >>=0A= >> Ron=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >> Sent: Wednesday, February 12, 2014 3:04 PM=0A= >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org=0A= >> Subject: Re: [sfc] Framework=0A= >>=0A= >>>> For all of those reasons, I strongly support a canonical service=0A= >>>> header that is independent of the transport methodology.=0A= >>=0A= >>=0A= >> I agree. However the format of service header should be standardized in = a way that is flexible. Some of us would like to see variable length header= that is also HW friendly. The service header can be represented as a mando= tory fixed length header (like IP header) along with an optional variable l= ength attribute field. Different services can be interested in different me= tadata, for example subscriber ID could be of interest in the mobile core s= ervice chain only.=0A= >>=0A= >> Sumandra=0A= >>=0A= >> On 2/12/14, 11:32 AM, "Ron Parker" wro= te:=0A= >>=0A= >>> Linda,=0A= >>>=0A= >>> My interpretation of the architecture docs is that the service=0A= >>> function chain is built in an abstract manner (i.e., SF-A then SF-B the= n SF-C).=0A= >>> Separately, a locator table provides network location for each of those= =0A= >>> service functions. In this way, you can locate the service functions = in=0A= >>> a manner appropriate to the type of transport you are using. If you= =0A= >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address= ,=0A= >>> GRE tunnel remote IP + key, etc., you can do that. You can even=0A= >>> potentially locate different service functions that reside in the same= =0A= >>> chain with different flavors of network locators. Another=0A= >>> justification to separate the identity of a service function from its= =0A= >>> network location is load balancing. If, for example, SF-A had 3 IP=0A= >>> addresses, that would imply load balancing to 3 instances using IP=0A= >>> as a transport layer.=0A= >>>=0A= >>> For all of those reasons, I strongly support a canonical service header= =0A= >>> that is independent of the transport methodology. At a particular=0A= >>> node, the decision as to where to go next should be based solely on=0A= >>> information carried in the canonical service header and not on the fiel= ds=0A= >>> in the transport header. That is, the SFC node discards the transport= =0A= >>> header and extracts the chain ID from the service header. Through=0A= >>> mechanisms we have not yet begun to discuss, the SFC node knows how=0A= >>> to interpret the chain ID and ultimately how to progress the packet.=0A= >>>=0A= >>> Ron=0A= >>>=0A= >>>=0A= >>> -----Original Message-----=0A= >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar=0A= >>> Sent: Wednesday, February 12, 2014 12:01 PM=0A= >>> To: Joel M. Halpern; sfc@ietf.org=0A= >>> Subject: Re: [sfc] Framework=0A= >>>=0A= >>> Agree with Joel's statement.=0A= >>>=0A= >>> I think a simple sentence below should be added Section 5.2 (SFC=0A= >>> Classifier) to emphasize this point.=0A= >>>=0A= >>> "A Service Chain Classifier node can associate a unique Layer 2 or= =0A= >>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those=0A= >>> Layer=0A= >>> 2 or 3 Label makes it easier for subsequent nodes along the flow=0A= >>> path to steer the flow to the service functions specified by the=0A= >>> flow's service chain."=0A= >>>=0A= >>>=0A= >>> Linda=0A= >>> -----Original Message-----=0A= >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= >>> Sent: Wednesday, February 12, 2014 10:20 AM=0A= >>> To: sfc@ietf.org=0A= >>> Subject: [sfc] Framework=0A= >>>=0A= >>> I was looking at the framework proposal.=0A= >>> The proposal has a very specific model of the scope of the transport=0A= >>> header (that it is derived from, and relates only to, the first=0A= >>> service function to which the packet will be directed.=0A= >>> That is clearly an operational model we need to support.=0A= >>>=0A= >>> However, I would like to allow other transport operational models,=0A= >>> such as the use of a VLAN to direct traffic along a chain. Or the=0A= >>> use of an MPLS label, or an MPLS label stack.=0A= >>>=0A= >>> Yours,=0A= >>> Joel M. Halpern=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= > _______________________________________________=0A= > sfc mailing list=0A= > sfc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= =0A= =0A= From mohamed.boucadair@orange.com Thu Feb 13 01:20:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47541A0177 for ; Thu, 13 Feb 2014 01:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RC-RY9xYVDAK for ; Thu, 13 Feb 2014 01:20:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A81A00FA for ; Thu, 13 Feb 2014 01:20:50 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id D54B419069C; Thu, 13 Feb 2014 10:20:48 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B88303840DE; Thu, 13 Feb 2014 10:20:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 13 Feb 2014 10:20:48 +0100 From: To: "Pham, Chuong D" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 10:20:47 +0100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8nPsI8wx0hXPcgRj6Hybf/H728gQAVehGQAA+ZyCAAGqORUAAXkF6w Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E97E@PUEXCB1B.nanterre.francetelecom.fr> References: <5602569641FB314FB4D9AD5659D41B9C2983C1CBF1@WSMSG3154V.srv.dir.telstra.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3C96@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983CCF342@WSMSG3154V.srv.dir.telstra.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 09:20:53 -0000 Hi Chuong, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 23:10 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Alla Goldner; Liushucheng (Will); >sfc@ietf.org >Objet=A0: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es- >01.txt > >Hi Med, > >Actually the scalability issue is pertaining to the need to have >subscriber-awareness so that subscribers are assigned to the correct >groups. [Med] I see; you are referring to the classification rules not the set of S= FC themselves.=20 For example, subscriber-A belongs to Parental Control group, >subscriber-B belongs to QoS-enabled group, subscriber-C belongs to a group >which has both Parental Control and QoS-enabled. [Med] This is what I have in mind too: limited number of SFCs but classific= ations rules can be triggered by per-subscriber info. That's really differe= nt that allowing customized set of SFC on a per-subscriber basis. This subt= lety should be recorded in one of existing drafts. > >The number of SFCs will be the same (permutation of service functions are >the same), [Med] Agree. however the need to have visibility of subscriber's IP address >(dynamically assigned in Mobile network), subscriber identity i.e. the >phone number and the services that the subscriber have subscribed to is >where the scalability concern is IMHO. [Med] Fair enough. > >So http://tools.ietf.org/html/draft-boucadair-sfc-requirements-02#section-= 6 >is still valid and my input adds the ability to recognise flows from >individual mobile users and assign them to a correct group of subscribers >who share a same SFC. [Med] Feel free to propose text to the requirement draft.=20 > >Regards, >Chuong > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Wednesday, 12 February 2014 8:23 PM >To: Pham, Chuong D; Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Dear Chuong, > >Thank you for the inputs. The draft will be updated to reflect most of you= r >points. > >As for the per-subscriber SFC, the scalability discussion is already >recorded here: http://tools.ietf.org/html/draft-boucadair-sfc-requirements= - >02#section-6. Beside considerations on scalability, what is really helpful >is to identify *** concrete *** use cases that would require such per- >subscriber SFCs (that would lead to instantiating millions of SFCs in a >domain): i.e., are there real business motivations to configure customized >service chains for each subscriber? Wouldn't be realistic to assume chains >for groups of subscribers? > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Pham, Chuong D >>Envoy=E9=A0: mercredi 12 f=E9vrier 2014 02:59 =C0=A0: Alla Goldner; Liush= ucheng >>(Will); sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Hi Liushucheng, >> >>There is also the case where a service function is selected based on >>user subscription. For example, steering traffic to a Parental Control >>(PC) only for the flows belonging to users who have PC subscription. >>One way of doing it is for the PCRF to notify the classifier about the >>correct flows to expect prior to the arrival of these flows. >> >>Other example is steering traffic to a DPI based on users with QoS >>subscriptions for the purpose of reporting and optionally enforcement. >> >>Another example is when a user wants to opt-out of service functions >>such as an Operator-mandate video optimisation platform for reasons >>such as the user is a Gold user with QoS and requirements for high >resolution video. >> >>To me, user subscription based traffic steering/servicing chaining is >>important for Mobile and at the same time, it poses great challenge on >>scalability therefore it is worthwhile to be included in your draft. >> >> >>Regards, >>Chuong >> >>-----Original Message----- >>From: Alla Goldner [mailto:agoldner@allot.com] >>Sent: Tuesday, 11 February 2014 9:53 PM >>To: Liushucheng (Will); sfc@ietf.org >>Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Dear Shucheng, >> >>With regard to this use case description, it would be useful, in my >>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>23.203 where Traffic Detection Function (TDF) is a standardized element >>residing on Gi/SGi which implements DPI (detection) functionality along >>with enforcement and charging of the corresponding detected >>applications. This is missing from your use case description. I think >>such a comment was already provided in a different email thread. >> >>Best Regards, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 >>9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com >>www.allot.com >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >>Sent: Tuesday, February 11, 2014 11:18 AM >>To: sfc@ietf.org >>Subject: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Hi all, >> >>We've just updated our use case draft. The main change is in the >>section of Use Case of Service Function Chain in Mobile Core Network. >>Looking forward to your comments. >> >>Regards, >>Shucheng (Will) >> >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Tuesday, February 11, 2014 5:14 PM >>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >>Leymann; Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie >>Hu; Huangyong (Oliver) >>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >> >> >>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >>successfully submitted by Will(Shucheng) Liu and posted to the IETF >repository. >> >>Name: draft-liu-sfc-use-cases >>Revision: 01 >>Title: Service Function Chaining (SFC) Use Cases >>Document date: 2014-02-11 >>Group: Individual Submission >>Pages: 15 >>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>cases-01.txt >>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-case= s- >01 >> >>Abstract: >> The delivery of value-added services relies on the invocation of >> advanced Service Functions in a sequential order. This mechanism is >> called Service Function Chaining (SFC). The set of involved Service >> Functions and their order depends on the service context. >> >> This document presents a set of use cases of Service Function >> Chaining (SFC). >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >>####################################################################### >>#### >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender >>by a reply e-mail and delete this message. >>Thank you. >>####################################################################### >>#### >>################### >> >> >>_______________________________________________ >>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 mohamed.boucadair@orange.com Thu Feb 13 01:45:20 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7B51A0110 for ; Thu, 13 Feb 2014 01:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Xm1soSepp89l for ; Thu, 13 Feb 2014 01:45:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4650C1A00F7 for ; Thu, 13 Feb 2014 01:45:18 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2A1D822C499; Thu, 13 Feb 2014 10:45:17 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0D5984C10A; Thu, 13 Feb 2014 10:45:01 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 13 Feb 2014 10:45:00 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 10:44:59 +0100 Thread-Topic: [sfc] Framework Thread-Index: Ac8oDlLROHRd1qPiRwWCapgFDAfAfQAjykaw Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E9BA@PUEXCB1B.nanterre.francetelecom.fr> References: <52FB9F32.4000005@joelhalpern.com> In-Reply-To: <52FB9F32.4000005@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:45:20 -0000 Hi Joel, The document does not exclude any transport modes; the ones that are listed= are provided for illustration purposes. The behavior of the classifier for= instance is generic: "The SFC Classifier classifies packets based on (som= e of) the contents of the packet." Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 17:20 >=C0=A0: sfc@ietf.org >Objet=A0: [sfc] Framework > >I was looking at the framework proposal. >The proposal has a very specific model of the scope of the transport >header (that it is derived from, and relates only to, the first service >function to which the packet will be directed. >That is clearly an operational model we need to support. > >However, I would like to allow other transport operational models, such >as the use of a VLAN to direct traffic along a chain. Or the use of an >MPLS label, or an MPLS label stack. > >Yours, >Joel M. Halpern > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Thu Feb 13 01:50:53 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5191A0110 for ; Thu, 13 Feb 2014 01:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6StVDijzhgAP for ; Thu, 13 Feb 2014 01:50:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 186411A012D for ; Thu, 13 Feb 2014 01:50:52 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 48E943242D3 for ; Thu, 13 Feb 2014 10:50:50 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2A55935C072 for ; Thu, 13 Feb 2014 10:50:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 13 Feb 2014 10:50:49 +0100 From: To: "sfc@ietf.org" Date: Thu, 13 Feb 2014 10:50:49 +0100 Thread-Topic: I-D Action: draft-boucadair-sfc-design-analysis-02.txt Thread-Index: Ac8oAyDxHEEHtIB/ToGvZnDgdwHtEAAndLMw Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E9C3@PUEXCB1B.nanterre.francetelecom.fr> References: <20140212145759.13174.27854.idtracker@ietfa.amsl.com> In-Reply-To: <20140212145759.13174.27854.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-design-analysis-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:50:53 -0000 Dear all, An updated version of the draft is now available online. The new version tr= ies to integrate some comments on the subscriber-identifier. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 12 f=E9vrier 2014 15:58 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-design-analysis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Service Function Chaining: Design Considerations,= Analysis & Recommendations Authors : Mohamed Boucadair Christian Jacquenet Ron Parker Linda Dunbar Filename : draft-boucadair-sfc-design-analysis-02.txt Pages : 24 Date : 2014-02-12 Abstract: This document aims at analyzing the various design options and providing a set of recommendations for the design of Service Function Chaining solution(s). Note: o The analysis does not claim to be exhaustive. The list includes a preliminary set of potential solutions; other proposals can be added to the analysis if required. o The analysis is still ongoing. The analysis text will be updated to integrate received comments and inputs. o Sketched recommendations are not frozen. These recommendations are provided as proposals to kick-off the discussion and to challenge them. o The analysis does not cover any application-specific solution (e.g., HTTP header) because of the potential issues inherent to (TLS) encrypted traffic. o The analysis will be updated to take into account the full set of SFC requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-design-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-design-analysis-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mohamed.boucadair@orange.com Thu Feb 13 01:58:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01AC1A01C2 for ; Thu, 13 Feb 2014 01:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bCDR4FkK85q4 for ; Thu, 13 Feb 2014 01:58:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 229231A01C1 for ; Thu, 13 Feb 2014 01:58:27 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id B31CF374500; Thu, 13 Feb 2014 10:58:25 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 9937D3840C7; Thu, 13 Feb 2014 10:58:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 13 Feb 2014 10:58:25 +0100 From: To: Nicolas BOUTHORS Date: Thu, 13 Feb 2014 10:58:23 +0100 Thread-Topic: fixed lenght vs. variable length (RE: [sfc] Framework) Thread-Index: Ac8ooiHF0S4I7RSqQpq8pXSMleyGKg== Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E9D2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Cc: "sfc@ietf.org" Subject: [sfc] fixed lenght vs. variable length (RE: Framework) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:58:32 -0000 Dear Nicolas, all, (I changed the subject to this specific issue). In addition to the point you mention, there is also the potential impact on= performances. FWWI, an initial text to discuss this points is available at: http://tools.= ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-4.2=20 It would be really helpful to record design considerations.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Nicolas BOUTHORS >Envoy=E9=A0: jeudi 13 f=E9vrier 2014 10:14 >=C0=A0: Ron Parker; Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >Cc=A0: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Objet=A0: Re: [sfc] Framework > >If we do not enforce a fix header size we have other implication. > >There is the question of segmentation and reassembly responsibility as >well. > >If adding length to the service header forces segmentation, then whose >responsibility is it >to reassemble the payload before passing it to the SF. > >Similar question for packet re-ordering. > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Wednesday, February 12, 2014 11:25 PM >To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: Re: [sfc] Framework > >Dave, > >Yes, that is a good point if we logically separate the forwarding function >from the SFC-aware service function, as we should. The forwarding >function is concerned with only the inbound transport header, the fixed >portion of the service header containing the chain information, and the >outbound transport header. The service function may look at the entiret= y >of the service header and would look at the encapsulated packet. > > Ron > > >-----Original Message----- >From: Dave Dolson [mailto:ddolson@sandvine.com] >Sent: Wednesday, February 12, 2014 5:18 PM >To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: RE: [sfc] Framework > >The forwarding plane might not even need to look at the encapsulated >packet. > >For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can >forward packets of the form: Ether | VLAN | BLOB. > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 12, 2014 4:30 PM >To: Ron Parker; Dave Dolson; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: Re: [sfc] Framework > >I agree as well. >Yours, >Joel > >On 2/12/14, 4:24 PM, Ron Parker wrote: >> Hi, Dave. >> >> I Agree with your statement. And if the total length of the header i= s >contained in the mandatory portion, the hardware implementation can easily >locate the encapsulated packet. >> >> Ron >> >> >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Wednesday, February 12, 2014 4:10 PM >> To: Ron Parker; Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: RE: [sfc] Framework >> >> I think a good approach would be: >> >> The information required for forwarding (the SF Identifier) should be in >a mandatory fixed-size header. >> >> Optional information (if any) is NOT to be used for forwarding, but is >for consumption by one or more of the applications in the chain. >> >> Then the forwarding plane, and even the PDP, can be agnostic about the >meta-data. >> >> -Dave >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Wednesday, February 12, 2014 4:05 PM >> To: Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> Paul, >> >> That is why I am proposing a hybrid where extensions or options can be >added but the total length is contained in the fixed portion. I can >envision certain deployments (e.g., Enterprise) where perhaps extensions >are not needed and the SFC functionality is realized in hardware. And, I >can envision certain other deployments (e.g., 3gpp) where the extension >headers add sufficient value to justify software based implementations. >> >> Ron >> >> >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >> Sent: Wednesday, February 12, 2014 3:40 PM >> To: Ron Parker >> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> Hi, >> >> We certainly need to be very careful with variable length headers when >hardware platform are in play. >> >> Ron, your examples of IP options and v6 EH have both suffered from >significant implementation and deployment hurdles due to the complexity an= d >cost associated with hardware support for the option/EH. >> >> Paul >> >> On Feb 12, 2014, at 3:10 PM, Ron Parker >wrote: >> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I completely agree. I might >suggest a compromise between hardware friendliness and software >flexibility. If the header had the ability to add extensions (perhaps >similar to IPv6) but also had the header length encoded in the mandatory >part (like IPv4), then a hardware implementation would be free to skip ove= r >the extensions (in cases where the deployment justifies ignoring the >extensions). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>> >>> >>> I agree. However the format of service header should be standardized in >a way that is flexible. Some of us would like to see variable length heade= r >that is also HW friendly. The service header can be represented as a >mandotory fixed length header (like IP header) along with an optional >variable length attribute field. Different services can be interested in >different metadata, for example subscriber ID could be of interest in the >mobile core service chain only. >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >wrote: >>> >>>> Linda, >>>> >>>> My interpretation of the architecture docs is that the service >>>> function chain is built in an abstract manner (i.e., SF-A then SF-B >then SF-C). >>>> Separately, a locator table provides network location for each of thos= e >>>> service functions. In this way, you can locate the service functions >in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >address, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP >>>> as a transport layer. >>>> >>>> For all of those reasons, I strongly support a canonical service heade= r >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the >fields >>>> in the transport header. That is, the SFC node discards the transpor= t >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how >>>> to interpret the chain ID and ultimately how to progress the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can associate a unique Layer 2 or >>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>>> Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>>> path to steer the flow to the service functions specified by the >>>> flow's service chain." >>>> >>>> >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first >>>> service function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>> >>>> However, I would like to allow other transport operational models, >>>> such as the use of a VLAN to direct traffic along a chain. Or the >>>> use of an MPLS label, or an MPLS label stack. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 mohamed.boucadair@orange.com Thu Feb 13 02:14:44 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9643B1A017C for ; Thu, 13 Feb 2014 02:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 e467zmxw94XQ for ; Thu, 13 Feb 2014 02:14:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF21A013C for ; Thu, 13 Feb 2014 02:14:42 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 805953744BF; Thu, 13 Feb 2014 11:14:40 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 559BE1580D5; Thu, 13 Feb 2014 11:14:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 13 Feb 2014 11:14:39 +0100 From: To: "Joel M. Halpern" , Ron Parker , Linda Dunbar , "sfc@ietf.org" Date: Thu, 13 Feb 2014 11:14:38 +0100 Thread-Topic: [sfc] Framework Thread-Index: Ac8oKd5tcr9YGSYCRc+MNeHtX49+ewAeYxWw Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31E9FC@PUEXCB1B.nanterre.francetelecom.fr> References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBCD6F.1020703@joelhalpern.com> In-Reply-To: <52FBCD6F.1020703@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:14:44 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 20:37 >=C0=A0: Ron Parker; Linda Dunbar; sfc@ietf.org >Objet=A0: Re: [sfc] Framework > >Ron, I think the architecture document (quinn) describes these issues in >a fashion taht is sufficiently flexible. >And I support the definition of the service header. > >Some of the other individual drafts however refer to process that [Med] If by "other" you include draft-boucadair-sfc-framework, I reiterate = my response: there is no excluded transport modes. The document lists some = options as (non-exhaustive) examples, and points to a detailed design analy= sis document. This BTW aligned with the charter of the WG that says the fol= lowing: " 2. Architecture: This document will provide a description of the SFC architectural building blocks and their relationships including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case. " >mandate transport behavior. And do so in ways that are, in my view, too >restrictive.=20 [Med] There is no such restriction at least in draft-boucadair-*. I hope th= is is now more clearer. Since I don't know how much or little other people agree >with those drafts, I wanted to raise the issue of the treatment of the >transport in those drafts. > >Yours, >Joel > >On 2/12/14, 2:32 PM, Ron Parker wrote: >> Linda, >> >> My interpretation of the architecture docs is that the service >> function chain is built in an abstract manner (i.e., SF-A then SF-B >> then SF-C). Separately, a locator table provides network location >> for each of those service functions. In this way, you can locate >> the service functions in a manner appropriate to the type of >> transport you are using. If you want that to be interface+VLAN, >> gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, >> etc., you can do that. You can even potentially locate different >> service functions that reside in the same chain with different >> flavors of network locators. Another justification to separate the >> identity of a service function from its network location is load >> balancing. If, for example, SF-A had 3 IP addresses, that would >> imply load balancing to 3 instances using IP as a transport layer. >> >> For all of those reasons, I strongly support a canonical service >> header that is independent of the transport methodology. At a >> particular node, the decision as to where to go next should be based >> solely on information carried in the canonical service header and not >> on the fields in the transport header. That is, the SFC node >> discards the transport header and extracts the chain ID from the >> service header. Through mechanisms we have not yet begun to >> discuss, the SFC node knows how to interpret the chain ID and >> ultimately how to progress the packet. >> >> Ron >> >> >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On >> Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM >> To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >> >> Agree with Joel's statement. >> >> I think a simple sentence below should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >> >> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >> Layer 2 or 3 Label makes it easier for subsequent nodes along the >> flow path to steer the flow to the service functions specified by the >> flow's service chain." >> >> >> Linda -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >> Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] >> Framework >> >> I was looking at the framework proposal. The proposal has a very >> specific model of the scope of the transport header (that it is >> derived from, and relates only to, the first service function to >> which the packet will be directed. That is clearly an operational >> model we need to support. >> >> However, I would like to allow other transport operational models, >> such as the use of a VLAN to direct traffic along a chain. Or the >> use of an MPLS label, or an MPLS label stack. >> >> Yours, Joel M. Halpern >> >> _______________________________________________ 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 mohamed.boucadair@orange.com Thu Feb 13 02:31:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1B1A01C2 for ; Thu, 13 Feb 2014 02:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vjI0euce7uYo for ; Thu, 13 Feb 2014 02:30:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8491A01C7 for ; Thu, 13 Feb 2014 02:30:57 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 505633742B1; Thu, 13 Feb 2014 11:30:55 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3171C18006A; Thu, 13 Feb 2014 11:30:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 13 Feb 2014 11:30:55 +0100 From: To: "Joel M. Halpern" , "Paul Quinn (paulq)" , Ron Parker Date: Thu, 13 Feb 2014 11:30:53 +0100 Thread-Topic: [sfc] Metadata structure Thread-Index: Ac8oNIIOOoTxVgoLQiO1GxdgGYe5JAAcAvsA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31EA26@PUEXCB1B.nanterre.francetelecom.fr> References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBDF4E.5000400@joelhalpern.com> In-Reply-To: <52FBDF4E.5000400@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Metadata structure X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:31:00 -0000 Re-, There is a need to assess the validity of those cases (and others which are= documented in use-case drafts) to avoid over-specification. The WG need to= identify the core functionally and ovoid designing a solution that would b= e much more complex that current practices. BTW, there should be a way to a= ssess to what extent proposed solutions solves the issues raised in the Pro= blem Statement draft.=20 "Flexibility" cannot be blindly used as an argument to justify more complex= ity. There are trade-offs; we should be aware of those when making design d= ecision.=20 I really hope we can follow the principles in RFC1925 and RFC3439; particul= arly this one:=20 " In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away." My current position on mandatory piece of information to be included in the= metadata is recorded in: http://tools.ietf.org/html/draft-boucadair-sfc-de= sign-analysis-02#section-5.5 that is one single code point. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 21:54 >=C0=A0: Paul Quinn (paulq); Ron Parker >Cc=A0: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Objet=A0: Re: [sfc] Metadata structure > >Paul, I agree that the various extension headers / options have not seen >uptake. This is in aprt due to it being somewhat more complex for the >hardware. But mostly because the initial need was not there. >In this case, we need variable metadata. The range of metadata that >people have discussed with me is so high that I can not imagine a fixed >length header handling even 80% of the cases well. > >Yours, >Joel > >On 2/12/14, 3:39 PM, Paul Quinn (paulq) wrote: >> Hi, >> >> We certainly need to be very careful with variable length headers when >hardware platform are in play. >> >> Ron, your examples of IP options and v6 EH have both suffered from >significant implementation and deployment hurdles due to the complexity an= d >cost associated with hardware support for the option/EH. >> >> Paul >> >> On Feb 12, 2014, at 3:10 PM, Ron Parker >wrote: >> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I completely agree. I might >suggest a compromise between hardware friendliness and software >flexibility. If the header had the ability to add extensions (perhaps >similar to IPv6) but also had the header length encoded in the mandatory >part (like IPv4), then a hardware implementation would be free to skip ove= r >the extensions (in cases where the deployment justifies ignoring the >extensions). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>> >>> >>> I agree. However the format of service header should be standardized in >a way that is flexible. Some of us would like to see variable length heade= r >that is also HW friendly. The service header can be represented as a >mandotory fixed length header (like IP header) along with an optional >variable length attribute field. Different services can be interested in >different metadata, for example subscriber ID could be of interest in the >mobile core service chain only. >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >wrote: >>> >>>> Linda, >>>> >>>> My interpretation of the architecture docs is that the service functio= n >>>> chain is built in an abstract manner (i.e., SF-A then SF-B then SF-C). >>>> Separately, a locator table provides network location for each of thos= e >>>> service functions. In this way, you can locate the service functions >in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >address, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP as = a >>>> transport layer. >>>> >>>> For all of those reasons, I strongly support a canonical service heade= r >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the >fields >>>> in the transport header. That is, the SFC node discards the transpor= t >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how to >>>> interpret the chain ID and ultimately how to progress the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow path >>>> to steer the flow to the service functions specified by the flow's >>>> service chain." >>>> >>>> >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first servic= e >>>> function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>> >>>> However, I would like to allow other transport operational models, suc= h >>>> as the use of a VLAN to direct traffic along a chain. Or the use of a= n >>>> MPLS label, or an MPLS label stack. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> _______________________________________________ >>>> 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 >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From ddolson@sandvine.com Thu Feb 13 04:39:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7D1A021E for ; Thu, 13 Feb 2014 04:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 3mxM_XF0c_s3 for ; Thu, 13 Feb 2014 04:39:20 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 702691A0218 for ; Thu, 13 Feb 2014 04:39:20 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Thu, 13 Feb 2014 07:39:18 -0500 From: Dave Dolson To: "'Nicolas.BOUTHORS@qosmos.com'" , "'Ron_Parker@affirmednetworks.com'" , "'jmh@joelhalpern.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQgABYqACAAAGugP//uNTggABWkACAALUQgP//5ao9 Date: Thu, 13 Feb 2014 12:39:18 +0000 Message-ID: In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:39:23 -0000 Good point to consider fragmentation.=20 We should design the encapsulation such that the forwarding functions do no= t need to reassemble. Each fragment should be independently forwardable; so= me SFs may choose to ignore these packets.=20 Any layer 2.5 protocol like VLAN or MPLS would support this.=20 Otherwise, a reassembly layer could be added after the forwarding coordinat= es. Think of something like the IPv6 reassembly option after a GRE header, = for instance. =20 IP | GRE | reassem | frag data We could alternatively mandate the inner IP be fragmented and that path-MTU= discovery be supported.=20 ----- Original Message ----- From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, 2014 04:13 AM=0A= To: Ron Parker ; Dave Dolson; Joel M. Halp= ern ; Paul Quinn (paulq) Cc: Sumandra Majee ; sfc@ietf.org ; Linda Dun= bar Subject: Re: [sfc] Framework If we do not enforce a fix header size we have other implication. There is the question of segmentation and reassembly responsibility as well= . If adding length to the service header forces segmentation, then whose resp= onsibility is it to reassemble the payload before passing it to the SF. =20 Similar question for packet re-ordering. ________________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework Dave, Yes, that is a good point if we logically separate the forwarding function = from the SFC-aware service function, as we should. The forwarding functio= n is concerned with only the inbound transport header, the fixed portion of= the service header containing the chain information, and the outbound tran= sport header. The service function may look at the entirety of the servi= ce header and would look at the encapsulated packet. Ron -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] Framework The forwarding plane might not even need to look at the encapsulated packet= . For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can f= orward packets of the form: Ether | VLAN | BLOB. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Framework I agree as well. Yours, Joel On 2/12/14, 4:24 PM, Ron Parker wrote: > Hi, Dave. > > I Agree with your statement. And if the total length of the header is= contained in the mandatory portion, the hardware implementation can easily= locate the encapsulated packet. > > Ron > > > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 12, 2014 4:10 PM > To: Ron Parker; Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: RE: [sfc] Framework > > I think a good approach would be: > > The information required for forwarding (the SF Identifier) should be in = a mandatory fixed-size header. > > Optional information (if any) is NOT to be used for forwarding, but is fo= r consumption by one or more of the applications in the chain. > > Then the forwarding plane, and even the PDP, can be agnostic about the me= ta-data. > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Wednesday, February 12, 2014 4:05 PM > To: Paul Quinn (paulq) > Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework > > Paul, > > That is why I am proposing a hybrid where extensions or options can be ad= ded but the total length is contained in the fixed portion. I can envisio= n certain deployments (e.g., Enterprise) where perhaps extensions are not n= eeded and the SFC functionality is realized in hardware. And, I can envis= ion certain other deployments (e.g., 3gpp) where the extension headers add = sufficient value to justify software based implementations. > > Ron > > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, February 12, 2014 3:40 PM > To: Ron Parker > Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework > > Hi, > > We certainly need to be very careful with variable length headers when ha= rdware platform are in play. > > Ron, your examples of IP options and v6 EH have both suffered from signif= icant implementation and deployment hurdles due to the complexity and cost = associated with hardware support for the option/EH. > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker = wrote: > >> Hi, Sumandra. >> >> Regarding service header flexibility, I completely agree. I might sugg= est a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6) = but also had the header length encoded in the mandatory part (like IPv4), t= hen a hardware implementation would be free to skip over the extensions (in= cases where the deployment justifies ignoring the extensions). >> >> Ron >> >> >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, February 12, 2014 3:04 PM >> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >>>> For all of those reasons, I strongly support a canonical service >>>> header that is independent of the transport methodology. >> >> >> I agree. However the format of service header should be standardized in = a way that is flexible. Some of us would like to see variable length header= that is also HW friendly. The service header can be represented as a mando= tory fixed length header (like IP header) along with an optional variable l= ength attribute field. Different services can be interested in different me= tadata, for example subscriber ID could be of interest in the mobile core s= ervice chain only. >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" wro= te: >> >>> Linda, >>> >>> My interpretation of the architecture docs is that the service >>> function chain is built in an abstract manner (i.e., SF-A then SF-B the= n SF-C). >>> Separately, a locator table provides network location for each of those >>> service functions. In this way, you can locate the service functions = in >>> a manner appropriate to the type of transport you are using. If you >>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP address= , >>> GRE tunnel remote IP + key, etc., you can do that. You can even >>> potentially locate different service functions that reside in the same >>> chain with different flavors of network locators. Another >>> justification to separate the identity of a service function from its >>> network location is load balancing. If, for example, SF-A had 3 IP >>> addresses, that would imply load balancing to 3 instances using IP >>> as a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service header >>> that is independent of the transport methodology. At a particular >>> node, the decision as to where to go next should be based solely on >>> information carried in the canonical service header and not on the fiel= ds >>> in the transport header. That is, the SFC node discards the transport >>> header and extracts the chain ID from the service header. Through >>> mechanisms we have not yet begun to discuss, the SFC node knows how >>> to interpret the chain ID and ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or >>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>> Layer >>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>> path to steer the flow to the service functions specified by the >>> flow's service chain." >>> >>> >>> Linda >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 10:20 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework proposal. >>> The proposal has a very specific model of the scope of the transport >>> header (that it is derived from, and relates only to, the first >>> service function to which the packet will be directed. >>> That is clearly an operational model we need to support. >>> >>> However, I would like to allow other transport operational models, >>> such as the use of a VLAN to direct traffic along a chain. Or the >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, >>> Joel M. Halpern >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 Ron_Parker@affirmednetworks.com Thu Feb 13 04:52:54 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766E1A0220 for ; Thu, 13 Feb 2014 04:52:54 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrjFdXpERnko for ; Thu, 13 Feb 2014 04:52:52 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id E32C01A0217 for ; Thu, 13 Feb 2014 04:52:51 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 04:52:50 -0800 From: Ron Parker To: Nicolas BOUTHORS Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gP//tyab Date: Thu, 13 Feb 2014 12:52:50 +0000 Message-ID: <828F0837-2949-45FF-A7BF-218F845A7164@affirmednetworks.com> References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBE7F3.1050605@joelhalpern.com> , , <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sumandra Majee , "sfc@ietf.org" , Linda Dunbar , "Paul Quinn \(paulq\)" , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:52:55 -0000 Nicolas, If you add even 1 byte, you could require fragmentation, so I don't think f= ixed vs variable creates the need, but perhaps contributes to the frequency= that it must occur. If the transport header includes an ipv4 or ipv6 hea= der, then fragmentation, when necessary, would occur in the outer datagram,= only. Ron > On Feb 13, 2014, at 4:14 AM, "Nicolas BOUTHORS" wrote: >=20 > If we do not enforce a fix header size we have other implication. >=20 > There is the question of segmentation and reassembly responsibility as we= ll. >=20 > If adding length to the service header forces segmentation, then whose re= sponsibility is it > to reassemble the payload before passing it to the SF. =20 >=20 > Similar question for packet re-ordering. >=20 >=20 > ________________________________________ > From: Ron Parker [Ron_Parker@affirmednetworks.com] > Sent: Wednesday, February 12, 2014 11:25 PM > To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) > Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework >=20 > Dave, >=20 > Yes, that is a good point if we logically separate the forwarding functio= n from the SFC-aware service function, as we should. The forwarding funct= ion is concerned with only the inbound transport header, the fixed portion = of the service header containing the chain information, and the outbound tr= ansport header. The service function may look at the entirety of the ser= vice header and would look at the encapsulated packet. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Wednesday, February 12, 2014 5:18 PM > To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) > Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: RE: [sfc] Framework >=20 > The forwarding plane might not even need to look at the encapsulated pack= et. >=20 > For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can= forward packets of the form: Ether | VLAN | BLOB. >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, February 12, 2014 4:30 PM > To: Ron Parker; Dave Dolson; Paul Quinn (paulq) > Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Framework >=20 > I agree as well. > Yours, > Joel >=20 >> On 2/12/14, 4:24 PM, Ron Parker wrote: >> Hi, Dave. >>=20 >> I Agree with your statement. And if the total length of the header i= s contained in the mandatory portion, the hardware implementation can easil= y locate the encapsulated packet. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Wednesday, February 12, 2014 4:10 PM >> To: Ron Parker; Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: RE: [sfc] Framework >>=20 >> I think a good approach would be: >>=20 >> The information required for forwarding (the SF Identifier) should be in= a mandatory fixed-size header. >>=20 >> Optional information (if any) is NOT to be used for forwarding, but is f= or consumption by one or more of the applications in the chain. >>=20 >> Then the forwarding plane, and even the PDP, can be agnostic about the m= eta-data. >>=20 >> -Dave >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Wednesday, February 12, 2014 4:05 PM >> To: Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >>=20 >> Paul, >>=20 >> That is why I am proposing a hybrid where extensions or options can be a= dded but the total length is contained in the fixed portion. I can envisi= on certain deployments (e.g., Enterprise) where perhaps extensions are not = needed and the SFC functionality is realized in hardware. And, I can envi= sion certain other deployments (e.g., 3gpp) where the extension headers add= sufficient value to justify software based implementations. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >> Sent: Wednesday, February 12, 2014 3:40 PM >> To: Ron Parker >> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >>=20 >> Hi, >>=20 >> We certainly need to be very careful with variable length headers when h= ardware platform are in play. >>=20 >> Ron, your examples of IP options and v6 EH have both suffered from signi= ficant implementation and deployment hurdles due to the complexity and cost= associated with hardware support for the option/EH. >>=20 >> Paul >>=20 >>> On Feb 12, 2014, at 3:10 PM, Ron Parker wrote: >>>=20 >>> Hi, Sumandra. >>>=20 >>> Regarding service header flexibility, I completely agree. I might sug= gest a compromise between hardware friendliness and software flexibility. = If the header had the ability to add extensions (perhaps similar to IPv6)= but also had the header length encoded in the mandatory part (like IPv4), = then a hardware implementation would be free to skip over the extensions (i= n cases where the deployment justifies ignoring the extensions). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>>=20 >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>>=20 >>>=20 >>> I agree. However the format of service header should be standardized in= a way that is flexible. Some of us would like to see variable length heade= r that is also HW friendly. The service header can be represented as a mand= otory fixed length header (like IP header) along with an optional variable = length attribute field. Different services can be interested in different m= etadata, for example subscriber ID could be of interest in the mobile core = service chain only. >>>=20 >>> Sumandra >>>=20 >>>> On 2/12/14, 11:32 AM, "Ron Parker" w= rote: >>>>=20 >>>> Linda, >>>>=20 >>>> My interpretation of the architecture docs is that the service >>>> function chain is built in an abstract manner (i.e., SF-A then SF-B th= en SF-C). >>>> Separately, a locator table provides network location for each of thos= e >>>> service functions. In this way, you can locate the service functions= in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP addres= s, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP >>>> as a transport layer. >>>>=20 >>>> For all of those reasons, I strongly support a canonical service heade= r >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the fie= lds >>>> in the transport header. That is, the SFC node discards the transpor= t >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how >>>> to interpret the chain ID and ultimately how to progress the packet. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>>=20 >>>> Agree with Joel's statement. >>>>=20 >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>>=20 >>>> "A Service Chain Classifier node can associate a unique Layer 2 or >>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>>> Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>>> path to steer the flow to the service functions specified by the >>>> flow's service chain." >>>>=20 >>>>=20 >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>>=20 >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first >>>> service function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>>=20 >>>> However, I would like to allow other transport operational models, >>>> such as the use of a VLAN to direct traffic along a chain. Or the >>>> use of an MPLS label, or an MPLS label stack. >>>>=20 >>>> Yours, >>>> Joel M. Halpern >>>>=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 >>>=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 >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Thu Feb 13 05:16:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4D1A0225 for ; Thu, 13 Feb 2014 05:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K1zOLHkjwwRY for ; Thu, 13 Feb 2014 05:16:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D3D6A1A0237 for ; Thu, 13 Feb 2014 05:16:10 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D73A4324557; Thu, 13 Feb 2014 14:16:08 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BBD1D238092; Thu, 13 Feb 2014 14:16:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 13 Feb 2014 14:16:08 +0100 From: To: Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 14:16:07 +0100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPJwmwr4CF3fGr1U2UamRYQIgrPpqvxVzAgAAabLCAA01WoA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 13:16:13 -0000 Dear Alla, The new version cites now TS 23.203. You can check the diff available at:=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 >=C0=A0: Liushucheng (Will); sfc@ietf.org >Objet=A0: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es- >01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my >opinion, referring to the existing 3GPP architecture as per 3GPP TS 23.203 >where Traffic Detection Function (TDF) is a standardized element residing >on Gi/SGi which implements DPI (detection) functionality along with >enforcement and charging of the corresponding detected applications. This >is missing from your use case description. I think such a comment was >already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards >Allot Communications >Tel +972 9 7619251 >Cell +972 54 2493985 >Fax +972 9 7443626 >agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the section o= f >Use Case of Service Function Chain in Mobile Core Network. Looking forward >to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann; >Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfully >submitted by Will(Shucheng) Liu and posted to the IETF repository. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases= -01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Thu Feb 13 05:21:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEF71A023F for ; Thu, 13 Feb 2014 05:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TT2ChAyzZxki for ; Thu, 13 Feb 2014 05:21:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id B12101A0237 for ; Thu, 13 Feb 2014 05:21:36 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 111ADC0655; Thu, 13 Feb 2014 14:21:35 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id B3CAEC80CF; Thu, 13 Feb 2014 14:21:34 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 13 Feb 2014 14:21:31 +0100 From: To: Dave Dolson , "'Nicolas.BOUTHORS@qosmos.com'" , "'Ron_Parker@affirmednetworks.com'" , "'jmh@joelhalpern.com'" , "'paulq@cisco.com'" Date: Thu, 13 Feb 2014 14:21:30 +0100 Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQgABYqACAAAGugP//uNTggABWkACAALUQgP//5ao9AAFkm1A= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> References: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.12.75714 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:21:40 -0000 Re-, FWIW, one of the existing architecture drafts includes the following behavi= or (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): " 6. Fragmentation Considerations If adding the Service Chaining Header would result in a fragmented packet, the classifier should include a Service Chaining Header in each fragment. Doing so would prevent SF Nodes to dedicate resource to handle fragments. "=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson >Envoy=E9=A0: jeudi 13 f=E9vrier 2014 13:39 >=C0=A0: 'Nicolas.BOUTHORS@qosmos.com'; 'Ron_Parker@affirmednetworks.com'; >'jmh@joelhalpern.com'; 'paulq@cisco.com' >Cc=A0: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >Objet=A0: Re: [sfc] Framework > >Good point to consider fragmentation. > >We should design the encapsulation such that the forwarding functions do >not need to reassemble. Each fragment should be independently forwardable; >some SFs may choose to ignore these packets. > >Any layer 2.5 protocol like VLAN or MPLS would support this. >Otherwise, a reassembly layer could be added after the forwarding >coordinates. Think of something like the IPv6 reassembly option after a GR= E >header, for instance. > >IP | GRE | reassem | frag data > >We could alternatively mandate the inner IP be fragmented and that path-MT= U >discovery be supported. > > > > >----- Original Message ----- >From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] >Sent: Thursday, February 13, 2014 04:13 AM >To: Ron Parker ; Dave Dolson; Joel M. >Halpern ; Paul Quinn (paulq) >Cc: Sumandra Majee ; sfc@ietf.org ; Linda >Dunbar >Subject: Re: [sfc] Framework > >If we do not enforce a fix header size we have other implication. > >There is the question of segmentation and reassembly responsibility as >well. > >If adding length to the service header forces segmentation, then whose >responsibility is it >to reassemble the payload before passing it to the SF. > >Similar question for packet re-ordering. > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Wednesday, February 12, 2014 11:25 PM >To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: Re: [sfc] Framework > >Dave, > >Yes, that is a good point if we logically separate the forwarding function >from the SFC-aware service function, as we should. The forwarding >function is concerned with only the inbound transport header, the fixed >portion of the service header containing the chain information, and the >outbound transport header. The service function may look at the entiret= y >of the service header and would look at the encapsulated packet. > > Ron > > >-----Original Message----- >From: Dave Dolson [mailto:ddolson@sandvine.com] >Sent: Wednesday, February 12, 2014 5:18 PM >To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: RE: [sfc] Framework > >The forwarding plane might not even need to look at the encapsulated >packet. > >For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can >forward packets of the form: Ether | VLAN | BLOB. > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 12, 2014 4:30 PM >To: Ron Parker; Dave Dolson; Paul Quinn (paulq) >Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >Subject: Re: [sfc] Framework > >I agree as well. >Yours, >Joel > >On 2/12/14, 4:24 PM, Ron Parker wrote: >> Hi, Dave. >> >> I Agree with your statement. And if the total length of the header i= s >contained in the mandatory portion, the hardware implementation can easily >locate the encapsulated packet. >> >> Ron >> >> >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Wednesday, February 12, 2014 4:10 PM >> To: Ron Parker; Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: RE: [sfc] Framework >> >> I think a good approach would be: >> >> The information required for forwarding (the SF Identifier) should be in >a mandatory fixed-size header. >> >> Optional information (if any) is NOT to be used for forwarding, but is >for consumption by one or more of the applications in the chain. >> >> Then the forwarding plane, and even the PDP, can be agnostic about the >meta-data. >> >> -Dave >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Wednesday, February 12, 2014 4:05 PM >> To: Paul Quinn (paulq) >> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> Paul, >> >> That is why I am proposing a hybrid where extensions or options can be >added but the total length is contained in the fixed portion. I can >envision certain deployments (e.g., Enterprise) where perhaps extensions >are not needed and the SFC functionality is realized in hardware. And, I >can envision certain other deployments (e.g., 3gpp) where the extension >headers add sufficient value to justify software based implementations. >> >> Ron >> >> >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >> Sent: Wednesday, February 12, 2014 3:40 PM >> To: Ron Parker >> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> Hi, >> >> We certainly need to be very careful with variable length headers when >hardware platform are in play. >> >> Ron, your examples of IP options and v6 EH have both suffered from >significant implementation and deployment hurdles due to the complexity an= d >cost associated with hardware support for the option/EH. >> >> Paul >> >> On Feb 12, 2014, at 3:10 PM, Ron Parker >wrote: >> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I completely agree. I might >suggest a compromise between hardware friendliness and software >flexibility. If the header had the ability to add extensions (perhaps >similar to IPv6) but also had the header length encoded in the mandatory >part (like IPv4), then a hardware implementation would be free to skip ove= r >the extensions (in cases where the deployment justifies ignoring the >extensions). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, February 12, 2014 3:04 PM >>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>>>> For all of those reasons, I strongly support a canonical service >>>>> header that is independent of the transport methodology. >>> >>> >>> I agree. However the format of service header should be standardized in >a way that is flexible. Some of us would like to see variable length heade= r >that is also HW friendly. The service header can be represented as a >mandotory fixed length header (like IP header) along with an optional >variable length attribute field. Different services can be interested in >different metadata, for example subscriber ID could be of interest in the >mobile core service chain only. >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >wrote: >>> >>>> Linda, >>>> >>>> My interpretation of the architecture docs is that the service >>>> function chain is built in an abstract manner (i.e., SF-A then SF-B >then SF-C). >>>> Separately, a locator table provides network location for each of thos= e >>>> service functions. In this way, you can locate the service functions >in >>>> a manner appropriate to the type of transport you are using. If you >>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >address, >>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>> potentially locate different service functions that reside in the same >>>> chain with different flavors of network locators. Another >>>> justification to separate the identity of a service function from its >>>> network location is load balancing. If, for example, SF-A had 3 IP >>>> addresses, that would imply load balancing to 3 instances using IP >>>> as a transport layer. >>>> >>>> For all of those reasons, I strongly support a canonical service heade= r >>>> that is independent of the transport methodology. At a particular >>>> node, the decision as to where to go next should be based solely on >>>> information carried in the canonical service header and not on the >fields >>>> in the transport header. That is, the SFC node discards the transpor= t >>>> header and extracts the chain ID from the service header. Through >>>> mechanisms we have not yet begun to discuss, the SFC node knows how >>>> to interpret the chain ID and ultimately how to progress the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>> To: Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can associate a unique Layer 2 or >>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>>> Layer >>>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>>> path to steer the flow to the service functions specified by the >>>> flow's service chain." >>>> >>>> >>>> Linda >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework proposal. >>>> The proposal has a very specific model of the scope of the transport >>>> header (that it is derived from, and relates only to, the first >>>> service function to which the packet will be directed. >>>> That is clearly an operational model we need to support. >>>> >>>> However, I would like to allow other transport operational models, >>>> such as the use of a VLAN to direct traffic along a chain. Or the >>>> use of an MPLS label, or an MPLS label stack. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 agoldner@allot.com Thu Feb 13 05:58:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06051A026C for ; Thu, 13 Feb 2014 05:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 mkiQ097EqldW for ; Thu, 13 Feb 2014 05:58:39 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD91A0238 for ; Thu, 13 Feb 2014 05:58:38 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 15:58:36 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 15:58:36 +0200 From: Alla Goldner To: "mohamed.boucadair@orange.com" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3DTK0g4qZ7UEinQvspEJX27pqzM7yw Date: Thu, 13 Feb 2014 13:58:35 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 13:58:43 -0000 Dear Mohamed, Thanks a lot for your kind consideration of my comment! I still have 3 comments in this regard:=20 1. It would be useful to mention within the newly introduced text that TD= F resides on Gi/SGi interface 2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network Arc= hitecture in order to outline it correctly (Figure 2 and Figure 4); also = correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture 3. It makes sense to reference latest available 3GPP TS 23.203 version (R= 12) - December 2013 Best regards and thanks in advance, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, February 13, 2014 3:16 PM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt Dear Alla, The new version cites now TS 23.203. You can check the diff available at:= =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 =20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner=20 >Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Dear Shucheng, > >With regard to this use case description, it would be useful, in my=20 >opinion, referring to the existing 3GPP architecture as per 3GPP TS=20 >23.203 where Traffic Detection Function (TDF) is a standardized element = >residing on Gi/SGi which implements DPI (detection) functionality along = >with enforcement and charging of the corresponding detected=20 >applications. This is missing from your use case description. I think=20 >such a comment was already provided in a different email thread. > >Best Regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >agoldner@allot.com www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >Sent: Tuesday, February 11, 2014 11:18 AM >To: sfc@ietf.org >Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-= >01.txt > >Hi all, > >We've just updated our use case draft. The main change is in the section= =20of >Use Case of Service Function Chain in Mobile Core Network. Looking forwa= rd >to your comments. > >Regards, >Shucheng (Will) > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 5:14 PM >To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leyman= n; >Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >Huangyong (Oliver) >Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt > > >A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successful= ly >submitted by Will(Shucheng) Liu and posted to the IETF repository. > >Name: draft-liu-sfc-use-cases >Revision: 01 >Title: Service Function Chaining (SFC) Use Cases >Document date: 2014-02-11 >Group: Individual Submission >Pages: 15 >URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >cases-01.txt >Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es-01 > >Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >########################################################################= ### >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender b= y a >reply e-mail and delete this message. >Thank you. >########################################################################= ### >################### > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From mohamed.boucadair@orange.com Thu Feb 13 06:22:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1A21A0240 for ; Thu, 13 Feb 2014 06:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iaO8ir1qvp-i for ; Thu, 13 Feb 2014 06:22:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0B51A0237 for ; Thu, 13 Feb 2014 06:22:01 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9B254324423; Thu, 13 Feb 2014 15:21:59 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 74E562380C6; Thu, 13 Feb 2014 15:21:59 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 13 Feb 2014 15:21:59 +0100 From: To: Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 15:21:57 +0100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3DTK0g4qZ7UEinQvspEJX27pqzM7ywgAAC7WA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 14:22:04 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] >Envoy=E9=A0: jeudi 13 f=E9vrier 2014 14:59 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); sfc@ietf.org >Objet=A0: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es- >01.txt > >Dear Mohamed, > >Thanks a lot for your kind consideration of my comment! > >I still have 3 comments in this regard: > >1. It would be useful to mention within the newly introduced text that TDF >resides on Gi/SGi interface [Med] All the functions listed in this section resides in the Gi interface.= The TDF text is just after a paragraph starting with "Gi Interface ...". W= e can repeat it also for TDF but we thought it is redundant.=20 >2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >Architecture in order to outline it correctly (Figure 2 and Figure 4); [Med] As you know there are DPI boxes in operational mobile networks that a= re not compliant with 3GPP specifications. Instead of updating existing fig= ures, adding a NEW figure with TDF can be considered.=20 also >correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture [Med] Will do. Thanks. >3. It makes sense to reference latest available 3GPP TS 23.203 version >(R12) - December 2013 [Med] OK. > >Best regards and thanks in advance, > > >Alla Goldner >Director of Mobile Technologies and Standards >Allot Communications >Tel +972 9 7619251 >Cell +972 54 2493985 >Fax +972 9 7443626 >agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 3:16 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Dear Alla, > >The new version cites now TS 23.203. You can check the diff available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will); >>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Shucheng, >> >>With regard to this use case description, it would be useful, in my >>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>23.203 where Traffic Detection Function (TDF) is a standardized element >>residing on Gi/SGi which implements DPI (detection) functionality along >>with enforcement and charging of the corresponding detected >>applications. This is missing from your use case description. I think >>such a comment was already provided in a different email thread. >> >>Best Regards, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >>Sent: Tuesday, February 11, 2014 11:18 AM >>To: sfc@ietf.org >>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >>01.txt >> >>Hi all, >> >>We've just updated our use case draft. The main change is in the section >of >>Use Case of Service Function Chain in Mobile Core Network. Looking forwar= d >>to your comments. >> >>Regards, >>Shucheng (Will) >> >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Tuesday, February 11, 2014 5:14 PM >>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leymann= ; >>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>Huangyong (Oliver) >>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >> >> >>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfull= y >>submitted by Will(Shucheng) Liu and posted to the IETF repository. >> >>Name: draft-liu-sfc-use-cases >>Revision: 01 >>Title: Service Function Chaining (SFC) Use Cases >>Document date: 2014-02-11 >>Group: Individual Submission >>Pages: 15 >>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>cases-01.txt >>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-case= s- >01 >> >>Abstract: >> The delivery of value-added services relies on the invocation of >> advanced Service Functions in a sequential order. This mechanism is >> called Service Function Chaining (SFC). The set of involved Service >> Functions and their order depends on the service context. >> >> This document presents a set of use cases of Service Function >> Chaining (SFC). >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >>#########################################################################= # ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender by >a >>reply e-mail and delete this message. >>Thank you. >>#########################################################################= # ># >>################### >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### From jmh@joelhalpern.com Thu Feb 13 06:28:17 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4191A0237 for ; Thu, 13 Feb 2014 06:28:17 -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 bDeOTXtB1DJ3 for ; Thu, 13 Feb 2014 06:28:12 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8B1A025B for ; Thu, 13 Feb 2014 06:28:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id ED3AE1BD46AA; Thu, 13 Feb 2014 06:28:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C88321BD46A5; Thu, 13 Feb 2014 06:28:10 -0800 (PST) Message-ID: <52FCD67F.2000908@joelhalpern.com> Date: Thu, 13 Feb 2014 09:28:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Ron Parker , Linda Dunbar , "sfc@ietf.org" References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBCD6F.1020703@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36F4C31E9FC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31E9FC@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:28:17 -0000 Unfortunately, while you intended to be transport agnostic, much of the behavioral description in section 5.2 and 5.4 is very specific about the required forwarding behaviors, including the scope of the transport. Yours, Joel On 2/13/14, 5:14 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoyé : mercredi 12 février 2014 20:37 >> À : Ron Parker; Linda Dunbar; sfc@ietf.org >> Objet : Re: [sfc] Framework >> >> Ron, I think the architecture document (quinn) describes these issues in >> a fashion taht is sufficiently flexible. >> And I support the definition of the service header. >> >> Some of the other individual drafts however refer to process that > > [Med] If by "other" you include draft-boucadair-sfc-framework, I reiterate my response: there is no excluded transport modes. The document lists some options as (non-exhaustive) examples, and points to a detailed design analysis document. This BTW aligned with the charter of the WG that says the following: > > " > 2. Architecture: This document will provide a description of the SFC > architectural building blocks and their relationships including > interconnection, placement of SFC specific capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. The initial scope is > restricted to a single administrative domain, keeping in mind that > architectural decisions made for the intra-domain case may have > implications for the inter-domain case. > " > > >> mandate transport behavior. And do so in ways that are, in my view, too >> restrictive. > > [Med] There is no such restriction at least in draft-boucadair-*. I hope this is now more clearer. > > Since I don't know how much or little other people agree >> with those drafts, I wanted to raise the issue of the treatment of the >> transport in those drafts. >> >> Yours, >> Joel >> >> On 2/12/14, 2:32 PM, Ron Parker wrote: >>> Linda, >>> >>> My interpretation of the architecture docs is that the service >>> function chain is built in an abstract manner (i.e., SF-A then SF-B >>> then SF-C). Separately, a locator table provides network location >>> for each of those service functions. In this way, you can locate >>> the service functions in a manner appropriate to the type of >>> transport you are using. If you want that to be interface+VLAN, >>> gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, >>> etc., you can do that. You can even potentially locate different >>> service functions that reside in the same chain with different >>> flavors of network locators. Another justification to separate the >>> identity of a service function from its network location is load >>> balancing. If, for example, SF-A had 3 IP addresses, that would >>> imply load balancing to 3 instances using IP as a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service >>> header that is independent of the transport methodology. At a >>> particular node, the decision as to where to go next should be based >>> solely on information carried in the canonical service header and not >>> on the fields in the transport header. That is, the SFC node >>> discards the transport header and extracts the chain ID from the >>> service header. Through mechanisms we have not yet begun to >>> discuss, the SFC node knows how to interpret the chain ID and >>> ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On >>> Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01 PM >>> To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>> Layer 2 or 3 Label makes it easier for subsequent nodes along the >>> flow path to steer the flow to the service functions specified by the >>> flow's service chain." >>> >>> >>> Linda -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject: [sfc] >>> Framework >>> >>> I was looking at the framework proposal. The proposal has a very >>> specific model of the scope of the transport header (that it is >>> derived from, and relates only to, the first service function to >>> which the packet will be directed. That is clearly an operational >>> model we need to support. >>> >>> However, I would like to allow other transport operational models, >>> such as the use of a VLAN to direct traffic along a chain. Or the >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, Joel M. Halpern >>> >>> _______________________________________________ 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 brunorijsman@gmail.com Thu Feb 13 06:14:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B4B1A0286 for ; Thu, 13 Feb 2014 06:14:27 -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 6h5I3UfABydF for ; Thu, 13 Feb 2014 06:14:25 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 801911A02B2 for ; Thu, 13 Feb 2014 06:14:25 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so8524065veb.16 for ; Thu, 13 Feb 2014 06:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SBvezVhm/kpsdn5z2smln0xbJYhUME0dbeZh2/1IXac=; b=x1QtqHjWz40UyEXE97kcwE8hFGn09iIKsR73Nbkfq6Gx7OgRFGh99YjGydDhkVNsT3 RBEJ8glWBSpuq3O+2iTw3LZ54nOuRvEJ1SSQYuDgF2VgI/8ZigTTAds9HQYTJeVs+cGs Kg8Yu4OgabUe+kqk3kyE0KAEwRfsp+jMT5rTolgnaQEuussL8pTYgD8WQeIKotov11hx mvB+bcry0sNLfaezaxkfaVx1H7zIRPgP4EX0vEzmHiGSr8cAGKC11iEnhHCQipzMC1qT S4F4jRIs5clY4D/fuhNLM5+3NnLa8/kMTfTvcs3GujN6m3tQdADem9Ovt7uuVxz/0HC6 DBZQ== MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr1113072vcx.1.1392300864089; Thu, 13 Feb 2014 06:14:24 -0800 (PST) Received: by 10.58.133.109 with HTTP; Thu, 13 Feb 2014 06:14:23 -0800 (PST) Date: Thu, 13 Feb 2014 09:14:23 -0500 Message-ID: From: Bruno Rijsman To: sfc@ietf.org Content-Type: multipart/alternative; boundary=001a11c2ca0c6cb20204f24a4e50 Subject: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:35:09 -0000 --001a11c2ca0c6cb20204f24a4e50 Content-Type: text/plain; charset=ISO-8859-1 Yesterday I posted a new draft "Metadata Considerations" (draft-rijsman-sfc-metadata-considerations-00): https://datatracker.ietf.org/doc/draft-rijsman-sfc-metadata-considerations/ This draft discusses the topic of metadata in the context of Service Function Chaining. It aims to: - identify use cases for metadata, - to define the problem space for metadata signaling, - identify candidate approaches, - describe the key challenges, - and guide the exploration and comparison of possible solutions. The goal of this draft is *not* to propose a specific protocol but rather to identify the requirements and solution space before we deep-dive into any particular approach. With that in mind, my questions for the mailing list are: - Are there any additional use cases for metadata beyond the three identified in chapter 2 of the draft? - Are there any additional signaling approaches beyond the five identified in chapter 3 of the draft? - Are there any additional challenges with respect to metadata signaling beyond the 13 identified in chapter 4 of the draft? -- Bruno --001a11c2ca0c6cb20204f24a4e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yesterday I posted a new draft "Metadata Conside= rations" (draft-rijsman-sfc-metadata-considerations-00): =A0


This draft discusses the topic of metadata in the context of= =A0Service Function Chaining. =A0It aims to:
  • identify use cases= for metadata,=A0
  • to define the problem space for metadata=A0signal= ing,=A0
  • identify candidate approaches,=A0
  • describe the key challenges,= =A0
  • and=A0guide the exploration and comparison of possible solution= s.
The goal of this draft is not=A0to propose a sp= ecific protocol but rather to identify the requirements and solution space = before we deep-dive into any particular approach.

With that in mind, my questions for the mailing list ar= e:
  • Are there any additional use cases for metadata beyond= the three identified in chapter 2 of the draft?

  • Are there = any additional signaling approaches beyond the five identified in chapter 3= =A0of the draft?

  • Are there any additional challenges with respect to metadata s= ignaling beyond the 13 identified in chapter 4=A0of the draft?
-- Bruno
--001a11c2ca0c6cb20204f24a4e50-- From agoldner@allot.com Thu Feb 13 06:43:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9E1A008E for ; Thu, 13 Feb 2014 06:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 YbkQ4bcRZwwR for ; Thu, 13 Feb 2014 06:43:02 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 437981A01F1 for ; Thu, 13 Feb 2014 06:43:00 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 16:42:58 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 16:42:58 +0200 From: Alla Goldner To: "mohamed.boucadair@orange.com" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3DTK0g4qZ7UEinQvspEJX27pqzM7ywgAAC7WCAAAq0UA== Date: Thu, 13 Feb 2014 14:42:57 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 14:43:06 -0000 Dear Mohamed, Thanks a lot for your kind response. On the point: >2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >Architecture in order to outline it correctly (Figure 2 and Figure 4); [Med] As you know there are DPI boxes in operational mobile networks that= =20are not compliant with 3GPP specifications. Instead of updating existi= ng figures, adding a NEW figure with TDF can be considered.=20 I don't think I agree with such a view. As long as we present standardize= d Mobile Network (defined by a different SDO i.e. 3GPP and not within a s= cope of IETF) it is very important to reference the existing well-defined= =20Network Elements. DPI functionality in mobile network is fulfilled by = the TDF. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, February 13, 2014 4:22 PM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier=20 >2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind consideration of my comment! > >I still have 3 comments in this regard: > >1. It would be useful to mention within the newly introduced text that=20 >TDF resides on Gi/SGi interface [Med] All the functions listed in this section resides in the Gi interfac= e. The TDF text is just after a paragraph starting with "Gi Interface ...= ". We can repeat it also for TDF but we thought it is redundant.=20 >2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >Architecture in order to outline it correctly (Figure 2 and Figure 4); [Med] As you know there are DPI boxes in operational mobile networks that= =20are not compliant with 3GPP specifications. Instead of updating existi= ng figures, adding a NEW figure with TDF can be considered.=20 =20also >correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture [Med] Will do. Thanks. >3. It makes sense to reference latest available 3GPP TS 23.203 version >(R12) - December 2013 [Med] OK. > >Best regards and thanks in advance, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >agoldner@allot.com www.allot.com > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]= >Sent: Thursday, February 13, 2014 3:16 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Dear Alla, > >The new version cites now TS 23.203. You can check the diff available at= : > >http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will); >>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Shucheng, >> >>With regard to this use case description, it would be useful, in my >>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>23.203 where Traffic Detection Function (TDF) is a standardized element= >>residing on Gi/SGi which implements DPI (detection) functionality along= >>with enforcement and charging of the corresponding detected >>applications. This is missing from your use case description. I think >>such a comment was already provided in a different email thread. >> >>Best Regards, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will)= >>Sent: Tuesday, February 11, 2014 11:18 AM >>To: sfc@ietf.org >>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= - >>01.txt >> >>Hi all, >> >>We've just updated our use case draft. The main change is in the sectio= n >of >>Use Case of Service Function Chain in Mobile Core Network. Looking forw= ard >>to your comments. >> >>Regards, >>Shucheng (Will) >> >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Tuesday, February 11, 2014 5:14 PM >>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai Leyma= nn; >>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>Huangyong (Oliver) >>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >> >> >>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been successfu= lly >>submitted by Will(Shucheng) Liu and posted to the IETF repository. >> >>Name: draft-liu-sfc-use-cases >>Revision: 01 >>Title: Service Function Chaining (SFC) Use Cases >>Document date: 2014-02-11 >>Group: Individual Submission >>Pages: 15 >>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>cases-01.txt >>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-case= s/ >>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-ca= ses- >01 >> >>Abstract: >> The delivery of value-added services relies on the invocation of >> advanced Service Functions in a sequential order. This mechanism is= >> called Service Function Chaining (SFC). The set of involved Service= >> Functions and their order depends on the service context. >> >> This document presents a set of use cases of Service Function >> Chaining (SFC). >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >>#######################################################################= ### ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender = by >a >>reply e-mail and delete this message. >>Thank you. >>#######################################################################= ### ># >>################### >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >########################################################################= ### >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender b= y a >reply e-mail and delete this message. >Thank you. >########################################################################= ### >################### #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From Ron_Parker@affirmednetworks.com Thu Feb 13 06:43:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1DF1A02B2 for ; Thu, 13 Feb 2014 06:43:23 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL7yvOlBxXPH for ; Thu, 13 Feb 2014 06:43:19 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5FB1A0295 for ; Thu, 13 Feb 2014 06:43:19 -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.0158.001; Thu, 13 Feb 2014 06:43:18 -0800 From: Ron Parker To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAInrgIAA9R8AgABG3ID//3wtkA== Date: Thu, 13 Feb 2014 14:43:18 +0000 Message-ID: References: <52FB9F32.4000005@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645C7E8C4@dfweml701-chm.china.huawei.com> <52FBCD6F.1020703@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36F4C31E9FC@PUEXCB1B.nanterre.francetelecom.fr> <52FCD67F.2000908@joelhalpern.com> In-Reply-To: <52FCD67F.2000908@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:43:23 -0000 Joel, In draft-boucadair-framework, section 5.2, SFC classifier, it is describing= examination of fields in the IP header of the original packet, independent= of what variant of transport delivered it to/from the classifier. Perhap= s we need to bring out that the payload that gets encapsulated by the servi= ce header and then the transport header could, itself, be L2 or L3, and con= sequently, examination of L2-L4 fields are potentially valid. In section 5.4, SFC Egress Node, we could improve the text to say "strip th= e SFC transport header and the SFC service header" rather than calling out = the SF Map Index, explicitly. Would this satisfy your concerns? Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, February 13, 2014 9:28 AM To: mohamed.boucadair@orange.com; Ron Parker; Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework Unfortunately, while you intended to be transport agnostic, much of the beh= avioral description in section 5.2 and 5.4 is very specific about the requi= red forwarding behaviors, including the scope of the transport. Yours, Joel On 2/13/14, 5:14 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >> Envoy=E9 : mercredi 12 f=E9vrier 2014 20:37 =C0 : Ron Parker; Linda Dunb= ar;=20 >> sfc@ietf.org Objet : Re: [sfc] Framework >> >> Ron, I think the architecture document (quinn) describes these issues=20 >> in a fashion taht is sufficiently flexible. >> And I support the definition of the service header. >> >> Some of the other individual drafts however refer to process that > > [Med] If by "other" you include draft-boucadair-sfc-framework, I reiterat= e my response: there is no excluded transport modes. The document lists som= e options as (non-exhaustive) examples, and points to a detailed design ana= lysis document. This BTW aligned with the charter of the WG that says the f= ollowing: > > " > 2. Architecture: This document will provide a description of the SFC=20 > architectural building blocks and their relationships including=20 > interconnection, placement of SFC specific capabilities, management,=20 > diagnostics, design analysis, and security models, as well as=20 > requirements on the protocol mechanisms. The initial scope is=20 > restricted to a single administrative domain, keeping in mind that=20 > architectural decisions made for the intra-domain case may have=20 > implications for the inter-domain case. > " > > >> mandate transport behavior. And do so in ways that are, in my view,=20 >> too restrictive. > > [Med] There is no such restriction at least in draft-boucadair-*. I hope = this is now more clearer. > > Since I don't know how much or little other people agree >> with those drafts, I wanted to raise the issue of the treatment of=20 >> the transport in those drafts. >> >> Yours, >> Joel >> >> On 2/12/14, 2:32 PM, Ron Parker wrote: >>> Linda, >>> >>> My interpretation of the architecture docs is that the service=20 >>> function chain is built in an abstract manner (i.e., SF-A then SF-B >>> then SF-C). Separately, a locator table provides network location >>> for each of those service functions. In this way, you can locate >>> the service functions in a manner appropriate to the type of >>> transport you are using. If you want that to be interface+VLAN, >>> gateway-IP+MPLS label stack, IP address, GRE tunnel remote IP + key, >>> etc., you can do that. You can even potentially locate different >>> service functions that reside in the same chain with different >>> flavors of network locators. Another justification to separate the >>> identity of a service function from its network location is load >>> balancing. If, for example, SF-A had 3 IP addresses, that would >>> imply load balancing to 3 instances using IP as a transport layer. >>> >>> For all of those reasons, I strongly support a canonical service >>> header that is independent of the transport methodology. At a >>> particular node, the decision as to where to go next should be based=20 >>> solely on information carried in the canonical service header and not >>> on the fields in the transport header. That is, the SFC node >>> discards the transport header and extracts the chain ID from the >>> service header. Through mechanisms we have not yet begun to >>> discuss, the SFC node knows how to interpret the chain ID and=20 >>> ultimately how to progress the packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Linda Dunbar Sent: Wednesday, February 12, 2014 12:01=20 >>> PM >>> To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can associate a unique Layer 2 or 3=20 >>> Label (e.g. VLAN, MPLS label) to the packets in the flow. Those=20 >>> Layer 2 or 3 Label makes it easier for subsequent nodes along the=20 >>> flow path to steer the flow to the service functions specified by=20 >>> the flow's service chain." >>> >>> >>> Linda -----Original Message----- From: sfc=20 >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 10:20 AM To: sfc@ietf.org Subject:=20 >>> [sfc] Framework >>> >>> I was looking at the framework proposal. The proposal has a very=20 >>> specific model of the scope of the transport header (that it is=20 >>> derived from, and relates only to, the first service function to=20 >>> which the packet will be directed. That is clearly an operational=20 >>> model we need to support. >>> >>> However, I would like to allow other transport operational models,=20 >>> such as the use of a VLAN to direct traffic along a chain. Or the=20 >>> use of an MPLS label, or an MPLS label stack. >>> >>> Yours, Joel M. Halpern >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From mohamed.boucadair@orange.com Thu Feb 13 06:50:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A21A02C4 for ; Thu, 13 Feb 2014 06:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WD4vM5D124Xw for ; Thu, 13 Feb 2014 06:50:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0461A02C7 for ; Thu, 13 Feb 2014 06:50:52 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 895A0C0B00; Thu, 13 Feb 2014 15:50:50 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 6DC541800DD; Thu, 13 Feb 2014 15:50:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 13 Feb 2014 15:50:50 +0100 From: To: Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Thu, 13 Feb 2014 15:50:48 +0100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3DTK0g4qZ7UEinQvspEJX27pqzM7ywgAAC7WCAAAq0UIAAAlGw Message-ID: <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 14:50:55 -0000 Re-, I hear your argument, but the point is we cannot ignore existing deployment= s that are not relying on such functional element. We should reflect both s= ituations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] >Envoy=E9=A0: jeudi 13 f=E9vrier 2014 15:43 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); sfc@ietf.org >Objet=A0: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es- >01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks that >are not compliant with 3GPP specifications. Instead of updating existing >figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present standardized >Mobile Network (defined by a different SDO i.e. 3GPP and not within a scop= e >of IETF) it is very important to reference the existing well-defined >Network Elements. DPI functionality in mobile network is fulfilled by the >TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards >Allot Communications >Tel +972 9 7619251 >Cell +972 54 2493985 >Fax +972 9 7443626 >agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f= =E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interface= . >The TDF text is just after a paragraph starting with "Gi Interface ...". W= e >can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks that >are not compliant with 3GPP specifications. Instead of updating existing >figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available at: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will); >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized element >>>residing on Gi/SGi which implements DPI (detection) functionality along >>>with enforcement and charging of the corresponding detected >>>applications. This is missing from your use case description. I think >>>such a comment was already provided in a different email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >>>01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the section >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism is >>> called Service Function Chaining (SFC). The set of involved Service >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>########################################################################= # ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or >>>distribute this message. >>>If you have mistakenly received this message, please notify the sender b= y >>a >>>reply e-mail and delete this message. >>>Thank you. >>>########################################################################= # ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>#########################################################################= # ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender by >a >>reply e-mail and delete this message. >>Thank you. >>#########################################################################= # ># >>################### >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### From agoldner@allot.com Thu Feb 13 06:58:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3853A1A02A3 for ; Thu, 13 Feb 2014 06:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 Wrk8gGMcTriW for ; Thu, 13 Feb 2014 06:58:01 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 97FE01A02A8 for ; Thu, 13 Feb 2014 06:57:59 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 16:57:57 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 16:57:57 +0200 From: Alla Goldner To: "mohamed.boucadair@orange.com" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3DTK0g4qZ7UEinQvspEJX27pqzM7ywgAAC7WCAAAq0UIAAAlGwgAACJBA= Date: Thu, 13 Feb 2014 14:57:56 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 14:58:05 -0000 Dear Mohamed, Before TDF was part of 3GPP standard (R11), it was indeed the case. Howev= er, starting from R11, for mobile networks, DPI equipment is nothing else= =20but "TDF".=20 Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, February 13, 2014 4:51 PM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt Re-, I hear your argument, but the point is we cannot ignore existing deployme= nts that are not relying on such functional element. We should reflect bo= th situations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier=20 >2014 15:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present=20 >standardized Mobile Network (defined by a different SDO i.e. 3GPP and=20 >not within a scope of IETF) it is very important to reference the=20 >existing well-defined Network Elements. DPI functionality in mobile=20 >network is fulfilled by the TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >agoldner@allot.com www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]= >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f= =E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interfa= ce. >The TDF text is just after a paragraph starting with "Gi Interface ...".= =20We >can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks tha= t >are not compliant with 3GPP specifications. Instead of updating existing= >figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available a= t: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will);= >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized elemen= t >>>residing on Gi/SGi which implements DPI (detection) functionality alon= g >>>with enforcement and charging of the corresponding detected >>>applications. This is missing from your use case description. I think >>>such a comment was already provided in a different email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications Tel= >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will= ) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-case= s- >>>01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the secti= on >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-= >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cas= es/ >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-c= ases- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism i= s >>> called Service Function Chaining (SFC). The set of involved Servic= e >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>######################################################################= ### ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or >>>distribute this message. >>>If you have mistakenly received this message, please notify the sender= =20by >>a >>>reply e-mail and delete this message. >>>Thank you. >>>######################################################################= ### ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>#######################################################################= ### ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender = by >a >>reply e-mail and delete this message. >>Thank you. >>#######################################################################= ### ># >>################### >########################################################################= ### >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender b= y a >reply e-mail and delete this message. >Thank you. >########################################################################= ### >################### #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From Ron_Parker@affirmednetworks.com Thu Feb 13 07:06:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0861A0294 for ; Thu, 13 Feb 2014 07:06:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D456CqCsDfBS for ; Thu, 13 Feb 2014 07:06:09 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id A78231A0246 for ; Thu, 13 Feb 2014 07:06:09 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 07:06:08 -0800 From: Ron Parker To: Alla Goldner , "mohamed.boucadair@orange.com" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKL3ISFl6/B9QwEud3/RyACSrcZqzvACAgAAGh4CAAAXegIAAAjIAgAAB/gD//3u3oA== Date: Thu, 13 Feb 2014 15:06:07 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 15:06:14 -0000 In a generic sense, yes, all DPI's are "Traffic Detection Functions". But= , I think that TDF in the 3gpp sense implies support of the DIAMETER Sd int= erface, too., Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 9:58 AM To: mohamed.boucadair@orange.com; Liushucheng (Will); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Dear Mohamed, Before TDF was part of 3GPP standard (R11), it was indeed the case. However= , starting from R11, for mobile networks, DPI equipment is nothing else but= "TDF".=20 Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Thursday, February 13, 2014 4:51 PM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Re-, I hear your argument, but the point is we cannot ignore existing deployment= s that are not relying on such functional element. We should reflect both s= ituations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier=20 >2014 15:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present=20 >standardized Mobile Network (defined by a different SDO i.e. 3GPP and=20 >not within a scope of IETF) it is very important to reference the=20 >existing well-defined Network Elements. DPI functionality in mobile=20 >network is fulfilled by the TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >agoldner@allot.com www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f= =E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interface= . >The TDF text is just after a paragraph starting with "Gi Interface ...". W= e >can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks that >are not compliant with 3GPP specifications. Instead of updating existing >figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available at: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will); >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized element >>>residing on Gi/SGi which implements DPI (detection) functionality along >>>with enforcement and charging of the corresponding detected >>>applications. This is missing from your use case description. I think >>>such a comment was already provided in a different email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >>>01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the section >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism is >>> called Service Function Chaining (SFC). The set of involved Service >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>########################################################################= # ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or >>>distribute this message. >>>If you have mistakenly received this message, please notify the sender b= y >>a >>>reply e-mail and delete this message. >>>Thank you. >>>########################################################################= # ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>#########################################################################= # ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender by >a >>reply e-mail and delete this message. >>Thank you. >>#########################################################################= # ># >>################### >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From jmh@joelhalpern.com Thu Feb 13 07:10:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C761A02AA for ; Thu, 13 Feb 2014 07:10:00 -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 V-UQPBpTfGdP for ; Thu, 13 Feb 2014 07:09:56 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDD1A02A2 for ; Thu, 13 Feb 2014 07:09:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 857681BD6323; Thu, 13 Feb 2014 07:09:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2BA3F1BD6314; Thu, 13 Feb 2014 07:09:53 -0800 (PST) Message-ID: <52FCE047.2010705@joelhalpern.com> Date: Thu, 13 Feb 2014 10:09:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Dave Dolson , "'Nicolas.BOUTHORS@qosmos.com'" , "'Ron_Parker@affirmednetworks.com'" , "'paulq@cisco.com'" References: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:10:00 -0000 There is a related complexity. I hope that we expect to support IPv6. IPv6 explicitly prohibits network elements from fragmenting end user packets. Yours, Joel On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: > Re-, > > FWIW, one of the existing architecture drafts includes the following behavior (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): > > " > 6. Fragmentation Considerations > > If adding the Service Chaining Header would result in a fragmented > packet, the classifier should include a Service Chaining Header in > each fragment. Doing so would prevent SF Nodes to dedicate resource > to handle fragments. > " > > Cheers, > Med > > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson >> Envoyé : jeudi 13 février 2014 13:39 >> À : 'Nicolas.BOUTHORS@qosmos.com'; 'Ron_Parker@affirmednetworks.com'; >> 'jmh@joelhalpern.com'; 'paulq@cisco.com' >> Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >> Objet : Re: [sfc] Framework >> >> Good point to consider fragmentation. >> >> We should design the encapsulation such that the forwarding functions do >> not need to reassemble. Each fragment should be independently forwardable; >> some SFs may choose to ignore these packets. >> >> Any layer 2.5 protocol like VLAN or MPLS would support this. >> Otherwise, a reassembly layer could be added after the forwarding >> coordinates. Think of something like the IPv6 reassembly option after a GRE >> header, for instance. >> >> IP | GRE | reassem | frag data >> >> We could alternatively mandate the inner IP be fragmented and that path-MTU >> discovery be supported. >> >> >> >> >> ----- Original Message ----- >> From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] >> Sent: Thursday, February 13, 2014 04:13 AM >> To: Ron Parker ; Dave Dolson; Joel M. >> Halpern ; Paul Quinn (paulq) >> Cc: Sumandra Majee ; sfc@ietf.org ; Linda >> Dunbar >> Subject: Re: [sfc] Framework >> >> If we do not enforce a fix header size we have other implication. >> >> There is the question of segmentation and reassembly responsibility as >> well. >> >> If adding length to the service header forces segmentation, then whose >> responsibility is it >> to reassemble the payload before passing it to the SF. >> >> Similar question for packet re-ordering. >> >> >> ________________________________________ >> From: Ron Parker [Ron_Parker@affirmednetworks.com] >> Sent: Wednesday, February 12, 2014 11:25 PM >> To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> Dave, >> >> Yes, that is a good point if we logically separate the forwarding function >>from the SFC-aware service function, as we should. The forwarding >> function is concerned with only the inbound transport header, the fixed >> portion of the service header containing the chain information, and the >> outbound transport header. The service function may look at the entirety >> of the service header and would look at the encapsulated packet. >> >> Ron >> >> >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Wednesday, February 12, 2014 5:18 PM >> To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: RE: [sfc] Framework >> >> The forwarding plane might not even need to look at the encapsulated >> packet. >> >> For example, (if the SF Identifier is a VLAN tag), an Ethernet switch can >> forward packets of the form: Ether | VLAN | BLOB. >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 4:30 PM >> To: Ron Parker; Dave Dolson; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> I agree as well. >> Yours, >> Joel >> >> On 2/12/14, 4:24 PM, Ron Parker wrote: >>> Hi, Dave. >>> >>> I Agree with your statement. And if the total length of the header is >> contained in the mandatory portion, the hardware implementation can easily >> locate the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: Wednesday, February 12, 2014 4:10 PM >>> To: Ron Parker; Paul Quinn (paulq) >>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: RE: [sfc] Framework >>> >>> I think a good approach would be: >>> >>> The information required for forwarding (the SF Identifier) should be in >> a mandatory fixed-size header. >>> >>> Optional information (if any) is NOT to be used for forwarding, but is >> for consumption by one or more of the applications in the chain. >>> >>> Then the forwarding plane, and even the PDP, can be agnostic about the >> meta-data. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Wednesday, February 12, 2014 4:05 PM >>> To: Paul Quinn (paulq) >>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Paul, >>> >>> That is why I am proposing a hybrid where extensions or options can be >> added but the total length is contained in the fixed portion. I can >> envision certain deployments (e.g., Enterprise) where perhaps extensions >> are not needed and the SFC functionality is realized in hardware. And, I >> can envision certain other deployments (e.g., 3gpp) where the extension >> headers add sufficient value to justify software based implementations. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >>> Sent: Wednesday, February 12, 2014 3:40 PM >>> To: Ron Parker >>> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Hi, >>> >>> We certainly need to be very careful with variable length headers when >> hardware platform are in play. >>> >>> Ron, your examples of IP options and v6 EH have both suffered from >> significant implementation and deployment hurdles due to the complexity and >> cost associated with hardware support for the option/EH. >>> >>> Paul >>> >>> On Feb 12, 2014, at 3:10 PM, Ron Parker >> wrote: >>> >>>> Hi, Sumandra. >>>> >>>> Regarding service header flexibility, I completely agree. I might >> suggest a compromise between hardware friendliness and software >> flexibility. If the header had the ability to add extensions (perhaps >> similar to IPv6) but also had the header length encoded in the mandatory >> part (like IPv4), then a hardware implementation would be free to skip over >> the extensions (in cases where the deployment justifies ignoring the >> extensions). >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> Sent: Wednesday, February 12, 2014 3:04 PM >>>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>>>> For all of those reasons, I strongly support a canonical service >>>>>> header that is independent of the transport methodology. >>>> >>>> >>>> I agree. However the format of service header should be standardized in >> a way that is flexible. Some of us would like to see variable length header >> that is also HW friendly. The service header can be represented as a >> mandotory fixed length header (like IP header) along with an optional >> variable length attribute field. Different services can be interested in >> different metadata, for example subscriber ID could be of interest in the >> mobile core service chain only. >>>> >>>> Sumandra >>>> >>>> On 2/12/14, 11:32 AM, "Ron Parker" >> wrote: >>>> >>>>> Linda, >>>>> >>>>> My interpretation of the architecture docs is that the service >>>>> function chain is built in an abstract manner (i.e., SF-A then SF-B >> then SF-C). >>>>> Separately, a locator table provides network location for each of those >>>>> service functions. In this way, you can locate the service functions >> in >>>>> a manner appropriate to the type of transport you are using. If you >>>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >> address, >>>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>>> potentially locate different service functions that reside in the same >>>>> chain with different flavors of network locators. Another >>>>> justification to separate the identity of a service function from its >>>>> network location is load balancing. If, for example, SF-A had 3 IP >>>>> addresses, that would imply load balancing to 3 instances using IP >>>>> as a transport layer. >>>>> >>>>> For all of those reasons, I strongly support a canonical service header >>>>> that is independent of the transport methodology. At a particular >>>>> node, the decision as to where to go next should be based solely on >>>>> information carried in the canonical service header and not on the >> fields >>>>> in the transport header. That is, the SFC node discards the transport >>>>> header and extracts the chain ID from the service header. Through >>>>> mechanisms we have not yet begun to discuss, the SFC node knows how >>>>> to interpret the chain ID and ultimately how to progress the packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>>> To: Joel M. Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>> Classifier) to emphasize this point. >>>>> >>>>> "A Service Chain Classifier node can associate a unique Layer 2 or >>>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>>>> Layer >>>>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>>>> path to steer the flow to the service functions specified by the >>>>> flow's service chain." >>>>> >>>>> >>>>> Linda >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>>> To: sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework proposal. >>>>> The proposal has a very specific model of the scope of the transport >>>>> header (that it is derived from, and relates only to, the first >>>>> service function to which the packet will be directed. >>>>> That is clearly an operational model we need to support. >>>>> >>>>> However, I would like to allow other transport operational models, >>>>> such as the use of a VLAN to direct traffic along a chain. Or the >>>>> use of an MPLS label, or an MPLS label stack. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 smkumar@cisco.com Thu Feb 13 07:15:37 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC7D1A0209 for ; Thu, 13 Feb 2014 07:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuTFNnuHNo2V for ; Thu, 13 Feb 2014 07:15:33 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id CB9431A0296 for ; Thu, 13 Feb 2014 07:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13485; q=dns/txt; s=iport; t=1392304528; x=1393514128; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=11KWaSxpkXVNtmU3Ofn7iq9lng/SupPFW04x6kIvAOg=; b=DvAmXwU5TOYgWvnzJed5KbZ6s7yB4C4DU6HK3bkgMozt8SJsIzK281iw IwrqO6HqLj5X3/WnvOQxMuNq4fqXo6kkyRqP0gnknnIApqRbDDkD52p1J AqaTxllwGJB8eqqiuFEfi9Pwox5rJu8e9ID5e29iLeaVjoVNaah4t3VOT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEXh/FKtJV2c/2dsb2JhbABQCYMGOFe/TIEXFnSCJQEBAQQBAQFREwcLDAQCAQgRAQMBAQEnBycLFAMGCAIEAQ0FiAUNx3wXjh4wKwcCBIQyBIkQjxyBMpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="20183375" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 13 Feb 2014 15:15:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DFFQv5028379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 15:15:27 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 09:15:26 -0600 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Dave Dolson , "'Nicolas.BOUTHORS@qosmos.com'" , "'Ron_Parker@affirmednetworks.com'" , "Paul Quinn (paulq)" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T9QcfaE2BvUyAObGffF4A4JqyPG4AgAAqPQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgP//e2cA Date: Thu, 13 Feb 2014 15:15:26 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> <52FCE047.2010705@joelhalpern.com> In-Reply-To: <52FCE047.2010705@joelhalpern.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: [10.21.87.182] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <29B049C4A48FB44A8A8761CE1A12A16C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:15:38 -0000 It is a given that the architecture support both v4 & v6 while at the same time we should not mandate one over the other. Surendra. On 2/13/14 7:09 AM, "Joel M. Halpern" wrote: >There is a related complexity. >I hope that we expect to support IPv6. >IPv6 explicitly prohibits network elements from fragmenting end user >packets. > >Yours, >Joel > >On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following >>behavior=20 >>(http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented >> packet, the classifier should include a Service Chaining Header in >> each fragment. Doing so would prevent SF Nodes to dedicate resource >> to handle fragments. >> " >> >> Cheers, >> Med >> >> >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson >>> Envoy=E9 : jeudi 13 f=E9vrier 2014 13:39 >>> =C0 : 'Nicolas.BOUTHORS@qosmos.com'; 'Ron_Parker@affirmednetworks.com'; >>> 'jmh@joelhalpern.com'; 'paulq@cisco.com' >>> Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >>> Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding functions >>>do >>> not need to reassemble. Each fragment should be independently >>>forwardable; >>> some SFs may choose to ignore these packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding >>> coordinates. Think of something like the IPv6 reassembly option after >>>a GRE >>> header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that >>>path-MTU >>> discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] >>> Sent: Thursday, February 13, 2014 04:13 AM >>> To: Ron Parker ; Dave Dolson; Joel M. >>> Halpern ; Paul Quinn (paulq) >>> Cc: Sumandra Majee ; sfc@ietf.org ; Linda >>> Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility as >>> well. >>> >>> If adding length to the service header forces segmentation, then whose >>> responsibility is it >>> to reassemble the payload before passing it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ >>> From: Ron Parker [Ron_Parker@affirmednetworks.com] >>> Sent: Wednesday, February 12, 2014 11:25 PM >>> To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >>> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>>function >>>from the SFC-aware service function, as we should. The forwarding >>> function is concerned with only the inbound transport header, the fixed >>> portion of the service header containing the chain information, and the >>> outbound transport header. The service function may look at the >>>entirety >>> of the service header and would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: Wednesday, February 12, 2014 5:18 PM >>> To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) >>> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: RE: [sfc] Framework >>> >>> The forwarding plane might not even need to look at the encapsulated >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet switch >>>can >>> forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 4:30 PM >>> To: Ron Parker; Dave Dolson; Paul Quinn (paulq) >>> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. >>> Yours, >>> Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>>header is >>> contained in the mandatory portion, the hardware implementation can >>>easily >>> locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>>> Sent: Wednesday, February 12, 2014 4:10 PM >>>> To: Ron Parker; Paul Quinn (paulq) >>>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should be >>>>in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>>> Sent: Wednesday, February 12, 2014 4:05 PM >>>> To: Paul Quinn (paulq) >>>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can be >>> added but the total length is contained in the fixed portion. I can >>> envision certain deployments (e.g., Enterprise) where perhaps >>>extensions >>> are not needed and the SFC functionality is realized in hardware. >>>And, I >>> can envision certain other deployments (e.g., 3gpp) where the extension >>> headers add sufficient value to justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >>>> Sent: Wednesday, February 12, 2014 3:40 PM >>>> To: Ron Parker >>>> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the >>>complexity and >>> cost associated with hardware support for the option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>>(perhaps >>> similar to IPv6) but also had the header length encoded in the >>>mandatory >>> part (like IPv4), then a hardware implementation would be free to skip >>>over >>> the extensions (in cases where the deployment justifies ignoring the >>> extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>> Sent: Wednesday, February 12, 2014 3:04 PM >>>>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be standardized >>>>>in >>> a way that is flexible. Some of us would like to see variable length >>>header >>> that is also HW friendly. The service header can be represented as a >>> mandotory fixed length header (like IP header) along with an optional >>> variable length attribute field. Different services can be interested >>>in >>> different metadata, for example subscriber ID could be of interest in >>>the >>> mobile core service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service >>>>>> function chain is built in an abstract manner (i.e., SF-A then SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for each of >>>>>>those >>>>>> service functions. In this way, you can locate the service >>>>>>functions >>> in >>>>>> a manner appropriate to the type of transport you are using. If >>>>>>you >>>>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>>>> potentially locate different service functions that reside in the >>>>>>same >>>>>> chain with different flavors of network locators. Another >>>>>> justification to separate the identity of a service function from >>>>>>its >>>>>> network location is load balancing. If, for example, SF-A had 3 IP >>>>>> addresses, that would imply load balancing to 3 instances using IP >>>>>> as a transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service >>>>>>header >>>>>> that is independent of the transport methodology. At a particular >>>>>> node, the decision as to where to go next should be based solely on >>>>>> information carried in the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards the >>>>>>transport >>>>>> header and extracts the chain ID from the service header. Through >>>>>> mechanisms we have not yet begun to discuss, the SFC node knows how >>>>>> to interpret the chain ID and ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>>>> To: Joel M. Halpern; sfc@ietf.org >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer >>>>>>2 or >>>>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those >>>>>> Layer >>>>>> 2 or 3 Label makes it easier for subsequent nodes along the flow >>>>>> path to steer the flow to the service functions specified by the >>>>>> flow's service chain." >>>>>> >>>>>> >>>>>> Linda >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>>>> To: sfc@ietf.org >>>>>> Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. >>>>>> The proposal has a very specific model of the scope of the transport >>>>>> header (that it is derived from, and relates only to, the first >>>>>> service function to which the packet will be directed. >>>>>> That is clearly an operational model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational models, >>>>>> such as the use of a VLAN to direct traffic along a chain. Or the >>>>>> use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Thu Feb 13 07:18:38 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FA1A02C6 for ; Thu, 13 Feb 2014 07:18:38 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F96Oh1sXE7pR for ; Thu, 13 Feb 2014 07:18:33 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id D71D01A02A3 for ; Thu, 13 Feb 2014 07:18:33 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 07:18:32 -0800 From: Ron Parker To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Dave Dolson , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA Date: Thu, 13 Feb 2014 15:18:32 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> <52FCE047.2010705@joelhalpern.com> In-Reply-To: <52FCE047.2010705@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:18:38 -0000 Joel, That is an excellent point to consider when choosing transport encapsulatio= ns. If the transport encapsulation is IPv4 or IPv6 based (i.e., IPx/UDP, = IPx/GRE, IPx/UDP/VxLAN, etc.), then fragmentation and defragmentation are n= aturally supported. If the transport encapsulation is VLAN, MPLS, etc., = then I believe one of the following must be true: * The end-to-end path is known to support the resulting larger frames * A path discovery mechanism is mandated by SFC when non-IP transports are = used * An SFC-specific fragmentation header and mechanisms must be defined (i.e.= , SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, February 13, 2014 10:10 AM To: mohamed.boucadair@orange.com; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.com= '; Ron Parker; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework There is a related complexity. I hope that we expect to support IPv6. IPv6 explicitly prohibits network elements from fragmenting end user packet= s. Yours, Joel On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: > Re-, > > FWIW, one of the existing architecture drafts includes the following beha= vior (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6= ): > > " > 6. Fragmentation Considerations > > If adding the Service Chaining Header would result in a fragmented > packet, the classifier should include a Service Chaining Header in > each fragment. Doing so would prevent SF Nodes to dedicate resource > to handle fragments. > " > > Cheers, > Med > > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson=20 >> Envoy=E9 : jeudi 13 f=E9vrier 2014 13:39 =C0 :=20 >> 'Nicolas.BOUTHORS@qosmos.com'; 'Ron_Parker@affirmednetworks.com'; >> 'jmh@joelhalpern.com'; 'paulq@cisco.com' >> Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >> Objet : Re: [sfc] Framework >> >> Good point to consider fragmentation. >> >> We should design the encapsulation such that the forwarding functions=20 >> do not need to reassemble. Each fragment should be independently=20 >> forwardable; some SFs may choose to ignore these packets. >> >> Any layer 2.5 protocol like VLAN or MPLS would support this. >> Otherwise, a reassembly layer could be added after the forwarding=20 >> coordinates. Think of something like the IPv6 reassembly option after=20 >> a GRE header, for instance. >> >> IP | GRE | reassem | frag data >> >> We could alternatively mandate the inner IP be fragmented and that=20 >> path-MTU discovery be supported. >> >> >> >> >> ----- Original Message ----- >> From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com] >> Sent: Thursday, February 13, 2014 04:13 AM >> To: Ron Parker ; Dave Dolson; Joel M. >> Halpern ; Paul Quinn (paulq) >> Cc: Sumandra Majee ; sfc@ietf.org ;=20 >> Linda Dunbar >> Subject: Re: [sfc] Framework >> >> If we do not enforce a fix header size we have other implication. >> >> There is the question of segmentation and reassembly responsibility=20 >> as well. >> >> If adding length to the service header forces segmentation, then=20 >> whose responsibility is it to reassemble the payload before passing=20 >> it to the SF. >> >> Similar question for packet re-ordering. >> >> >> ________________________________________ >> From: Ron Parker [Ron_Parker@affirmednetworks.com] >> Sent: Wednesday, February 12, 2014 11:25 PM >> To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> Dave, >> >> Yes, that is a good point if we logically separate the forwarding functi= on >>from the SFC-aware service function, as we should. The forwarding >> function is concerned with only the inbound transport header, the=20 >>fixed portion of the service header containing the chain information, an= d the >> outbound transport header. The service function may look at the entir= ety >> of the service header and would look at the encapsulated packet. >> >> Ron >> >> >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Wednesday, February 12, 2014 5:18 PM >> To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: RE: [sfc] Framework >> >> The forwarding plane might not even need to look at the encapsulated=20 >> packet. >> >> For example, (if the SF Identifier is a VLAN tag), an Ethernet switch=20 >> can forward packets of the form: Ether | VLAN | BLOB. >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 4:30 PM >> To: Ron Parker; Dave Dolson; Paul Quinn (paulq) >> Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> I agree as well. >> Yours, >> Joel >> >> On 2/12/14, 4:24 PM, Ron Parker wrote: >>> Hi, Dave. >>> >>> I Agree with your statement. And if the total length of the header = is >> contained in the mandatory portion, the hardware implementation can=20 >> easily locate the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Dave Dolson [mailto:ddolson@sandvine.com] >>> Sent: Wednesday, February 12, 2014 4:10 PM >>> To: Ron Parker; Paul Quinn (paulq) >>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: RE: [sfc] Framework >>> >>> I think a good approach would be: >>> >>> The information required for forwarding (the SF Identifier) should=20 >>> be in >> a mandatory fixed-size header. >>> >>> Optional information (if any) is NOT to be used for forwarding, but=20 >>> is >> for consumption by one or more of the applications in the chain. >>> >>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>> the >> meta-data. >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Wednesday, February 12, 2014 4:05 PM >>> To: Paul Quinn (paulq) >>> Cc: Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Paul, >>> >>> That is why I am proposing a hybrid where extensions or options can=20 >>> be >> added but the total length is contained in the fixed portion. I can >> envision certain deployments (e.g., Enterprise) where perhaps extensions >> are not needed and the SFC functionality is realized in hardware. And,= I >> can envision certain other deployments (e.g., 3gpp) where the=20 >> extension headers add sufficient value to justify software based impleme= ntations. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >>> Sent: Wednesday, February 12, 2014 3:40 PM >>> To: Ron Parker >>> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Hi, >>> >>> We certainly need to be very careful with variable length headers=20 >>> when >> hardware platform are in play. >>> >>> Ron, your examples of IP options and v6 EH have both suffered from >> significant implementation and deployment hurdles due to the=20 >> complexity and cost associated with hardware support for the option/EH. >>> >>> Paul >>> >>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>> >> wrote: >>> >>>> Hi, Sumandra. >>>> >>>> Regarding service header flexibility, I completely agree. I might >> suggest a compromise between hardware friendliness and software >> flexibility. If the header had the ability to add extensions (perhaps >> similar to IPv6) but also had the header length encoded in the=20 >> mandatory part (like IPv4), then a hardware implementation would be=20 >> free to skip over the extensions (in cases where the deployment=20 >> justifies ignoring the extensions). >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> Sent: Wednesday, February 12, 2014 3:04 PM >>>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport methodology. >>>> >>>> >>>> I agree. However the format of service header should be=20 >>>> standardized in >> a way that is flexible. Some of us would like to see variable length=20 >> header that is also HW friendly. The service header can be=20 >> represented as a mandotory fixed length header (like IP header) along=20 >> with an optional variable length attribute field. Different services=20 >> can be interested in different metadata, for example subscriber ID=20 >> could be of interest in the mobile core service chain only. >>>> >>>> Sumandra >>>> >>>> On 2/12/14, 11:32 AM, "Ron Parker"=20 >>>> >> wrote: >>>> >>>>> Linda, >>>>> >>>>> My interpretation of the architecture docs is that the service=20 >>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>> SF-B >> then SF-C). >>>>> Separately, a locator table provides network location for each of tho= se >>>>> service functions. In this way, you can locate the service function= s >> in >>>>> a manner appropriate to the type of transport you are using. If you >>>>> want that to be interface+VLAN, gateway-IP+MPLS label stack, IP >> address, >>>>> GRE tunnel remote IP + key, etc., you can do that. You can even >>>>> potentially locate different service functions that reside in the sam= e >>>>> chain with different flavors of network locators. Another >>>>> justification to separate the identity of a service function from its >>>>> network location is load balancing. If, for example, SF-A had 3 IP >>>>> addresses, that would imply load balancing to 3 instances using IP=20 >>>>> as a transport layer. >>>>> >>>>> For all of those reasons, I strongly support a canonical service head= er >>>>> that is independent of the transport methodology. At a particular >>>>> node, the decision as to where to go next should be based solely=20 >>>>> on information carried in the canonical service header and not on=20 >>>>> the >> fields >>>>> in the transport header. That is, the SFC node discards the transpo= rt >>>>> header and extracts the chain ID from the service header. Through >>>>> mechanisms we have not yet begun to discuss, the SFC node knows=20 >>>>> how to interpret the chain ID and ultimately how to progress the pack= et. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, 2014 12:01 PM >>>>> To: Joel M. Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>> Classifier) to emphasize this point. >>>>> >>>>> "A Service Chain Classifier node can associate a unique Layer=20 >>>>> 2 or >>>>> 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. Those=20 >>>>> Layer >>>>> 2 or 3 Label makes it easier for subsequent nodes along the flow=20 >>>>> path to steer the flow to the service functions specified by the=20 >>>>> flow's service chain." >>>>> >>>>> >>>>> Linda >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M.=20 >>>>> Halpern >>>>> Sent: Wednesday, February 12, 2014 10:20 AM >>>>> To: sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework proposal. >>>>> The proposal has a very specific model of the scope of the=20 >>>>> transport header (that it is derived from, and relates only to,=20 >>>>> the first service function to which the packet will be directed. >>>>> That is clearly an operational model we need to support. >>>>> >>>>> However, I would like to allow other transport operational models,=20 >>>>> such as the use of a VLAN to direct traffic along a chain. Or the=20 >>>>> use of an MPLS label, or an MPLS label stack. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 jmoisand@juniper.net Thu Feb 13 07:26:54 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7441A0273 for ; Thu, 13 Feb 2014 07:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecgZUh1VjtRf for ; Thu, 13 Feb 2014 07:26:49 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id D9A791A0209 for ; Thu, 13 Feb 2014 07:26:48 -0800 (PST) Received: from mail20-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 15:26:47 +0000 Received: from mail20-ch1 (localhost [127.0.0.1]) by mail20-ch1-R.bigfish.com (Postfix) with ESMTP id 7789A300126; Thu, 13 Feb 2014 15:26:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z579ehf7Iz9371Ic89bh936eId772h1102I542I1432I12d5I4015I1447I14ffI9a6kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdch70kz1de098h1033IL17326ah8275bh8275dh1de097h186068h18602ehz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail20-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(48214007)(377424004)(377454003)(53754006)(189002)(199002)(2473001)(43544003)(164054003)(13464003)(51914003)(2656002)(74876001)(87266001)(74316001)(74366001)(90146001)(74706001)(81542001)(87936001)(81342001)(85852003)(93136001)(81686001)(49866001)(69226001)(4396001)(76796001)(76576001)(76786001)(15202345003)(2201001)(92566001)(56816005)(83072002)(95666001)(95416001)(79102001)(19580405001)(19580395003)(77982001)(56776001)(93516002)(59766001)(80976001)(54316002)(85306002)(65816001)(33646001)(551544002)(86362001)(74502001)(31966008)(74662001)(50986001)(83322001)(15974865002)(47976001)(81816001)(15975445006)(94946001)(47736001)(66066001)(51856001)(76482001)(54356001)(80022001)(53806001)(94316002)(47446002)(63696002)(46102001)(24704002)(921002)(1121002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB714; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:E7EFFDE5.ABFAE381.8DD8FC4B.82258848.2093B; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail20-ch1 (localhost.localdomain [127.0.0.1]) by mail20-ch1 (MessageSwitch) id 1392305205377287_28126; Thu, 13 Feb 2014 15:26:45 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail20-ch1.bigfish.com (Postfix) with ESMTP id 5725C48005A; Thu, 13 Feb 2014 15:26:45 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 15:26:44 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 15:26:43 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 15:26:40 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 15:26:40 +0000 From: Jerome Moisand To: Alla Goldner , Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDdosdAlrriM0Oe9XZXROZkwZqmCQKAgAH2hQCAAmPrAIADhxoAgAROqDCAAJNYAIAAk1Hg Date: Thu, 13 Feb 2014 15:26:39 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:26:54 -0000 Alla & folks, Well... I don't know... Getting deep in network architectures and the role = of the various network elements is indeed crucial. Both 3GPP and BBF (Broad= band Forum) did a lot of work in the past decade to define architecture & n= odal requirements, which shaped in turn the deployment of all major Service= Providers worldwide. So quite clearly, service chaining have to build on t= hat and find a good way to insert itself into such architectures while exte= nding them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for s= ervice classification/enforcement, as it... already does it for its own pur= pose! This is BY NATURE a highly scalable subscriber & service management s= ystem, classifying and enforcing policies (usually L3, occasionally higher)= , and fully integrated with the HSS/PCRF chain which holds the subscriber/s= ervice authentication & authorization data. As such, service classification= *and* service enforcement (and service accounting) is already there. For 1= 00% of the mobile (data) subscribers. Sure enough, a TDF system may also do= its own form of service classification (and processing too), but let's not= forget this is an OPTIONAL system on the data path on the recently defined= 3GPP architectures you referred to. For many use cases, there is just no p= oint going through a DPI function. While for other use cases, there is clea= rly such a point, but only when it brings clear value for a given service c= onstruct, only applicable to corresponding subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary su= bscriber management system on the data path, fully integrated with a AAA sy= stem, and already doing service classification *and* service processing at = scale for 100% of the subscribers. Any classification/enforcement system be= hind it is optional and only applicable to a subset of services & subscribe= rs. Bottomline: sure, use cases with TDF should be described, but PGW-centric u= se cases remain the rule, not the exception. And double-clicking on existin= g standardized network architectures (e.g. 3GPP and BBF) and related deploy= ments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE;= Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tool= s.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Function= ) for providing ADC (Application Detection and Control) Rules for applicati= on detection, enforcement and also charging starting from R12. Please see a= rchitecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with th= e GGSN (via Diameter), not the service functions, do you mean "for the GGSN= (or the flow classifier) to carry the data passed down from PCRF to packet= s' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service treatm= ent, i.e. desired sequence of service functions, to specific flows based on= the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions." is not correct as well as PGW/PC= EF is not the only element which enforces different support per different f= lows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architectur= e and make assumptions and conclusions about potential 3GPP elements functi= onality which are not in scope of IETF. If we want to define use cases for = 3GPP networks, then we should show correct picture of 3GPP architecture wi= thout redesigning it and leave 3GPP Network Elements functionality potentia= l extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; = Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sf= c@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID?=20 I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good.=20 Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions.=20 =20 | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF | | |Network| =20 | | < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 | | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph=20 >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not=20 >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From jmh@joelhalpern.com Thu Feb 13 07:31:23 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166E81A020D for ; Thu, 13 Feb 2014 07:31:23 -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 cWKq0sBahlqD for ; Thu, 13 Feb 2014 07:31:18 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D08FD1A02CD for ; Thu, 13 Feb 2014 07:31:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 02AA91BD66B7; Thu, 13 Feb 2014 07:31:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE1E41BD67DD; Thu, 13 Feb 2014 07:31:15 -0800 (PST) Message-ID: <52FCE54A.5090403@joelhalpern.com> Date: Thu, 13 Feb 2014 10:31:22 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ron Parker , "mohamed.boucadair@orange.com" , Dave Dolson , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" References: <76B41B8FACE1514795D30EC137FF391D3E50EA@LILAS.jungle.qosmos.com> <94C682931C08B048B7A8645303FDC9F36F4C31EADC@PUEXCB1B.nanterre.francetelecom.fr> <52FCE047.2010705@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:31:23 -0000 I mostly agree with you Ron. I can probably come up with some other variations, but your second point is that the transport must deal with the issue of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is being fragmented, then we are assuming that the exit from service chaining can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of > the following must be true: > > * The end-to-end path is known to support the resulting larger > frames * A path discovery mechanism is mandated by SFC when non-IP > transports are used * An SFC-specific fragmentation header and > mechanisms must be defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10 > AM To: mohamed.boucadair@orange.com; Dave Dolson; > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support > IPv6. IPv6 explicitly prohibits network elements from fragmenting end > user packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the >> following behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented >> packet, the classifier should include a Service Chaining Header in >> each fragment. Doing so would prevent SF Nodes to dedicate >> resource to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc >>> [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoyé : >>> jeudi 13 février 2014 13:39 À : 'Nicolas.BOUTHORS@qosmos.com'; >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com'; >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding >>> functions do not need to reassemble. Each fragment should be >>> independently forwardable; some SFs may choose to ignore these >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the >>> forwarding coordinates. Think of something like the IPv6 >>> reassembly option after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and >>> that path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ; >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other >>> implication. >>> >>> There is the question of segmentation and reassembly >>> responsibility as well. >>> >>> If adding length to the service header forces segmentation, then >>> whose responsibility is it to reassemble the payload before >>> passing it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header >>> and would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] >>> Framework >>> >>> The forwarding plane might not even need to look at the >>> encapsulated packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda >>> Dunbar Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation >>> can easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) >>>> should be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, >>>> but is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic >>>> about the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options >>>> can be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq) >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel >>>> M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length >>>> headers when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered >>>> from >>> significant implementation and deployment hurdles due to the >>> complexity and cost associated with hardware support for the >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded >>> in the mandatory part (like IPv4), then a hardware implementation >>> would be free to skip over the extensions (in cases where the >>> deployment justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical >>>>>>> service header that is independent of the transport >>>>>>> methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable >>> length header that is also HW friendly. The service header can >>> be represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for >>> example subscriber ID could be of interest in the mobile core >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the >>>>>> service function chain is built in an abstract manner >>>>>> (i.e., SF-A then SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions >>>>>> that reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as >>>>>> a transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical >>>>>> service header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information >>>>>> carried in the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain >>>>>> ID and ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 >>>>>> (SFC Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique >>>>>> Layer 2 or 3 Label (e.g. VLAN, MPLS label) to the packets >>>>>> in the flow. Those Layer 2 or 3 Label makes it easier for >>>>>> subsequent nodes along the flow path to steer the flow to >>>>>> the service functions specified by the flow's service >>>>>> chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a >>>>>> very specific model of the scope of the transport header >>>>>> (that it is derived from, and relates only to, the first >>>>>> service function to which the packet will be directed. That >>>>>> is clearly an operational model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational >>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>> chain. Or the use of an MPLS label, or an MPLS label >>>>>> stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ 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 >>>> >>>> _______________________________________________ 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 agoldner@allot.com Thu Feb 13 07:35:57 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF81A02C6 for ; Thu, 13 Feb 2014 07:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 CElw12kymt6m for ; Thu, 13 Feb 2014 07:35:51 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1A1A02B4 for ; Thu, 13 Feb 2014 07:35:48 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 17:35:46 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 17:35:46 +0200 From: Alla Goldner To: Ron Parker , "mohamed.boucadair@orange.com" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKM0iCNhMnD56qkOvMcWU8mHwZpqzUJXw Date: Thu, 13 Feb 2014 15:35:45 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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: Thu, 13 Feb 2014 15:35:57 -0000 Dear Ron, all, Yes, the standardized means to define TDF (DPI) in mobile network within = 3GPP specifications is to define Sd interface between the TDF and the PCR= F. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Thursday, February 13, 2014 5:06 PM To: Alla Goldner; mohamed.boucadair@orange.com; Liushucheng (Will); sfc@i= etf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt In a generic sense, yes, all DPI's are "Traffic Detection Functions". B= ut, I think that TDF in the 3gpp sense implies support of the DIAMETER Sd= =20interface, too., =20 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 9:58 AM To: mohamed.boucadair@orange.com; Liushucheng (Will); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt Dear Mohamed, Before TDF was part of 3GPP standard (R11), it was indeed the case. Howev= er, starting from R11, for mobile networks, DPI equipment is nothing else= =20but "TDF".=20 Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +9= 72 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com w= ww.allot.com -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, February 13, 2014 4:51 PM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-cas= es-01.txt Re-, I hear your argument, but the point is we cannot ignore existing deployme= nts that are not relying on such functional element. We should reflect bo= th situations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier >2014 15:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present=20 >standardized Mobile Network (defined by a different SDO i.e. 3GPP and=20 >not within a scope of IETF) it is very important to reference the=20 >existing well-defined Network Elements. DPI functionality in mobile=20 >network is fulfilled by the TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >agoldner@allot.com www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13=20 >>f=E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that = >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interfa= ce. >The TDF text is just after a paragraph starting with "Gi Interface=20 >...". We can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com=20 >>[mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- = >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available a= t: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner=20 >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will);= =20 >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my=20 >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized=20 >>>element residing on Gi/SGi which implements DPI (detection)=20 >>>functionality along with enforcement and charging of the=20 >>>corresponding detected applications. This is missing from your use=20 >>>case description. I think such a comment was already provided in a dif= ferent email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications=20 >>>Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng=20 >>>(Will) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for=20 >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the=20 >>>section >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu;=20 >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-= >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cas= es/ >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-c= ases- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism i= s >>> called Service Function Chaining (SFC). The set of involved Servic= e >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>##################################################################### >>>#### ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may=20 >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or=20 >>>distribute this message. >>>If you have mistakenly received this message, please notify the=20 >>>sender by >>a >>>reply e-mail and delete this message. >>>Thank you. >>>##################################################################### >>>#### ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>###################################################################### >>#### ># >>################### >>This message is intended only for the designated recipient(s).It may=20 >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or=20 >>distribute this message. >>If you have mistakenly received this message, please notify the sender = >>by >a >>reply e-mail and delete this message. >>Thank you. >>###################################################################### >>#### ># >>################### >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From ddolson@sandvine.com Thu Feb 13 08:03:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15F1A0305 for ; Thu, 13 Feb 2014 08:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Ym_d2st1HqRF for ; Thu, 13 Feb 2014 08:02:54 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id A1E041A0311 for ; Thu, 13 Feb 2014 08:02:53 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Thu, 13 Feb 2014 11:02:50 -0500 From: Dave Dolson To: "'jmh@joelhalpern.com'" , "'Ron_Parker@affirmednetworks.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQgABYqACAAAGugP//uNTggABWkACAALUQgP//5ao9AAFkm1AADli1gAAATHIAAAByvQAACWDfew== Date: Thu, 13 Feb 2014 16:02:50 +0000 Message-ID: In-Reply-To: <52FCE54A.5090403@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:03:00 -0000 it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM=0A= To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other=20 variations, but your second point is that the transport must deal with=20 the issue of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer)=20 is being fragmented, then we are assuming that the exit from service=20 chaining can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of > the following must be true: > > * The end-to-end path is known to support the resulting larger > frames * A path discovery mechanism is mandated by SFC when non-IP > transports are used * An SFC-specific fragmentation header and > mechanisms must be defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10 > AM To: mohamed.boucadair@orange.com; Dave Dolson; > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support > IPv6. IPv6 explicitly prohibits network elements from fragmenting end > user packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the >> following behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented >> packet, the classifier should include a Service Chaining Header in >> each fragment. Doing so would prevent SF Nodes to dedicate >> resource to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc >>> [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com'; >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com'; >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding >>> functions do not need to reassemble. Each fragment should be >>> independently forwardable; some SFs may choose to ignore these >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the >>> forwarding coordinates. Think of something like the IPv6 >>> reassembly option after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and >>> that path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ; >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other >>> implication. >>> >>> There is the question of segmentation and reassembly >>> responsibility as well. >>> >>> If adding length to the service header forces segmentation, then >>> whose responsibility is it to reassemble the payload before >>> passing it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header >>> and would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] >>> Framework >>> >>> The forwarding plane might not even need to look at the >>> encapsulated packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda >>> Dunbar Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation >>> can easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) >>>> should be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, >>>> but is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic >>>> about the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options >>>> can be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq) >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel >>>> M. Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length >>>> headers when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered >>>> from >>> significant implementation and deployment hurdles due to the >>> complexity and cost associated with hardware support for the >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded >>> in the mandatory part (like IPv4), then a hardware implementation >>> would be free to skip over the extensions (in cases where the >>> deployment justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical >>>>>>> service header that is independent of the transport >>>>>>> methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable >>> length header that is also HW friendly. The service header can >>> be represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for >>> example subscriber ID could be of interest in the mobile core >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the >>>>>> service function chain is built in an abstract manner >>>>>> (i.e., SF-A then SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions >>>>>> that reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as >>>>>> a transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical >>>>>> service header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information >>>>>> carried in the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain >>>>>> ID and ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 >>>>>> (SFC Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique >>>>>> Layer 2 or 3 Label (e.g. VLAN, MPLS label) to the packets >>>>>> in the flow. Those Layer 2 or 3 Label makes it easier for >>>>>> subsequent nodes along the flow path to steer the flow to >>>>>> the service functions specified by the flow's service >>>>>> chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a >>>>>> very specific model of the scope of the transport header >>>>>> (that it is derived from, and relates only to, the first >>>>>> service function to which the packet will be directed. That >>>>>> is clearly an operational model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational >>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>> chain. Or the use of an MPLS label, or an MPLS label >>>>>> stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ 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 >>>> >>>> _______________________________________________ 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 jmoisand@juniper.net Thu Feb 13 08:13:49 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9235D1A0338 for ; Thu, 13 Feb 2014 08:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1vyT4slK2ox for ; Thu, 13 Feb 2014 08:13:38 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 218451A0327 for ; Thu, 13 Feb 2014 08:13:31 -0800 (PST) Received: from mail116-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 16:13:29 +0000 Received: from mail116-co1 (localhost [127.0.0.1]) by mail116-co1-R.bigfish.com (Postfix) with ESMTP id C5088DA0119; Thu, 13 Feb 2014 16:13:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(zzbb2dI98dI9371Ic89bh542I1432I15caKJdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz31iz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail116-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(13464003)(55784002)(199002)(189002)(51704005)(377454003)(479174003)(85306002)(65816001)(561944002)(19580395003)(19580405001)(79102001)(54316002)(56776001)(77982001)(93516002)(80976001)(59766001)(80022001)(54356001)(53806001)(66066001)(51856001)(76482001)(63696002)(46102001)(94316002)(47446002)(86362001)(74662001)(31966008)(74502001)(33646001)(94946001)(47736001)(15975445006)(83322001)(50986001)(47976001)(81816001)(81686001)(93136001)(49866001)(85852003)(69226001)(4396001)(74366001)(90146001)(74316001)(74876001)(2656002)(87266001)(81342001)(87936001)(81542001)(74706001)(56816005)(92566001)(95416001)(95666001)(83072002)(15202345003)(76796001)(76576001)(76786001)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB714; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:E66DC9DA.A7FA9383.F9C1B173.82A5DB49.208A0; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail116-co1 (localhost.localdomain [127.0.0.1]) by mail116-co1 (MessageSwitch) id 1392308006731070_13427; Thu, 13 Feb 2014 16:13:26 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.227]) by mail116-co1.bigfish.com (Postfix) with ESMTP id AD7579000E1; Thu, 13 Feb 2014 16:13:26 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 16:13:26 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 16:13:24 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 16:13:21 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 16:13:21 +0000 From: Jerome Moisand To: Dave Dolson , "'jmh@joelhalpern.com'" , "'Ron_Parker@affirmednetworks.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Wx4fmGuSHEU24oNCjTCFRY5qy5XDvgAA7rACAAAvKAIAAHk+AgAACZACAAAOWAIAACMoAgAAAupA= Date: Thu, 13 Feb 2014 16:13:20 +0000 Message-ID: <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> References: <52FCE54A.5090403@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:13:49 -0000 Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames=20 > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar =20 >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar=20 >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC=20 >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow.=20 >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From agoldner@allot.com Thu Feb 13 08:15:59 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592FB1A034D for ; Thu, 13 Feb 2014 08:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 rbJ0RtIzCXOL for ; Thu, 13 Feb 2014 08:15:47 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F01A0301 for ; Thu, 13 Feb 2014 08:15:24 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 13 Feb 2014 18:15:22 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 18:15:22 +0200 From: Alla Goldner To: Jerome Moisand , Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf1aUaggCMCUS7T9nUlmVBtJqmCQKAgAH2hQCAAmPrAIADhxoAgAROqDCAAI+EoIAAe7mAgAAtNNA= Date: Thu, 13 Feb 2014 16:15:21 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:16:00 -0000 Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interfa= ce is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optiona= l in exactly the same way. The whole 3GPP PCC architecture is optional. T= herefore, the claim about 100% of mobile data subscribers may not be full= y correct. And with regards to the features required for service classifi= cation and service enforcement that you describe below - they are presen= t at both GGSN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier O= F COURSE should be considered, same as use cases where TDF is considered = as a classifier. And, once describing those use cases, the existing 3GPP = architecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-= case-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Alla & folks, Well... I don't know... Getting deep in network architectures and the rol= e of the various network elements is indeed crucial. Both 3GPP and BBF (B= roadband Forum) did a lot of work in the past decade to define architectu= re & nodal requirements, which shaped in turn the deployment of all major= =20Service Providers worldwide. So quite clearly, service chaining have t= o build on that and find a good way to insert itself into such architectu= res while extending them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for= =20service classification/enforcement, as it... already does it for its o= wn purpose! This is BY NATURE a highly scalable subscriber & service mana= gement system, classifying and enforcing policies (usually L3, occasional= ly higher), and fully integrated with the HSS/PCRF chain which holds the = subscriber/service authentication & authorization data. As such, service = classification *and* service enforcement (and service accounting) is alre= ady there. For 100% of the mobile (data) subscribers. Sure enough, a TDF = system may also do its own form of service classification (and processing= =20too), but let's not forget this is an OPTIONAL system on the data path= =20on the recently defined 3GPP architectures you referred to. For many u= se cases, there is just no point going through a DPI function. While for = other use cases, there is clearly such a point, but only when it brings c= lear value for a given service construct, only applicable to correspondin= g subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary = subscriber management system on the data path, fully integrated with a AA= A system, and already doing service classification *and* service processi= ng at scale for 100% of the subscribers. Any classification/enforcement s= ystem behind it is optional and only applicable to a subset of services &= =20subscribers. Bottomline: sure, use cases with TDF should be described, but PGW-centric= =20use cases remain the rule, not the exception. And double-clicking on e= xisting standardized network architectures (e.g. 3GPP and BBF) and relate= d deployments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone D= E; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@= tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Functi= on) for providing ADC (Application Detection and Control) Rules for appli= cation detection, enforcement and also charging starting from R12. Please= =20see architecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with = the GGSN (via Diameter), not the service functions, do you mean "for the = GGSN (or the flow classifier) to carry the data passed down from PCRF to = packets' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service trea= tment, i.e. desired sequence of service functions, to specific flows base= d on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions." is not correct as we= ll as PGW/PCEF is not the only element which enforces different support p= er different flows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architect= ure and make assumptions and conclusions about potential 3GPP elements fu= nctionality which are not in scope of IETF. If we want to define use case= s for 3GPP networks, then we should show correct picture of 3GPP archite= cture without redesigning it and leave 3GPP Network Elements functionalit= y potential extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +9= 72 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com w= ww.allot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson= ; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and = service related metadata delivered from mobile control plane function lik= e PCRF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the = service functions, do you mean "for the GGSN (or the flow classifier) to = carry the data passed down from PCRF to packets' metadata field to servic= e functions on the chain"? Since the policies passed down by PCRF usually can't be understood by ser= vice functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related i= nformation, that are either embedded in packets as metadata or passed dow= n from control plane, to process the flows according to service related = policies" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" = used in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN ha= s a VLAN-ID?=20 I understand that some common classification scheme could be encoding a c= ertain QoS to a specific flow, applying some security functions to some f= lows, etc. The classification node can use simple VLAN-ID to mark differe= nt classification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC = BOF is very good.=20 Walter's wireless example is described in the Section 3.2 of https://data= tracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the sugge= sted text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treat= ment, i.e. desired sequence of service functions, to specific flows based= =20on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions.=20 =20 =20 | Mobile backhaul Network =20 =20 +-----+ | +---+---+ =20 =20 |PCRF | | |Network| =20 =20 | | < ---- > |Ctrller| =20 =20 +-----+ | +----+--+=20 =20 | | =20 =20 | | =20 =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> =20 | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> =20 | [PCEF]| | |Optimizer| | |=20 =20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> =20 | | | | | | |=20 =20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Hi Linda, First, thanks for the feedback. While it may look like a lot of component= s, we still have simplified 3GPP quite a lot. For example, in the first d= raft we left out the TDF that appears in recent standards. We=B9ll be add= ing that in response to other comments. I believe the overview section is= =20still quite short, but we will try to shorten it a bit further if it i= s too long. If you feel anything in particular is missing or extraneous, = please let us know. Yes, it is probably overkill to have two example APNs. The User & Pass ar= e important for example in cases of hot-lining where the user must first = be authenticated (for various reasons) before data services are provided/= continued. It is just another example of the important relationship betwe= en Classification (in an SFC sense) and Policy and Charging (in a 3GPP se= nse). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave = Dolson , Martin Stiemerling , "= draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph = >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not = >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile= >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statement= s > of the working group. > > Service function chains typically reside in a LAN segment which link= s > the mobile access network to the actual application platforms locate= d > in the carrier's datacenters or somewhere else in the Internet. > Service function chains ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy o= r > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From jmoisand@juniper.net Thu Feb 13 08:29:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541B1A02DF for ; Thu, 13 Feb 2014 08:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BTQtWtV3s8c for ; Thu, 13 Feb 2014 08:29:47 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id A4C7E1A02B0 for ; Thu, 13 Feb 2014 08:29:47 -0800 (PST) Received: from mail81-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 16:29:46 +0000 Received: from mail81-co1 (localhost [127.0.0.1]) by mail81-co1-R.bigfish.com (Postfix) with ESMTP id 5F20914026A; Thu, 13 Feb 2014 16:29:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(z579ehf7Iz9371Ic89bh2174M936eI146fId772h1102I542I1432I12d5I4015I1447I14ffI9a6kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdch70kz1de098h1033IL17326ah8275bh8275dh1de097h186068h18602ehz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail81-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(48214007)(51704005)(24730?= =?iso-8859-1?Q?01)(85644002)(52314003)(164054003)(199002)(189002)(5191400?= =?iso-8859-1?Q?3)(377454003)(43544003)(377424004)(13464003)(53754006)(765?= =?iso-8859-1?Q?76001)(15974865002)(83072002)(85852003)(551544002)(1597544?= =?iso-8859-1?Q?5006)(76786001)(76796001)(94946001)(65816001)(63696002)(86?= =?iso-8859-1?Q?362001)(94316002)(54316002)(56776001)(95416001)(81816001)(?= =?iso-8859-1?Q?93516002)(2656002)(85306002)(15202345003)(87936001)(956660?= =?iso-8859-1?Q?01)(93136001)(80022001)(81686001)(2201001)(92566001)(90146?= =?iso-8859-1?Q?001)(56816005)(87266001)(83322001)(80976001)(19580395003)(?= =?iso-8859-1?Q?33646001)(19580405001)(69226001)(66066001)(47736001)(50986?= =?iso-8859-1?Q?001)(49866001)(81542001)(47976001)(74316001)(46102001)(743?= =?iso-8859-1?Q?66001)(79102001)(74876001)(74706001)(53806001)(4396001)(81?= =?iso-8859-1?Q?342001)(51856001)(77982001)(59766001)(76482001)(54356001)(?= =?iso-8859-1?Q?31966008)(74502001)(74662001)(47446002)(1121002)(24704002)?= =?iso-8859-1?Q?(921002)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR05MB71?= =?iso-8859-1?Q?5;H:CO2PR05MB716.namprd05.prod.outlook.com;CLIP:66.129.241?= =?iso-8859-1?Q?.10;FPR:E7DFFDE5.ABBAE391.8DD0FC47.92254848.209EB;InfoNoRe?= =?iso-8859-1?Q?cordsA:1;MX:1;LANG:en;?= Received: from mail81-co1 (localhost.localdomain [127.0.0.1]) by mail81-co1 (MessageSwitch) id 1392308983762088_3097; Thu, 13 Feb 2014 16:29:43 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.254]) by mail81-co1.bigfish.com (Postfix) with ESMTP id AA6C2640047; Thu, 13 Feb 2014 16:29:43 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 16:29:43 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 16:29:39 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 16:29:37 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 16:29:37 +0000 From: Jerome Moisand To: Alla Goldner , Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDdosdAlrriM0Oe9XZXROZkwZqmCQKAgAH2hQCAAmPrAIADhxoAgAROqDCAAJNYAIAAk1HggAATt4CAAABcIA== Date: Thu, 13 Feb 2014 16:29:37 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:29:53 -0000 I don't know if the whole PCC architecture is truly optional in 3GPP theory= (I've never seen it expressed that way, but I'll take your word for it), b= ut one would be hard-pressed to find a 3G/LTE mobile broadband network with= out it. So in practice my 100% statement remains true (I'll give you 99.9% = if you wish!).=20 So I have a bit of an issue putting PGW and TDF at the same level. This sim= ply doesn't reflect any reality, nor the spirit of the 3GPP specs. And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory (= I took a very active role in several of those specs, e.g. TR-101). While a = DPI function is truly optional (and not that many subscribers in absolute %= go through it in practice) and not standardized. Anyway, I agree with you that mobile use cases with or without TDF should b= e considered. A case without PGW would seem much more dubious to me. We may= be saying more or the same thing, overall. -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com]=20 Sent: Thursday, February 13, 2014 11:15 AM To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interface= is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optional in= exactly the same way. The whole 3GPP PCC architecture is optional. Therefo= re, the claim about 100% of mobile data subscribers may not be fully correc= t. And with regards to the features required for service classification and= service enforcement that you describe below - they are present at both GG= SN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier OF = COURSE should be considered, same as use cases where TDF is considered as a= classifier. And, once describing those use cases, the existing 3GPP archit= ecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Alla & folks, Well... I don't know... Getting deep in network architectures and the role = of the various network elements is indeed crucial. Both 3GPP and BBF (Broad= band Forum) did a lot of work in the past decade to define architecture & n= odal requirements, which shaped in turn the deployment of all major Service= Providers worldwide. So quite clearly, service chaining have to build on t= hat and find a good way to insert itself into such architectures while exte= nding them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for s= ervice classification/enforcement, as it... already does it for its own pur= pose! This is BY NATURE a highly scalable subscriber & service management s= ystem, classifying and enforcing policies (usually L3, occasionally higher)= , and fully integrated with the HSS/PCRF chain which holds the subscriber/s= ervice authentication & authorization data. As such, service classification= *and* service enforcement (and service accounting) is already there. For 1= 00% of the mobile (data) subscribers. Sure enough, a TDF system may also do= its own form of service classification (and processing too), but let's not= forget this is an OPTIONAL system on the data path on the recently defined= 3GPP architectures you referred to. For many use cases, there is just no p= oint going through a DPI function. While for other use cases, there is clea= rly such a point, but only when it brings clear value for a given service c= onstruct, only applicable to corresponding subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary su= bscriber management system on the data path, fully integrated with a AAA sy= stem, and already doing service classification *and* service processing at = scale for 100% of the subscribers. Any classification/enforcement system be= hind it is optional and only applicable to a subset of services & subscribe= rs. Bottomline: sure, use cases with TDF should be described, but PGW-centric u= se cases remain the rule, not the exception. And double-clicking on existin= g standardized network architectures (e.g. 3GPP and BBF) and related deploy= ments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE;= Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tool= s.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Function= ) for providing ADC (Application Detection and Control) Rules for applicati= on detection, enforcement and also charging starting from R12. Please see a= rchitecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with th= e GGSN (via Diameter), not the service functions, do you mean "for the GGSN= (or the flow classifier) to carry the data passed down from PCRF to packet= s' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service treatm= ent, i.e. desired sequence of service functions, to specific flows based on= the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions." is not correct as well as PGW/PC= EF is not the only element which enforces different support per different f= lows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architectur= e and make assumptions and conclusions about potential 3GPP elements functi= onality which are not in scope of IETF. If we want to define use cases for = 3GPP networks, then we should show correct picture of 3GPP architecture wi= thout redesigning it and leave 3GPP Network Elements functionality potentia= l extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; = Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sf= c@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID?=20 I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good.=20 Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions.=20 =20 | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF | | |Network| =20 | | < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 | | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph=20 >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not=20 >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### From Ron_Parker@affirmednetworks.com Thu Feb 13 08:36:14 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEC71A0361 for ; Thu, 13 Feb 2014 08:36:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MOmHZiBXHuo for ; Thu, 13 Feb 2014 08:36:09 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6116D1A0333 for ; Thu, 13 Feb 2014 08:36:09 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 08:36:08 -0800 From: Ron Parker To: Jerome Moisand , Dave Dolson , "'jmh@joelhalpern.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgACBCLA= Date: Thu, 13 Feb 2014 16:36:07 +0000 Message-ID: References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:36:14 -0000 The point I was trying to make that even fixed size headers will create the= need for fragmentation. Furthermore, the full increase in packet/frame = size must account for both the SFC-transport header and the SFC-service hea= der. A good network design will avoid the need for fragmentation (which = is admittedly easier to account for with fixed sized headers). But when i= t is not possible to set MTU/MFS large enough on all links, then the networ= k should still function properly, although with the obvious inefficiencies = that are introduced. This is the IPv4 and IPv6 approach, in, general (esp= ecially IPv6) -- try to avoid fragmentation but deal with it when necessary= . Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From Ron_Parker@affirmednetworks.com Thu Feb 13 08:39:18 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609231A0375 for ; Thu, 13 Feb 2014 08:39:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ts1mHvVE6AE for ; Thu, 13 Feb 2014 08:39:14 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id C38441A0360 for ; Thu, 13 Feb 2014 08:39:01 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 08:39:00 -0800 From: Ron Parker To: Ron Parker , Jerome Moisand , Dave Dolson , "'jmh@joelhalpern.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgACBCLCAAQBTsA== Date: Thu, 13 Feb 2014 16:38:59 +0000 Message-ID: References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Feb 2014 08:41:55 -0800 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:39:18 -0000 Also, I don't think PMTU discovery is applicable here. We are encapsulati= ng original packets/frames. What would we do if PMTU discovery told us th= at there is not sufficient headroom to add our encapsulations? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, February 13, 2014 11:36 AM To: Jerome Moisand; Dave Dolson; 'jmh@joelhalpern.com'; 'mohamed.boucadair@= orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework The point I was trying to make that even fixed size headers will create the= need for fragmentation. Furthermore, the full increase in packet/frame = size must account for both the SFC-transport header and the SFC-service hea= der. A good network design will avoid the need for fragmentation (which = is admittedly easier to account for with fixed sized headers). But when i= t is not possible to set MTU/MFS large enough on all links, then the networ= k should still function properly, although with the obvious inefficiencies = that are introduced. This is the IPv4 and IPv6 approach, in, general (esp= ecially IPv6) -- try to avoid fragmentation but deal with it when necessary= . Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 mikebianc@aol.com Thu Feb 13 08:40:15 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC181A0333 for ; Thu, 13 Feb 2014 08:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, 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 BcPKP7CRU4eH for ; Thu, 13 Feb 2014 08:40:04 -0800 (PST) Received: from omr-d07.mx.aol.com (omr-d07.mx.aol.com [205.188.109.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED841A035F for ; Thu, 13 Feb 2014 08:40:04 -0800 (PST) Received: from mtaout-mbe02.mx.aol.com (mtaout-mbe02.mx.aol.com [172.26.254.174]) by omr-d07.mx.aol.com (Outbound Mail Relay) with ESMTP id 3CD1E701E5BC2; Thu, 13 Feb 2014 11:40:03 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbe02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id F3FCF380000B2; Thu, 13 Feb 2014 11:40:02 -0500 (EST) Date: Thu, 13 Feb 2014 11:40:02 -0500 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, jmoisand@juniper.net, ddolson@sandvine.com, jmh@joelhalpern.com, mohamed.boucadair@orange.com, Nicolas.BOUTHORS@qosmos.com, paulq@cisco.com Message-ID: <727102446.37309.1392309602893.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37308_1856842950.1392309602891" X-Originating-IP: 10.172.1.75, 64.12.173.49 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1392309603; bh=DbMwvdTVjgfWiDr42Ersu7jRqvMTDxUyJGvAVTgLGjI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=u39zerOusCsXzkUrcNUJKh47hUt8MAZU8xlzuHRI6LjV2fpX0cr7QIp+GLGG5V7g8 X65/pyUig/Q+DPxWlGaBsNVUVTRSUqn32DPOPTOxzKEDUFHMcGNtwSVwT0vWQN78aj mVCDrnl1Vs23y2twCLMVCd9hsZG68nSdBWpyOPlA= x-aol-sid: 3039ac1afeae52fcf562685c X-AOL-IP: 64.12.250.54 X-Mailman-Approved-At: Thu, 13 Feb 2014 08:41:55 -0800 Cc: S.Majee@F5.com, sfc@ietf.org, linda.dunbar@huawei.com Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:40:15 -0000 ------=_Part_37308_1856842950.1392309602891 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable should the draft indicate how a router should respond when the DNF bit is s= et? =C2=A0To what should the MTU be set in the reply? From: Ron_Parker@affirmednetworks.com To: Jerome Moisand,Dave Dolson,= 'jmh@joelhalpern.com','mohamed.boucadair@orange.com','Nicolas.BOUTHORS@qosmos.com','paulq@cisco.com' cc: 'S.Majee@F5.com','sfc@ietf.org','linda.du= nbar@huawei.com' Sent: Thursday, February 13, 2014 Subject: Re: [sfc] Framework The point I was trying to make that even fixed size headers will create the= need for fragmentation. =C2=A0=C2=A0 Furthermore, the full increase in pac= ket/frame size must account for both the SFC-transport header and the SFC-s= ervice header. =C2=A0=C2=A0 A good network design will avoid the need for f= ragmentation (which is admittedly easier to account for with fixed sized he= aders). =C2=A0 But when it is not possible to set MTU/MFS large enough on a= ll links, then the network should still function properly, although with th= e obvious inefficiencies that are introduced. =C2=A0 This is the IPv4 and I= Pv6 approach, in, general (especially IPv6) -- try to avoid fragmentation b= ut deal with it when necessary. =C2=A0 Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February= 13, 2014 11:13 AMTo: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'moha= med.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com'= Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'Subject: RE:= [sfc] FrameworkYes, fragmentation and variable headers are usually a reall= y bad thing for forwarding performance. Let's not forget that we live in a = 100G-ish kind of world nowadays.Now the question should be: WHY would we wa= nt to do that (variable headers leading to fragmentation issues)?For exampl= e, the type of metadata that may require variable-length fields might be a = better candidate for some out-of-band signaling mechanism. If this is servi= ce authorization data (e.g. a service profile/policy), this sounds likely. = Not 100% sure this is true for all use cases though. Only a good understand= ing of use cases, grounded by reflecting on existing network architectures = (notably broadband, fixed or mobile), would tell us if one approach or anot= her is the most appropriate.Anyhoo, we're jumping way deep in the detailed = protocol design here. This seems a tad premature.-----Original Message-----= From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave DolsonSent: Thurs= day, February 13, 2014 11:03 AMTo: 'jmh@joelhalpern.com'; 'Ron_Parker@affir= mednetworks.com'; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.= com'; 'paulq@cisco.com'Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@= huawei.com'Subject: Re: [sfc] Frameworkit is overall more efficient to supp= ort PMTU discovery rather than fragmenting every large packet. The is why T= CP adopted it so early on. The fragmenting also puts huge performance burde= n on the service functions.Fragmenting may also affect the ability of load = balancers to get each fragment to the correct destination. So PMTU discove= ry SHOULD be used, in my opinion. By this I mean the client or server is in= formed that its packets are too big (for IPv6 or IPv4 with DF=3D1). Some op= erators may wish to incur the extra cost to hide the existence of the tunne= ling, when the elements of the chain can support it, so we could consider t= hat as an optional mechanism. -Dave----- Original Message -----From: Joel M= . Halpern [mailto:jmh@joelhalpern.com]Sent: Thursday, February 13, 2014 10:= 31 AMTo: Ron Parker ; mohamed.boucadair@or= ange.com ; Dave Dolson; 'Nicolas.BOUTHORS@qos= mos.com' ; 'paulq@cisco.com' = Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] FrameworkI= mostly agree with you Ron. I can probably come up with some other variati= ons, but your second point is that the transport must deal with the issue o= f frame size / fit.I would note that if we assume that the carrying encaps = (IPv4/v6 outer) is being fragmented, then we are assuming that the exit fro= m service chaining can and will reassemble.Yours,JoelOn 2/13/14, 10:18 AM, = Ron Parker wrote:> Joel,>> That is an excellent point to consider when choo= sing transport> encapsulations. =C2=A0 If the transport encapsulation is IP= v4 or IPv6> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then> frag= mentation and defragmentation are naturally supported. =C2=A0=C2=A0 If the>= transport encapsulation is VLAN, MPLS, etc., then I believe one of the > f= ollowing must be true:>> * The end-to-end path is known to support the resu= lting larger frames> * A path discovery mechanism is mandated by SFC when n= on-IP transports > are used * An SFC-specific fragmentation header and mech= anisms must be > defined (i.e.,> SFC-transport/SFC-fragmentation/SFC-servic= e/original-packet-or-frame)>> Ron>>> -----Original Message----- From: Joel= M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 201= 4 10:10 > AM To: mohamed.boucadair@orange.com; Dave Dolson; > 'Nicolas.BOUT= HORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc:> 'S.Majee@F5.com'; 'sfc= @ietf.org'; 'linda.dunbar@huawei.com' Subject:> Re: [sfc] Framework>> There= is a related complexity. I hope that we expect to support IPv6. > IPv6 exp= licitly prohibits network elements from fragmenting end user > packets.>> Y= ours, Joel>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote:>> Re-= ,>>>> FWIW, one of the existing architecture drafts includes the following = >> behavior>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#= section-6):>>>>>>">> 6. Fragmentation Considerations>>>> If adding the Serv= ice Chaining Header would result in a fragmented >> packet, the classifier = should include a Service Chaining Header in >> each fragment. Doing so wou= ld prevent SF Nodes to dedicate resource >> to handle fragments. ">>>> Chee= rs, Med>>>>>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@iet= f.org] >>> De la part de Dave Dolson Envoy=C3=A9 :>>> jeudi 13 f=C3=A9vrier= 2014 13:39 =C3=80 : 'Nicolas.BOUTHORS@qosmos.com'; >>> 'Ron_Parker@affirme= dnetworks.com'; 'jmh@joelhalpern.com'; >>> 'paulq@cisco.com' Cc : 'S.Majee@= F5.com'; 'sfc@ietf.org'; >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Fr= amework>>>>>> Good point to consider fragmentation.>>>>>> We should design = the encapsulation such that the forwarding >>> functions do not need to rea= ssemble. Each fragment should be >>> independently forwardable; some SFs ma= y choose to ignore these >>> packets.>>>>>> Any layer 2.5 protocol like VLA= N or MPLS would support this.>>> Otherwise, a reassembly layer could be add= ed after the forwarding >>> coordinates. Think of something like the IPv6 r= eassembly option >>> after a GRE header, for instance.>>>>>> IP | GRE | rea= ssem | frag data>>>>>> We could alternatively mandate the inner IP be fragm= ented and that >>> path-MTU discovery be supported.>>>>>>>>>>>>>>> ----- Or= iginal Message ----- From: Nicolas BOUTHORS >>> [mailto:Nicolas.BOUTHORS@qo= smos.com] Sent: Thursday, February 13,>>> 2014 04:13 AM To: Ron Parker ;>>> Dave Dolson; Joel M. Halpern ; Paul Quinn>>> (paulq) Cc: Sumandra Majee ; >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework>>>>>> If we do not enforce a fix = header size we have other implication.>>>>>> There is the question of segme= ntation and reassembly responsibility >>> as well.>>>>>> If adding length t= o the service header forces segmentation, then >>> whose responsibility is = it to reassemble the payload before passing >>> it to the SF.>>>>>> Similar= question for packet re-ordering.>>>>>>>>> ________________________________= ________ From: Ron Parker >>> [Ron_Parker@affirmednetworks.com] Sent: Wedne= sday, February 12,>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul = Quinn>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject:>>>= Re: [sfc] Framework>>>>>> Dave,>>>>>> Yes, that is a good point if we logi= cally separate the forwarding>>> function from the SFC-aware service functi= on, as we should. =C2=A0 The>>> forwarding function is concerned with only = the inbound transport >>> header, the fixed portion of the service header = containing the>>> chain information, and the outbound transport header. =C2= =A0=C2=A0 The>>> service function may look at the entirety of the service h= eader and >>> would look at the encapsulated packet.>>>>>> Ron>>>>>>>>> ---= --Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com]= Sent: Wednesday, February 12, 2014>>> 5:18 PM To: Joel M. Halpern; Ron Par= ker; Paul Quinn (paulq) Cc:>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar S= ubject: RE: [sfc] >>> Framework>>>>>> The forwarding plane might not even n= eed to look at the encapsulated >>> packet.>>>>>> For example, (if the SF I= dentifier is a VLAN tag), an Ethernet >>> switch can forward packets of the= form: Ether | VLAN | BLOB.>>>>>>>>>>>> -----Original Message----- From: s= fc [mailto:sfc-bounces@ietf.org] >>> On Behalf Of Joel M. Halpern Sent:>>> = Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>> Paul = Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar>>> Subject: Re= : [sfc] Framework>>>>>> I agree as well. Yours, Joel>>>>>> On 2/12/14, 4:24= PM, Ron Parker wrote:>>>> Hi, Dave.>>>>>>>> I Agree with your statement. = =C2=A0=C2=A0 And if the total length of the>>>> header is>>> contained in t= he mandatory portion, the hardware implementation can >>> easily locate the= encapsulated packet.>>>>>>>> Ron>>>>>>>>>>>> -----Original Message----- Fr= om: Dave Dolson >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, Februar= y 12,>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M.>>>> H= alpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject:>>>> RE: [sfc] F= ramework>>>>>>>> I think a good approach would be:>>>>>>>> The information = required for forwarding (the SF Identifier) should >>>> be in>>> a mandator= y fixed-size header.>>>>>>>> Optional information (if any) is NOT to be use= d for forwarding, but >>>> is>>> for consumption by one or more of the appl= ications in the chain.>>>>>>>> Then the forwarding plane, and even the PDP,= can be agnostic about >>>> the>>> meta-data.>>>>>>>> -Dave>>>>>>>>>>>> ---= --Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>> On Beh= alf Of Ron Parker Sent:>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Q= uinn (paulq) Cc:>>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda D= unbar>>>> Subject: Re: [sfc] Framework>>>>>>>> Paul,>>>>>>>> That is why I = am proposing a hybrid where extensions or options can >>>> be>>> added but = the total length is contained in the fixed portion. =C2=A0 I>>> can envisio= n certain deployments (e.g., Enterprise) where perhaps >>> extensions are n= ot needed and the SFC functionality is realized>>> in hardware. =C2=A0 And,= I can envision certain other deployments>>> (e.g., 3gpp) where the extensi= on headers add sufficient value to >>> justify software based implementatio= ns.>>>>>>>> Ron>>>>>>>>>>>> -----Original Message----- From: Paul Quinn (pa= ulq) >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014>>>> 3= :40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. >>>> Halper= n; sfc@ietf.org Subject: Re: [sfc] Framework>>>>>>>> Hi,>>>>>>>> We certain= ly need to be very careful with variable length headers >>>> when>>> hardwa= re platform are in play.>>>>>>>> Ron, your examples of IP options and v6 EH= have both suffered from>>> significant implementation and deployment hurdl= es due to the >>> complexity and cost associated with hardware support for = the >>> option/EH.>>>>>>>> Paul>>>>>>>> On Feb 12, 2014, at 3:10 PM, Ron Pa= rker >>>> >>> wrote:>>>>>>>>> Hi, Sumandra= .>>>>>>>>>> Regarding service header flexibility, I completely agree. =C2= =A0 I>>>>> might>>> suggest a compromise between hardware friendliness and = software>>> flexibility. =C2=A0=C2=A0 If the header had the ability to add = extensions>>> (perhaps similar to IPv6) but also had the header length enco= ded in >>> the mandatory part (like IPv4), then a hardware implementation w= ould >>> be free to skip over the extensions (in cases where the deployment= >>> justifies ignoring the extensions).>>>>>>>>>> Ron>>>>>>>>>>>>>>> -----= Original Message----- From: Sumandra Majee >>>>> [mailto:S.Majee@F5.com] Se= nt: Wednesday, February 12, 2014>>>>> 3:04 PM To: Ron Parker; Linda Dunbar;= Joel M. Halpern; >>>>> sfc@ietf.org Subject: Re: [sfc] Framework>>>>>>>>>>= >> For all of those reasons, I strongly support a canonical service >>>>>>>= header that is independent of the transport methodology.>>>>>>>>>>>>>>> I = agree. However the format of service header should be >>>>> standardized in= >>> a way that is flexible. Some of us would like to see variable length >>= > header that is also HW friendly. The service header can be >>> represente= d as a mandotory fixed length header (like IP>>> header) along with an opti= onal variable length attribute field.>>> Different services can be interest= ed in different metadata, for >>> example subscriber ID could be of interes= t in the mobile core >>> service chain only.>>>>>>>>>> Sumandra>>>>>>>>>> O= n 2/12/14, 11:32 AM, "Ron Parker">>>>> >>>= wrote:>>>>>>>>>>> Linda,>>>>>>>>>>>> My interpretation of the architecture= docs is that the service >>>>>> function chain is built in an abstract man= ner (i.e., SF-A then >>>>>> SF-B>>> then SF-C).>>>>>> Separately, a locator= table provides network location for>>>>>> each of those service functions.= =C2=A0 In this way, you can>>>>>> locate the service functions>>> in>>>>>>= a manner appropriate to the type of transport you are>>>>>> using. =C2=A0 = If you want that to be interface+VLAN,>>>>>> gateway-IP+MPLS label stack, I= P>>> address,>>>>>> GRE tunnel remote IP + key, etc., you can do that. =C2= =A0=C2=A0 You>>>>>> can even potentially locate different service functions= that >>>>>> reside in the same chain with different flavors of>>>>>> netwo= rk locators. =C2=A0=C2=A0 Another justification to separate the>>>>>> ident= ity of a service function from its network location is>>>>>> load balancing= . =C2=A0 If, for example, SF-A had 3 IP addresses,>>>>>> that would imply l= oad balancing to 3 instances using IP as a >>>>>> transport layer.>>>>>>>>>= >>> For all of those reasons, I strongly support a canonical service >>>>>>= header that is independent of the transport>>>>>> methodology. =C2=A0=C2= =A0 At a particular node, the decision as to>>>>>> where to go next should = be based solely on information carried in >>>>>> the canonical service head= er and not on the>>> fields>>>>>> in the transport header. =C2=A0 That is, = the SFC node discards>>>>>> the transport header and extracts the chain ID = from the>>>>>> service header. =C2=A0=C2=A0 Through mechanisms we have not = yet begun>>>>>> to discuss, the SFC node knows how to interpret the chain I= D and >>>>>> ultimately how to progress the packet.>>>>>>>>>>>> Ron>>>>>>>>= >>>>>>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@= ietf.org] On Behalf Of Linda Dunbar>>>>>> Sent: Wednesday, February 12, 201= 4 12:01 PM To: Joel M.>>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Frame= work>>>>>>>>>>>> Agree with Joel's statement.>>>>>>>>>>>> I think a simple = sentence below should be added Section 5.2 (SFC>>>>>> Classifier) to emphas= ize this point.>>>>>>>>>>>> "A Service Chain Classifier node can associate = a unique Layer 2 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets i= n the flow.>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent n= odes >>>>>> along the flow path to steer the flow to the service functions = >>>>>> specified by the flow's service chain.">>>>>>>>>>>>>>>>>> Linda ----= -Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Be= half Of Joel M. Halpern>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM T= o:>>>>>> sfc@ietf.org Subject: [sfc] Framework>>>>>>>>>>>> I was looking at= the framework proposal. The proposal has a very >>>>>> specific model of t= he scope of the transport header (that it is >>>>>> derived from, and relat= es only to, the first service function to >>>>>> which the packet will be d= irected. That is clearly an operational >>>>>> model we need to support.>>>= >>>>>>>>> However, I would like to allow other transport operational >>>>>>= models, such as the use of a VLAN to direct traffic along a >>>>>> chain. = Or the use of an MPLS label, or an MPLS label stack.>>>>>>>>>>>> Yours, Jo= el M. Halpern>>>>>>>>>>>> _______________________________________________ s= fc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/s= fc>>>>>>>>>>>> _______________________________________________ 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>>>>>>>>>> ________________________________________= _______ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/list= info/sfc>>>>>>>>>>>> _______________________________________________ sfc ma= iling list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc>>>>>>= _______________________________________________ sfc mailing list >>> sfc@i= etf.org https://www.ietf.org/mailman/listinfo/sfc>>>_______________________= ________________________sfc mailing listsfc@ietf.orghttps://www.ietf.org/ma= ilman/listinfo/sfc_______________________________________________sfc mailin= g listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_37308_1856842950.1392309602891 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
should the draf= t indicate how a router should respond when the DNF bit is set?  To wh= at should the MTU be set in the reply?





From: Ron_Par= ker@affirmednetworks.com<Ron_Parker@affirmednetworks.com>
To: <= /b>Jerome Moisand<jmoisand@juniper.net>,Dave Dolson<ddolson@sandvi= ne.com>,'jmh@joelhalpern.com'<jmh@joelhalpern.com>,'mohamed.boucad= air@orange.com'<mohamed.boucadair@orange.com>,'Nicolas.BOUTHORS@qosmo= s.com'<Nicolas.BOUTHORS@qosmos.com>,'paulq@cisco.com'<paulq@cisco.= com>
cc: 'S.Majee@F5.com'<S.Majee@F5.com>,'sfc@ietf.org'= <sfc@ietf.org>,'linda.dunbar@huawei.com'<linda.dunbar@huawei.com&g= t;
Sent: Thursday, February 13, 2014
Subject: Re: [sfc]= Framework

The point I was trying to make that even f= ixed size headers will create the need for fragmentation.    Furt= hermore, the full increase in packet/frame size must account for both the S= FC-transport header and the SFC-service header.    A good network= design will avoid the need for fragmentation (which is admittedly easier t= o account for with fixed sized headers).   But when it is not possible= to set MTU/MFS large enough on all links, then the network should still fu= nction properly, although with the obvious inefficiencies that are introduc= ed.   This is the IPv4 and IPv6 approach, in, general (especially IPv6= ) -- try to avoid fragmentation but deal with it when necessary.

&n= bsp; Ron


-----Original Message-----


From: = Jerome Moisand [mailto:jmoisand@juniper.net]
Sent: Thursday,= February 13, 2014 11:13 AM
To: Dave Dolson; 'jmh@joelhalpern= .com'; Ron Parker; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos= .com'; 'paulq@cisco.com'
Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'= ; 'linda.dunbar@huawei.com'
Subject: RE: [sfc] Framework

Yes, fragmentation and variable headers are usuall= y a really bad thing for forwarding performance. Let's not forget that we l= ive in a 100G-ish kind of world nowadays.

Now = the question should be: WHY would we want to do that (variable headers lead= ing to fragmentation issues)?

For example, the= type of metadata that may require variable-length fields might be a better= candidate for some out-of-band signaling mechanism. If this is service aut= horization data (e.g. a service profile/policy), this sounds likely. Not 10= 0% sure this is true for all use cases though. Only a good understanding of= use cases, grounded by reflecting on existing network architectures (notab= ly broadband, fixed or mobile), would tell us if one approach or another is= the most appropriate.

Anyhoo, we're jumping w= ay deep in the detailed protocol design here. This seems a tad premature.
-----Original Message-----
From: = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Se= nt: Thursday, February 13, 2014 11:03 AM
To: 'jmh@joelhalpern= .com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.boucadair@orange.com'; '= Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com'
Cc: 'S.Majee@= F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Subject: R= e: [sfc] Framework

it is overall more efficien= t to support PMTU discovery rather than fragmenting every large packet. The= is why TCP adopted it so early on.

The fragm= enting also puts huge performance burden on the service functions.
Fragmenting may also affect the ability of load balancers to get each= fragment to the correct destination.

So PMT= U discovery SHOULD be used, in my opinion. By this I mean the client or ser= ver is informed that its packets are too big (for IPv6 or IPv4 with DF=3D1)= .

Some operators may wish to incur the extra = cost to hide the existence of the tunneling, when the elements of the chain= can support it, so we could consider that as an optional mechanism.

-Dave


-= ---- Original Message -----
From: Joel M. Halpern [mailto:jmh= @joelhalpern.com]
Sent: Thursday, February 13, 2014 10:31 AM<= br class=3D"">To: Ron Parker <Ron_Parker@affirmednetworks.com>; moham= ed.boucadair@orange.com <mohamed.boucadair@orange.com>; Dave Dolson; = 'Nicolas.BOUTHORS@qosmos.com' <Nicolas.BOUTHORS@qosmos.com>; 'paulq@c= isco.com' <paulq@cisco.com>
Cc: 'S.Majee@F5.com' <S.= Majee@F5.com>; 'sfc@ietf.org' <sfc@ietf.org>; 'linda.dunbar@huawei= .com' <linda.dunbar@huawei.com>
Subject: Re: [sfc] Fram= ework

I mostly agree with you Ron. I can prob= ably come up with some other variations, but your second point is that the = transport must deal with the issue of frame size / fit.

I would note that if we assume that the carrying encaps (IPv4/v6 = outer) is being fragmented, then we are assuming that the exit from service= chaining can and will reassemble.

Yours,
Joel

On 2/13/14, 10:18 AM, Ron Parke= r wrote:
> Joel,
>
> Tha= t is an excellent point to consider when choosing transport
&= gt; encapsulations.   If the transport encapsulation is IPv4 or IPv6> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then=
> fragmentation and defragmentation are naturally support= ed.    If the
> transport encapsulation is VLAN,= MPLS, etc., then I believe one of the
> following must b= e true:
>
> * The end-to-end path is know= n to support the resulting larger frames
> * A path discov= ery mechanism is mandated by SFC when non-IP transports
>= are used * An SFC-specific fragmentation header and mechanisms must be > defined (i.e.,
> SFC-transport/SFC-fragme= ntation/SFC-service/original-packet-or-frame)
>
> Ron
>
>
> --= ---Original Message----- From: Joel M. Halpern
> [mailto:= jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10
> AM To: mohamed.boucadair@orange.com; Dave Dolson;
>= 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc:
> 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subj= ect:
> Re: [sfc] Framework
>
> There is a related complexity. I hope that we expect to support IPv6= .
> IPv6 explicitly prohibits network elements from fragm= enting end user
> packets.
>
> Yours, Joel
>
> On 2/13/14, 8:21 = AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> FWIW, one of the existing architectu= re drafts includes the following
>> behavior
>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02= #section-6):
>>
>>
&g= t;>
"
>> 6. Fragmentation Consideratio= ns
>>
>> If adding the Service Chai= ning Header would result in a fragmented
>> packet, th= e classifier should include a Service Chaining Header in
>= ;> each fragment. Doing so would prevent SF Nodes to dedicate resource =
>> to handle fragments. "
>>
>> Cheers, Med
>>
>>=
>>> -----Message d'origine----- De : sfc [mailto:sf= c-bounces@ietf.org]
>>> De la part de Dave Dolson E= nvoy=C3=A9 :
>>> jeudi 13 f=C3=A9vrier 2014 13:39 = =C3=80 : 'Nicolas.BOUTHORS@qosmos.com';
>>> 'Ron_Pa= rker@affirmednetworks.com'; 'jmh@joelhalpern.com';
>>&= gt; 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';
>>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework
>>>
>>> Good point to consider fragm= entation.
>>>
>>> We should d= esign the encapsulation such that the forwarding
>>>= ; functions do not need to reassemble. Each fragment should be
>>> independently forwardable; some SFs may choose to ignore th= ese
>>> packets.
>>>
>>> Any layer 2.5 protocol like VLAN or MPLS would support = this.
>>> Otherwise, a reassembly layer could be add= ed after the forwarding
>>> coordinates. Think of s= omething like the IPv6 reassembly option
>>> after = a GRE header, for instance.
>>>
>&g= t;> IP | GRE | reassem | frag data
>>>
>>> We could alternatively mandate the inner IP be fragmente= d and that
>>> path-MTU discovery be supported.
>>>
>>>
>>&g= t;
>>>
>>> ----- Original Mes= sage ----- From: Nicolas BOUTHORS
>>> [mailto:Nicol= as.BOUTHORS@qosmos.com] Sent: Thursday, February 13,
>>= > 2014 04:13 AM To: Ron Parker <Ron_Parker@affirmednetworks.com>;<= br class=3D"">>>> Dave Dolson; Joel M. Halpern <jmh@joelhalpern= .com>; Paul Quinn
>>> (paulq) <paulq@cisco.com= > Cc: Sumandra Majee <S.Majee@F5.com>;
>>>= sfc@ietf.org <sfc@ietf.org>; Linda Dunbar <linda.dunbar@huawei.co= m>
>>> Subject: Re: [sfc] Framework
>>>
>>> If we do not enforce a fix header = size we have other implication.
>>>
&g= t;>> There is the question of segmentation and reassembly responsibil= ity
>>> as well.
>>>
>>> If adding length to the service header forces segmentat= ion, then
>>> whose responsibility is it to reassem= ble the payload before passing
>>> it to the SF.>>>
>>> Similar question for pa= cket re-ordering.
>>>
>>>
>>> ________________________________________ From: Ron = Parker
>>> [Ron_Parker@affirmednetworks.com] Sent: = Wednesday, February 12,
>>> 2014 11:25 PM To: Dave D= olson; Joel M. Halpern; Paul Quinn
>>> (paulq) Cc: S= umandra Majee; sfc@ietf.org; Linda Dunbar Subject:
>>&g= t; Re: [sfc] Framework
>>>
>>>= ; Dave,
>>>
>>> Yes, that is = a good point if we logically separate the forwarding
>>= > function from the SFC-aware service function, as we should.   The=
>>> forwarding function is concerned with only the = inbound transport
>>> header, the fixed portion of= the service header containing the
>>> chain informa= tion, and the outbound transport header.    The
>= ;>> service function may look at the entirety of the service header a= nd
>>> would look at the encapsulated packet.
>>>
>>> Ron
>>= >
>>>
>>> -----Original Me= ssage----- From: Dave Dolson
>>> [mailto:ddolson@sa= ndvine.com] Sent: Wednesday, February 12, 2014
>>> 5= :18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc:
>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc= ]
>>> Framework
>>>
>>> The forwarding plane might not even need to look at the = encapsulated
>>> packet.
>>>=
>>> For example, (if the SF Identifier is a VLAN ta= g), an Ethernet
>>> switch can forward packets of t= he form: Ether | VLAN | BLOB.
>>>
>= ;>>
>>>
>>> -----Origin= al Message----- From: sfc [mailto:sfc-bounces@ietf.org]
>= >> On Behalf Of Joel M. Halpern Sent:
>>> Wedn= esday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;
>>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda D= unbar
>>> Subject: Re: [sfc] Framework
>>>
>>> I agree as well. Yours, Joel
>>>
>>> On 2/12/14, 4:24 PM, Ron P= arker wrote:
>>>> Hi, Dave.
>>= ;>>
>>>> I Agree with your statement. &nbs= p;  And if the total length of the
>>>> head= er is
>>> contained in the mandatory portion, the ha= rdware implementation can
>>> easily locate the enc= apsulated packet.
>>>>
>>>= > Ron
>>>>
>>>>
>>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday,= February 12,
>>>> 2014 4:10 PM To: Ron Parker; P= aul Quinn (paulq) Cc: Joel M.
>>>> Halpern; Suman= dra Majee; sfc@ietf.org; Linda Dunbar Subject:
>>>&g= t; RE: [sfc] Framework
>>>>
>>= ;>> I think a good approach would be:
>>>><= br class=3D"">>>>> The information required for forwarding (the= SF Identifier) should
>>>> be in
= >>> a mandatory fixed-size header.
>>>><= br class=3D"">>>>> Optional information (if any) is NOT to be u= sed for forwarding, but
>>>> is
&g= t;>> for consumption by one or more of the applications in the chain.=
>>>>
>>>> Then the for= warding plane, and even the PDP, can be agnostic about
>&= gt;>> the
>>> meta-data.
>>= ;>>
>>>> -Dave
>>>&g= t;
>>>>
>>>> -----Origi= nal Message----- From: sfc [mailto:sfc-bounces@ietf.org]
>= ;>>> On Behalf Of Ron Parker Sent:
>>>> = Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc:
>>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Du= nbar
>>>> Subject: Re: [sfc] Framework
>>>>
>>>> Paul,
&= gt;>>>
>>>> That is why I am proposing a= hybrid where extensions or options can
>>>> be<= br class=3D"">>>> added but the total length is contained in the f= ixed portion.   I
>>> can envision certain depl= oyments (e.g., Enterprise) where perhaps
>>> extens= ions are not needed and the SFC functionality is realized
>= ;>> in hardware.   And, I can envision certain other deployments=
>>> (e.g., 3gpp) where the extension headers add su= fficient value to
>>> justify software based implem= entations.
>>>>
>>>> Ro= n
>>>>
>>>>
>>>> -----Original Message----- From: Paul Quinn (paulq) >>>> [mailto:paulq@cisco.com] Sent: Wednesday, Febr= uary 12, 2014
>>>> 3:40 PM To: Ron Parker Cc: Sum= andra Majee; Linda Dunbar; Joel M.
>>>> Halpern;= sfc@ietf.org Subject: Re: [sfc] Framework
>>>>>>>> Hi,
>>>>
>>>> We certainly need to be very careful with variable l= ength headers
>>>> when
>>&g= t; hardware platform are in play.
>>>>
>>>> Ron, your examples of IP options and v6 EH have both= suffered from
>>> significant implementation and de= ployment hurdles due to the
>>> complexity and cost= associated with hardware support for the
>>> optio= n/EH.
>>>>
>>>> Paul>>>>
>>>> On Feb 12, 2014= , at 3:10 PM, Ron Parker
>>>> <Ron_Parker@aff= irmednetworks.com>
>>> wrote:
>&= gt;>>
>>>>> Hi, Sumandra.
= >>>>>
>>>>> Regarding service h= eader flexibility, I completely agree.   I
>>>&= gt;> might
>>> suggest a compromise between hardw= are friendliness and software
>>> flexibility.  = ;  If the header had the ability to add extensions
>&= gt;> (perhaps similar to IPv6) but also had the header length encoded in=
>>> the mandatory part (like IPv4), then a hardwar= e implementation would
>>> be free to skip over the= extensions (in cases where the deployment
>>> just= ifies ignoring the extensions).
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> -----Original= Message----- From: Sumandra Majee
>>>>> [mai= lto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014
>&g= t;>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;
>>>>> sfc@ietf.org Subject: Re: [sfc] Framework>>>>>
>>>>>>>= For all of those reasons, I strongly support a canonical service
>>>>>>> header that is independent of the transp= ort methodology.
>>>>>
>>&= gt;>>
>>>>> I agree. However the format = of service header should be
>>>>> standardize= d in
>>> a way that is flexible. Some of us would li= ke to see variable length
>>> header that is also H= W friendly. The service header can be
>>> represent= ed as a mandotory fixed length header (like IP
>>> h= eader) along with an optional variable length attribute field.
>>> Different services can be interested in different metadata, = for
>>> example subscriber ID could be of interest = in the mobile core
>>> service chain only.
>>>>>
>>>>> Sumandra
>>>>>
>>>>> On 2/12/1= 4, 11:32 AM, "Ron Parker"
>>>>> <Ron_Parker= @affirmednetworks.com>
>>> wrote:
&= gt;>>>>
>>>>>> Linda,
>>>>>>
>>>>>> My in= terpretation of the architecture docs is that the service
&g= t;>>>>> function chain is built in an abstract manner (i.e.,= SF-A then
>>>>>> SF-B
>&= gt;> then SF-C).
>>>>>> Separately, a lo= cator table provides network location for
>>>>>= ;> each of those service functions.   In this way, you can
>>>>>> locate the service functions
&= gt;>> in
>>>>>> a manner appropriate = to the type of transport you are
>>>>>> usi= ng.   If you want that to be interface+VLAN,
>>>= ;>>> gateway-IP+MPLS label stack, IP
>>> ad= dress,
>>>>>> GRE tunnel remote IP + key, e= tc., you can do that.    You
>>>>>&g= t; can even potentially locate different service functions that
>>>>>> reside in the same chain with different flav= ors of
>>>>>> network locators.   = ; Another justification to separate the
>>>>>&= gt; identity of a service function from its network location is
>>>>>> load balancing.   If, for example, SF-A ha= d 3 IP addresses,
>>>>>> that would imply l= oad balancing to 3 instances using IP as a
>>>>&= gt;> transport layer.
>>>>>>
>>>>>> For all of those reasons, I strongly support a = canonical service
>>>>>> header that is in= dependent of the transport
>>>>>> methodolo= gy.    At a particular node, the decision as to
>= ;>>>>> where to go next should be based solely on informatio= n carried in
>>>>>> the canonical service = header and not on the
>>> fields
>&= gt;>>>> in the transport header.   That is, the SFC node d= iscards
>>>>>> the transport header and ext= racts the chain ID from the
>>>>>> service = header.    Through mechanisms we have not yet begun
>>>>>> to discuss, the SFC node knows how to interpret t= he chain ID and
>>>>>> ultimately how to p= rogress the packet.
>>>>>>
&g= t;>>>>> Ron
>>>>>>
>>>>>>
>>>>>> -----= Original Message----- From: sfc
>>>>>> [ma= ilto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
>>= >>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M.>>>>>> Halpern; sfc@ietf.org Subject: Re: [sf= c] Framework
>>>>>>
>>&= gt;>>> Agree with Joel's statement.
>>>>= >>
>>>>>> I think a simple sentence b= elow should be added Section 5.2 (SFC
>>>>>>= ; Classifier) to emphasize this point.
>>>>>&g= t;
>>>>>> "A Service Chain Classifier node = can associate a unique Layer 2
>>>>>> or 3= Label (e.g. VLAN, MPLS label) to the packets in the flow.
&g= t;>>>>> Those Layer 2 or 3 Label makes it easier for subsequ= ent nodes
>>>>>> along the flow path to st= eer the flow to the service functions
>>>>>&g= t; specified by the flow's service chain."
>>>>&g= t;>
>>>>>>
>>>>= ;>> Linda -----Original Message----- From: sfc
>>= ;>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halper= n
>>>>>> Sent: Wednesday, February 12, 2014= 10:20 AM To:
>>>>>> sfc@ietf.org Subject: = [sfc] Framework
>>>>>>
>&g= t;>>>> I was looking at the framework proposal. The proposal ha= s a very
>>>>>> specific model of the scop= e of the transport header (that it is
>>>>>&g= t; derived from, and relates only to, the first service function to
>>>>>> which the packet will be directed. That is= clearly an operational
>>>>>> model we ne= ed to support.
>>>>>>
>>= ;>>>> However, I would like to allow other transport operationa= l
>>>>>> models, such as the use of a VLAN= to direct traffic along a
>>>>>> chain. = Or the use of an MPLS label, or an MPLS label stack.
>>= >>>>
>>>>>> Yours, Joel M. Halp= ern
>>>>>>
>>>>&g= t;> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mail= man/listinfo/sfc
>>>>>>
>&= gt;>>>> _______________________________________________ sfc mai= ling list
>>>>>> sfc@ietf.org https://www.= ietf.org/mailman/listinfo/sfc
>>>>>>
>>>>>> __________________________________________= _____ sfc mailing list
>>>>>> sfc@ietf.org= https://www.ietf.org/mailman/listinfo/sfc
>>>>&g= t;
>>>>> _____________________________________= __________ sfc mailing list
>>>>> sfc@ietf.or= g https://www.ietf.org/mailman/listinfo/sfc
>>>><= br class=3D"">>>>> ____________________________________________= ___ sfc mailing list
>>>> sfc@ietf.org https://w= ww.ietf.org/mailman/listinfo/sfc
>>>>
>>>
>>> ________________________________= _______________ sfc mailing list
>>> sfc@ietf.org h= ttps://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.o= rg
https://www.ietf.org/mailman/listinfo/sfc


________________________________= _______________
sfc mailing list
sfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc
------=_Part_37308_1856842950.1392309602891-- From Ron_Parker@affirmednetworks.com Thu Feb 13 08:42:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE1E1A037C for ; Thu, 13 Feb 2014 08:42:12 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChBwz2eIlGbq for ; Thu, 13 Feb 2014 08:42:08 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 261071A036B for ; Thu, 13 Feb 2014 08:42:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 08:42:07 -0800 From: Ron Parker To: "'sfc@ietf.org'" Thread-Topic: MTU Thread-Index: Ac8o2oHnMZCedYTGShmh9RjlKXFXbQ== Date: Thu, 13 Feb 2014 16:42:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sfc] MTU X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:42:12 -0000 Resending due to SFC email list server complaining about too many recipient= s... The point I was trying to make here is that even fixed size headers may cre= ate the need for fragmentation. Furthermore, the full increase in packet= /frame size must account for both the SFC-transport header and the SFC-serv= ice header. A good network design will avoid the need for fragmentation = (which is admittedly easier to account for with fixed sized headers). But= when it is not possible to set MTU/MFS large enough on all links, then the= network should still function properly, although with the obvious ineffici= encies that are introduced. This is the IPv4 and IPv6 approach, in, gener= al (especially IPv6) -- try to avoid fragmentation but deal with it when ne= cessary. Also, I don't think PMTU discovery is applicable here. We are encapsulati= ng original packets/frames. What would we do if PMTU discovery told us th= at there is not sufficient headroom to add our encapsulations, whatever the= y may be? Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 jmoisand@juniper.net Thu Feb 13 08:44:15 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841E1A027C for ; Thu, 13 Feb 2014 08:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuqVZeSY8AVS for ; Thu, 13 Feb 2014 08:44:07 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id F25EA1A01CF for ; Thu, 13 Feb 2014 08:44:06 -0800 (PST) Received: from mail218-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 16:44:05 +0000 Received: from mail218-ch1 (localhost [127.0.0.1]) by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 06FDD1201F1 for ; Thu, 13 Feb 2014 16:44:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(z569dhzbb2dI98dI9371Ic89bh542I1432I15caKJdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz31iz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail218-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(13464003)(55784002)(199002)(189002)(51704005)(377454003)(479174003)(85306002)(65816001)(561944002)(19580395003)(19580405001)(79102001)(54316002)(93516002)(56776001)(77982001)(80976001)(59766001)(80022001)(54356001)(53806001)(66066001)(51856001)(76482001)(63696002)(46102001)(94316002)(47446002)(86362001)(74662001)(31966008)(74502001)(33646001)(94946001)(47736001)(15975445006)(83322001)(50986001)(47976001)(81816001)(81686001)(93136001)(49866001)(85852003)(69226001)(4396001)(221733001)(74366001)(90146001)(74316001)(74876001)(2656002)(87266001)(81342001)(87936001)(81542001)(74706001)(56816005)(92566001)(95666001)(95416001)(83072002)(15202345003)(76576001)(76796001)(76786001)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB714; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:E66DF9D9.A7FA9383.F9C1B173.92A5DB49.20950; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 1392309842789530_27757; Thu, 13 Feb 2014 16:44:02 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail218-ch1.bigfish.com (Postfix) with ESMTP id BC5CC4E005E for ; Thu, 13 Feb 2014 16:44:02 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 16:44:02 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 16:44:00 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 16:43:58 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 16:43:57 +0000 From: Jerome Moisand To: "'sfc@ietf.org'" Thread-Topic: MTU Thread-Index: Ac8o2oHnMZCedYTGShmh9RjlKXFXbQAACpNA Date: Thu, 13 Feb 2014 16:43:57 +0000 Message-ID: <3c74b639b7a94c51b3115fb037db303d@CO2PR05MB716.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [sfc] MTU X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:44:15 -0000 Yeah, well, in practice, large Ethernet frames are supported by every decen= t network systems on Earth, that is, the ones running in carrier-class netw= orks. Access Nodes, switches, routers, etc. So adding a small size fixed he= ader is usually not a problem. While adding variable-size fields IS a probl= em. That being said, I don't disagree with what you said. "Try to avoid fragmen= tation but deal with it when necessary" =3D> well worded. Let's just not ma= ke it necessary in mainstream cases... ;-) Anyhoo, again, we're in design weeds here... Seems premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, February 13, 2014 11:42 AM To: 'sfc@ietf.org' Subject: [sfc] MTU Resending due to SFC email list server complaining about too many recipient= s... The point I was trying to make here is that even fixed size headers may cre= ate the need for fragmentation. Furthermore, the full increase in packet= /frame size must account for both the SFC-transport header and the SFC-serv= ice header. A good network design will avoid the need for fragmentation = (which is admittedly easier to account for with fixed sized headers). But= when it is not possible to set MTU/MFS large enough on all links, then the= network should still function properly, although with the obvious ineffici= encies that are introduced. This is the IPv4 and IPv6 approach, in, gener= al (especially IPv6) -- try to avoid fragmentation but deal with it when ne= cessary. Also, I don't think PMTU discovery is applicable here. We are encapsulati= ng original packets/frames. What would we do if PMTU discovery told us th= at there is not sufficient headroom to add our encapsulations, whatever the= y may be? Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 ddolson@sandvine.com Thu Feb 13 09:00:46 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D72D1A022F for ; Thu, 13 Feb 2014 09:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 8pl9cl7Lqdot for ; Thu, 13 Feb 2014 09:00:42 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7735A1A02D9 for ; Thu, 13 Feb 2014 09:00:41 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Thu, 13 Feb 2014 12:00:39 -0500 From: Dave Dolson To: "'Ron_Parker@affirmednetworks.com'" , "'jmoisand@juniper.net'" , "'jmh@joelhalpern.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5T1if7u7sQPESL5TfpLJebsJqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFwCAAAcWAP//rLrQgABYqACAAAGugP//uNTggABWkACAALUQgP//5ao9AAFkm1AADli1gAAATHIAAAByvQAACWDfe///wLIAgAAGXoCAAADNgIAATcJB Date: Thu, 13 Feb 2014 17:00:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:00:46 -0000 That is when the ICMP "too big" message is sent to the sender, indicating a= n appropriate size to use, just as when any constraining MTU is encountered= .=20 So discovering the MTU of the chain is part of it, then passing the smaller= value on to the original sender.=20 Admittedly, it difficult to choose a size with a variable (unbounded?) head= er.=20 ----- Original Message ----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 13, 2014 11:38 AM=0A= To: Ron Parker ; Jerome Moisand ; Dave Dolson; 'jmh@joelhalpern.com' ; 'mo= hamed.boucadair@orange.com' ; 'Nicolas.BOUTHO= RS@qosmos.com' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: RE: [sfc] Framework Also, I don't think PMTU discovery is applicable here. We are encapsulati= ng original packets/frames. What would we do if PMTU discovery told us th= at there is not sufficient headroom to add our encapsulations? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, February 13, 2014 11:36 AM To: Jerome Moisand; Dave Dolson; 'jmh@joelhalpern.com'; 'mohamed.boucadair@= orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework The point I was trying to make that even fixed size headers will create the= need for fragmentation. Furthermore, the full increase in packet/frame = size must account for both the SFC-transport header and the SFC-service hea= der. A good network design will avoid the need for fragmentation (which = is admittedly easier to account for with fixed sized headers). But when i= t is not possible to set MTU/MFS large enough on all links, then the networ= k should still function properly, although with the obvious inefficiencies = that are introduced. This is the IPv4 and IPv6 approach, in, general (esp= ecially IPv6) -- try to avoid fragmentation but deal with it when necessary= . Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 Ron_Parker@affirmednetworks.com Thu Feb 13 09:08:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE21A0345 for ; Thu, 13 Feb 2014 09:08:08 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAkSIHk0JWSB for ; Thu, 13 Feb 2014 09:07:59 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id E302F1A0305 for ; Thu, 13 Feb 2014 09:07:58 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 09:07:57 -0800 From: Ron Parker To: "'sfc@ietf.org'" Thread-Topic: MTU Thread-Index: Ac8o3bKv3odEUKYdTH6w9dX3m0zSRA== Date: Thu, 13 Feb 2014 17:07:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sfc] MTU X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:08:08 -0000 Dave, I have been thinking that SFC is operating transparently to the end user. = Coupling SFC to end-user explicit behavioral requirements seems like the p= roverbial slippery slope to me. How do others feel about this? Ron =20 -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Thursday, February 13, 2014 12:01 PM To: Ron Parker; 'jmoisand@juniper.net'; 'jmh@joelhalpern.com'; 'mohamed.bou= cadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework That is when the ICMP "too big" message is sent to the sender, indicating a= n appropriate size to use, just as when any constraining MTU is encountered= .=20 So discovering the MTU of the chain is part of it, then passing the smaller= value on to the original sender.=20 Admittedly, it difficult to choose a size with a variable (unbounded?) head= er.=20 ----- Original Message ----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 13, 2014 11:38 AM To: Ron Parker ; Jerome Moisand ; Dave Dolson; 'jmh@joelhalpern.com' ; 'mo= hamed.boucadair@orange.com' ; 'Nicolas.BOUTHO= RS@qosmos.com' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: RE: [sfc] Framework Also, I don't think PMTU discovery is applicable here. We are encapsulati= ng original packets/frames. What would we do if PMTU discovery told us th= at there is not sufficient headroom to add our encapsulations? Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, February 13, 2014 11:36 AM To: Jerome Moisand; Dave Dolson; 'jmh@joelhalpern.com'; 'mohamed.boucadair@= orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework The point I was trying to make that even fixed size headers will create the= need for fragmentation. Furthermore, the full increase in packet/frame = size must account for both the SFC-transport header and the SFC-service hea= der. A good network design will avoid the need for fragmentation (which = is admittedly easier to account for with fixed sized headers). But when i= t is not possible to set MTU/MFS large enough on all links, then the networ= k should still function properly, although with the obvious inefficiencies = that are introduced. This is the IPv4 and IPv6 approach, in, general (esp= ecially IPv6) -- try to avoid fragmentation but deal with it when necessary= . Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. If the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ; >>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the total length of the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. If the header had the ability to add extensions >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. Through mechanisms we have not yet begun >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 mikebianc@aol.com Thu Feb 13 09:21:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4A01A02CD for ; Thu, 13 Feb 2014 09:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, 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 mllDJ-XJIUbx for ; Thu, 13 Feb 2014 09:21:07 -0800 (PST) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) by ietfa.amsl.com (Postfix) with ESMTP id 392581A02CF for ; Thu, 13 Feb 2014 09:21:07 -0800 (PST) Received: from mtaout-mbe01.mx.aol.com (mtaout-mbe01.mx.aol.com [172.26.254.173]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id 1314D70000094; Thu, 13 Feb 2014 12:21:06 -0500 (EST) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbe01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C72683800009B; Thu, 13 Feb 2014 12:21:05 -0500 (EST) Date: Thu, 13 Feb 2014 12:21:05 -0500 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <1191180552.37515.1392312065690.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37514_1906702098.1392312065689" X-Originating-IP: 10.172.1.75, 205.188.60.49 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1392312066; bh=LhtO1FJ4+/8aZmfi/WO/RJWawuJt8KTHySA3YpXSnEw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ac2CgfkuDSPwp85Ur9ehsqKs0E58YgYwTMXJE13L5hy/dLRu1QLw97c+z7tiIQ/yZ DzP7GYJv/zp0tLUOao5MgN9TSktmEykmxKfnUa1MQsVKj515zUB1n2L5WY6fgfz9rG TGxYI5YrdG86o73DhU1QBMKaJKY8el6GfTyWyuhE= x-aol-sid: 3039ac1afead52fcff016fc7 X-AOL-IP: 64.12.250.54 Subject: Re: [sfc] MTU X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:21:14 -0000 ------=_Part_37514_1906702098.1392312065689 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This isn't an end-user behavior requirement, though. =C2=A0To make SFC tran= sparent to the end-user, you would want to send back an appropriate 'too bi= g' message. =C2=A0The draft text on this could be as simple as requiring th= at any SFC implementation send back an appropriate MTU for the sender to us= e based on the header that would have been applied, leaving the 'how' up to= implementation. From: Ron_Parker@affirmednetworks.com To: 'sfc@ietf.org' Sent: Thursday, February 13, 2014 Subject: [sfc] MTU Dave, I have been thinking that SFC is operating transparently to the end user. = =C2=A0 Coupling SFC to end-user explicit behavioral requirements seems like= the proverbial slippery slope to me. =C2=A0 How do others feel about this? =C2=A0=C2=A0 Ron =20 -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Thursday, February 13, 2014 12:01 PM To: Ron Parker; 'jmoisand@juniper.net'; 'jmh@joelhalpern.com'; 'mohamed.bou= cadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework That is when the ICMP "too big" message is sent to the sender, indicating a= n appropriate size to use, just as when any constraining MTU is encountered= .=20 So discovering the MTU of the chain is part of it, then passing the smaller= value on to the original sender.=20 Admittedly, it difficult to choose a size with a variable (unbounded?) head= er.=20 ----- Original Message ----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, February 13, 2014 11:38 AM To: Ron Parker ; Jerome Moisand ; Dave Dolson; 'jmh@joelhalpern.com' ; 'mo= hamed.boucadair@orange.com' ; 'Nicolas.BOUTHO= RS@qosmos.com' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: RE: [sfc] Framework Also, I don't think PMTU discovery is applicable here. =C2=A0 We are encaps= ulating original packets/frames. =C2=A0 What would we do if PMTU discovery = told us that there is not sufficient headroom to add our encapsulations? =C2=A0=C2=A0 Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, February 13, 2014 11:36 AM To: Jerome Moisand; Dave Dolson; 'jmh@joelhalpern.com'; 'mohamed.boucadair@= orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework The point I was trying to make that even fixed size headers will create the= need for fragmentation. =C2=A0=C2=A0 Furthermore, the full increase in pac= ket/frame size must account for both the SFC-transport header and the SFC-s= ervice header. =C2=A0=C2=A0 A good network design will avoid the need for f= ragmentation (which is admittedly easier to account for with fixed sized he= aders). =C2=A0 But when it is not possible to set MTU/MFS large enough on a= ll links, then the network should still function properly, although with th= e obvious inefficiencies that are introduced. =C2=A0 This is the IPv4 and I= Pv6 approach, in, general (especially IPv6) -- try to avoid fragmentation b= ut deal with it when necessary. =C2=A0 Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 11:13 AM To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@oran= ge.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: RE: [sfc] Framework Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kind of= world nowadays. Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)? For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate. Anyhoo, we're jumping way deep in the detailed protocol design here. This s= eems a tad premature. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 13, 2014 11:03 AM To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.bouc= adair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: Re: [sfc] Framework it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.=20 The fragmenting also puts huge performance burden on the service functions. Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination. =20 So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).=20 Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.=20 -Dave ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:31 AM To: Ron Parker ; mohamed.boucadair@orange.= com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.c= om' ; 'paulq@cisco.com' Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'lind= a.dunbar@huawei.com' Subject: Re: [sfc] Framework I mostly agree with you Ron. I can probably come up with some other variat= ions, but your second point is that the transport must deal with the issue = of frame size / fit. I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble. Yours, Joel On 2/13/14, 10:18 AM, Ron Parker wrote: > Joel, > > That is an excellent point to consider when choosing transport > encapsulations. =C2=A0 If the transport encapsulation is IPv4 or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally supported. =C2=A0=C2=A0 I= f the > transport encapsulation is VLAN, MPLS, etc., then I believe one of the=20 > following must be true: > > * The end-to-end path is known to support the resulting larger frames > * A path discovery mechanism is mandated by SFC when non-IP transports=20 > are used * An SFC-specific fragmentation header and mechanisms must be=20 > defined (i.e., > SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern=20 > [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10=20 > AM To: mohamed.boucadair@orange.com; Dave Dolson;=20 > 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to support IPv6.=20 > IPv6 explicitly prohibits network elements from fragmenting end user=20 > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> FWIW, one of the existing architecture drafts includes the following=20 >> behavior >> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >> >> >> " >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result in a fragmented=20 >> packet, the classifier should include a Service Chaining Header in=20 >> each fragment. Doing so would prevent SF Nodes to dedicate resource=20 >> to handle fragments. " >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]=20 >>> De la part de Dave Dolson Envoy=C3=A9 : >>> jeudi 13 f=C3=A9vrier 2014 13:39 =C3=80 : 'Nicolas.BOUTHORS@qosmos.com'= ;=20 >>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';=20 >>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';=20 >>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the forwarding=20 >>> functions do not need to reassemble. Each fragment should be=20 >>> independently forwardable; some SFs may choose to ignore these=20 >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>> Otherwise, a reassembly layer could be added after the forwarding=20 >>> coordinates. Think of something like the IPv6 reassembly option=20 >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be fragmented and that=20 >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas BOUTHORS=20 >>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker ;>>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>> (paulq) Cc: Sumandra Majee ;=20 >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have other implication. >>> >>> There is the question of segmentation and reassembly responsibility=20 >>> as well. >>> >>> If adding length to the service header forces segmentation, then=20 >>> whose responsibility is it to reassemble the payload before passing=20 >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> ________________________________________ From: Ron Parker=20 >>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically separate the forwarding >>> function from the SFC-aware service function, as we should. =C2=A0 The >>> forwarding function is concerned with only the inbound transport=20 >>> header, the fixed portion of the service header containing the >>> chain information, and the outbound transport header. =C2=A0=C2=A0 The >>> service function may look at the entirety of the service header and=20 >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson=20 >>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc]=20 >>> Framework >>> >>> The forwarding plane might not even need to look at the encapsulated=20 >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN tag), an Ethernet=20 >>> switch can forward packets of the form: Ether | VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;=20 >>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> Hi, Dave. >>>> >>>> I Agree with your statement. =C2=A0=C2=A0 And if the total length of = the >>>> header is >>> contained in the mandatory portion, the hardware implementation can=20 >>> easily locate the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson=20 >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the SF Identifier) should=20 >>>> be in >>> a mandatory fixed-size header. >>>> >>>> Optional information (if any) is NOT to be used for forwarding, but=20 >>>> is >>> for consumption by one or more of the applications in the chain. >>>> >>>> Then the forwarding plane, and even the PDP, can be agnostic about=20 >>>> the >>> meta-data. >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where extensions or options can=20 >>>> be >>> added but the total length is contained in the fixed portion. =C2=A0 I >>> can envision certain deployments (e.g., Enterprise) where perhaps=20 >>> extensions are not needed and the SFC functionality is realized >>> in hardware. =C2=A0 And, I can envision certain other deployments >>> (e.g., 3gpp) where the extension headers add sufficient value to=20 >>> justify software based implementations. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn (paulq)=20 >>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.=20 >>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with variable length headers=20 >>>> when >>> hardware platform are in play. >>>> >>>> Ron, your examples of IP options and v6 EH have both suffered from >>> significant implementation and deployment hurdles due to the=20 >>> complexity and cost associated with hardware support for the=20 >>> option/EH. >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker=20 >>>> >>> wrote: >>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I completely agree. =C2=A0 I >>>>> might >>> suggest a compromise between hardware friendliness and software >>> flexibility. =C2=A0=C2=A0 If the header had the ability to add extensio= ns >>> (perhaps similar to IPv6) but also had the header length encoded in=20 >>> the mandatory part (like IPv4), then a hardware implementation would=20 >>> be free to skip over the extensions (in cases where the deployment=20 >>> justifies ignoring the extensions). >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Sumandra Majee=20 >>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;=20 >>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>>> header that is independent of the transport methodology. >>>>> >>>>> >>>>> I agree. However the format of service header should be=20 >>>>> standardized in >>> a way that is flexible. Some of us would like to see variable length=20 >>> header that is also HW friendly. The service header can be=20 >>> represented as a mandotory fixed length header (like IP >>> header) along with an optional variable length attribute field. >>> Different services can be interested in different metadata, for=20 >>> example subscriber ID could be of interest in the mobile core=20 >>> service chain only. >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>> wrote: >>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the architecture docs is that the service=20 >>>>>> function chain is built in an abstract manner (i.e., SF-A then=20 >>>>>> SF-B >>> then SF-C). >>>>>> Separately, a locator table provides network location for >>>>>> each of those service functions. =C2=A0 In this way, you can >>>>>> locate the service functions >>> in >>>>>> a manner appropriate to the type of transport you are >>>>>> using. =C2=A0 If you want that to be interface+VLAN, >>>>>> gateway-IP+MPLS label stack, IP >>> address, >>>>>> GRE tunnel remote IP + key, etc., you can do that. =C2=A0=C2=A0 You >>>>>> can even potentially locate different service functions that=20 >>>>>> reside in the same chain with different flavors of >>>>>> network locators. =C2=A0=C2=A0 Another justification to separate the >>>>>> identity of a service function from its network location is >>>>>> load balancing. =C2=A0 If, for example, SF-A had 3 IP addresses, >>>>>> that would imply load balancing to 3 instances using IP as a=20 >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I strongly support a canonical service=20 >>>>>> header that is independent of the transport >>>>>> methodology. =C2=A0=C2=A0 At a particular node, the decision as to >>>>>> where to go next should be based solely on information carried in=20 >>>>>> the canonical service header and not on the >>> fields >>>>>> in the transport header. =C2=A0 That is, the SFC node discards >>>>>> the transport header and extracts the chain ID from the >>>>>> service header. =C2=A0=C2=A0 Through mechanisms we have not yet begu= n >>>>>> to discuss, the SFC node knows how to interpret the chain ID and=20 >>>>>> ultimately how to progress the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>> Classifier) to emphasize this point. >>>>>> >>>>>> "A Service Chain Classifier node can associate a unique Layer 2=20 >>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes=20 >>>>>> along the flow path to steer the flow to the service functions=20 >>>>>> specified by the flow's service chain." >>>>>> >>>>>> >>>>>> Linda -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the framework proposal. The proposal has a very=20 >>>>>> specific model of the scope of the transport header (that it is=20 >>>>>> derived from, and relates only to, the first service function to=20 >>>>>> which the packet will be directed. That is clearly an operational=20 >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to allow other transport operational=20 >>>>>> models, such as the use of a VLAN to direct traffic along a=20 >>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> 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 ------=_Part_37514_1906702098.1392312065689 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This isn't an e= nd-user behavior requirement, though.  To make SFC transparent to the = end-user, you would want to send back an appropriate 'too big' message. &nb= sp;The draft text on this could be as simple as requiring that any SFC impl= ementation send back an appropriate MTU for the sender to use based on the = header that would have been applied, leaving the 'how' up to implementation= .





From: Ron_Parker@affirmednetworks.com<Ron_Parker@= affirmednetworks.com>
To: 'sfc@ietf.org'<sfc@ietf.org>Sent: Thursday, February 13, 2014
Subject: [sfc] MTU
=
Dave,

I have been thinking that SFC is operating = transparently to the end user.   Coupling SFC to end-user explicit beh= avioral requirements seems like the proverbial slippery slope to me.  = How do others feel about this?

   Ron


-----O= riginal Message-----
From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Thursday, February 13, 2= 014 12:01 PM
To: Ron Parker; 'jm= oisand@juniper.net'; 'jmh@joelha= lpern.com'; 'mohamed.bo= ucadair@orange.com'; 'Ni= colas.BOUTHORS@qosmos.com'; 'paulq@c= isco.com'
Cc: 'S.Majee@F5.com'= ; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Subject: Re: [sfc] F= ramework

That is when the ICMP "too big" message is sent to the send= er, indicating an appropriate size to use, just as when any constraining MT= U is encountered.

So discovering the MTU of the chain is part of it= , then passing the smaller value on to the original sender.

Admitte= dly, it difficult to choose a size with a variable (unbounded?) header.


----- Original Message -----
From: Ron Parker [mailto:Ron_Parker@affirmednetworks.c= om]
Sent: Thursday, February 13, 2014 11:38 AM
To: Ron Parker <= ;Ron_Parker@affirmednetw= orks.com>; Jerome Moisand <jmoisand@juniper.net>; Dave Dolson; 'jmh@joelhalpern.com' <jmh@joelhalpern.com>; 'mohamed.boucadair@orange.com' <mohamed.boucadair@orange.com>; 'Nicolas.BOUTHORS@qosmos.com' <Nicolas.BOUTHORS@qosmos.com>; '= paulq@cisco.com' <paulq@cisco.com>
Cc: 'S.Majee@F5.com' <S.Maje= e@F5.com>; 'sfc@ietf.org' <sfc@ietf.org>; 'linda.dunbar@huawei.com' <linda.dunbar@huawei.com>
Subject: RE: [sfc]= Framework

Also, I don't think PMTU discovery is applicable here. &n= bsp; We are encapsulating original packets/frames.   What would we do = if PMTU discovery told us that there is not sufficient headroom to add our = encapsulations?

   Ron


-----Original Message--= ---
From: sfc [mailto:sfc-bounce= s@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, February 13, 201= 4 11:36 AM
To: Jerome Moisand; Dave Dolson; 'jmh@joelhalpern.com'; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com'
Cc: 'S.Majee@F5.com'; 'sfc@ietf.org';= 'linda.dunbar@huawei.com'Subject: Re: [sfc] Framework

The point I was trying to make that e= ven fixed size headers will create the need for fragmentation.   = Furthermore, the full increase in packet/frame size must account for both = the SFC-transport header and the SFC-service header.    A good ne= twork design will avoid the need for fragmentation (which is admittedly eas= ier to account for with fixed sized headers).   But when it is not pos= sible to set MTU/MFS large enough on all links, then the network should sti= ll function properly, although with the obvious inefficiencies that are int= roduced.   This is the IPv4 and IPv6 approach, in, general (especially= IPv6) -- try to avoid fragmentation but deal with it when necessary.
  Ron


-----Original Message-----
From: Jerome Moisand= [mailto:jmoisand@juniper.net]<= br>Sent: Thursday, February 13, 2014 11:13 AM
To: Dave Dolson; 'jmh@joelhalpern.com'; Ron Parker; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos= .com'; 'paulq@cisco.com'
Cc: = 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Subject: RE: [sfc] Framework

Yes, = fragmentation and variable headers are usually a really bad thing for forwa= rding performance. Let's not forget that we live in a 100G-ish kind of worl= d nowadays.

Now the question should be: WHY would we want to do that= (variable headers leading to fragmentation issues)?

For example, th= e type of metadata that may require variable-length fields might be a bette= r candidate for some out-of-band signaling mechanism. If this is service au= thorization data (e.g. a service profile/policy), this sounds likely. Not 1= 00% sure this is true for all use cases though. Only a good understanding o= f use cases, grounded by reflecting on existing network architectures (nota= bly broadband, fixed or mobile), would tell us if one approach or another i= s the most appropriate.

Anyhoo, we're jumping way deep in the detail= ed protocol design here. This seems a tad premature.

-----Original M= essage-----
From: sfc [mailto:sf= c-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, Februar= y 13, 2014 11:03 AM
To: 'jmh@joel= halpern.com'; 'Ron_P= arker@affirmednetworks.com'; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com'
Cc: 'S.= Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Sub= ject: Re: [sfc] Framework

it is overall more efficient to support PM= TU discovery rather than fragmenting every large packet. The is why TCP ado= pted it so early on.

The fragmenting also puts huge performance bur= den on the service functions.
Fragmenting may also affect the ability of= load balancers to get each fragment to the correct destination.

S= o PMTU discovery SHOULD be used, in my opinion. By this I mean the client o= r server is informed that its packets are too big (for IPv6 or IPv4 with DF= =3D1).

Some operators may wish to incur the extra cost to hide the = existence of the tunneling, when the elements of the chain can support it, = so we could consider that as an optional mechanism.

-Dave

----- Original Message -----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, Feb= ruary 13, 2014 10:31 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>; mohamed.boucadair@orange.com <mohamed.boucadair@orange.com<= /a>>; Dave Dolson; 'Nicol= as.BOUTHORS@qosmos.com' <Nicolas.BOUTHORS@qosmos.com>; 'paulq@cisco.com' <paulq@cisco.c= om>
Cc: 'S.Majee@F5.com' &l= t;S.Majee@F5.com>; 'sfc@ietf.org' <sfc= @ietf.org>; 'linda.dunbar= @huawei.com' <linda.dunba= r@huawei.com>
Subject: Re: [sfc] Framework

I mostly agree = with you Ron. I can probably come up with some other variations, but your = second point is that the transport must deal with the issue of frame size /= fit.

I would note that if we assume that the carrying encaps (IPv4/= v6 outer) is being fragmented, then we are assuming that the exit from serv= ice chaining can and will reassemble.

Yours,
Joel

On 2/13/= 14, 10:18 AM, Ron Parker wrote:
> Joel,
>
> That is an ex= cellent point to consider when choosing transport
> encapsulations. &= nbsp; If the transport encapsulation is IPv4 or IPv6
> based (i.e., I= Px/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then
> fragmentation and defra= gmentation are naturally supported.    If the
> transport e= ncapsulation is VLAN, MPLS, etc., then I believe one of the
> follow= ing must be true:
>
> * The end-to-end path is known to support= the resulting larger frames
> * A path discovery mechanism is mandat= ed by SFC when non-IP transports
> are used * An SFC-specific fragme= ntation header and mechanisms must be
> defined (i.e.,
> SFC-t= ransport/SFC-fragmentation/SFC-service/original-packet-or-frame)
>> Ron
>
>
> -----Original Message----- From: Joel M.= Halpern
> [mailto:jmh@joelha= lpern.com] Sent: Thursday, February 13, 2014 10:10
> AM To: mohamed.boucadair@orange.com; Dave Dolson;
> 'Ni= colas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc:
> 'S.= Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subjec= t:
> Re: [sfc] Framework
>
> There is a related complexit= y. I hope that we expect to support IPv6.
> IPv6 explicitly prohibit= s network elements from fragmenting end user
> packets.
>
&= gt; Yours, Joel
>
> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote:
>&g= t; Re-,
>>
>> FWIW, one of the existing architecture draf= ts includes the following
>> behavior
>> (http://= tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6):
>= ;>
>>
>>
"
>> 6. Fragmentation Considerati= ons
>>
>> If adding the Service Chaining Header would res= ult in a fragmented
>> packet, the classifier should include a Se= rvice Chaining Header in
>> each fragment. Doing so would preven= t SF Nodes to dedicate resource
>> to handle fragments. "
>= >
>> Cheers, Med
>>
>>
>>> -----M= essage d'origine----- De : sfc [mai= lto:sfc-bounces@ietf.org]
>>> De la part de Dave Dolson En= voy=C3=A9 :
>>> jeudi 13 f=C3=A9vrier 2014 13:39 =C3=80 : 'Nicolas.BOUTHORS@qosmos.com'= ;
>>> 'Ron_= Parker@affirmednetworks.com'; 'j= mh@joelhalpern.com';
>>> 'paulq@cisco.com' Cc : 'S.Majee@F5.= com'; 'sfc@ietf.org';
>>&= gt; 'linda.dunbar@huawei.com= ' Objet : Re: [sfc] Framework
>>>
>>> Good point to= consider fragmentation.
>>>
>>> We should design t= he encapsulation such that the forwarding
>>> functions do not= need to reassemble. Each fragment should be
>>> independently= forwardable; some SFs may choose to ignore these
>>> packets.=
>>>
>>> Any layer 2.5 protocol like VLAN or MPLS w= ould support this.
>>> Otherwise, a reassembly layer could be a= dded after the forwarding
>>> coordinates. Think of something = like the IPv6 reassembly option
>>> after a GRE header, for in= stance.
>>>
>>> IP | GRE | reassem | frag data
&= gt;>>
>>> We could alternatively mandate the inner IP be = fragmented and that
>>> path-MTU discovery be supported.
&g= t;>>
>>>
>>>
>>>
>>> = ----- Original Message ----- From: Nicolas BOUTHORS
>>> [mailto:Nicolas.BOUTHORS@qosmos.co= m] Sent: Thursday, February 13,
>>> 2014 04:13 AM To: Ron P= arker <Ron_Parker@aff= irmednetworks.com>;
>>> Dave Dolson; Joel M. Halpern <= ;jmh@joelhalpern.com>; Paul Q= uinn
>>> (paulq) <paulq@c= isco.com> Cc: Sumandra Majee <S= .Majee@F5.com>;
>>> sfc= @ietf.org <sfc@ietf.org>; Lin= da Dunbar <linda.dunbar@huawe= i.com>
>>> Subject: Re: [sfc] Framework
>>><= br>>>> If we do not enforce a fix header size we have other implic= ation.
>>>
>>> There is the question of segmentatio= n and reassembly responsibility
>>> as well.
>>>>>> If adding length to the service header forces segmentation, = then
>>> whose responsibility is it to reassemble the payload = before passing
>>> it to the SF.
>>>
>>&g= t; Similar question for packet re-ordering.
>>>
>>>=
>>> ________________________________________ From: Ron Parker =
>>> [Ron_Pa= rker@affirmednetworks.com] Sent: Wednesday, February 12,
>>>= ; 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn
>>>= ; (paulq) Cc: Sumandra Majee; sfc@ietf.org<= /a>; Linda Dunbar Subject:
>>> Re: [sfc] Framework
>>&= gt;
>>> Dave,
>>>
>>> Yes, that is a go= od point if we logically separate the forwarding
>>> function f= rom the SFC-aware service function, as we should.   The
>>>= ; forwarding function is concerned with only the inbound transport
>= >> header, the fixed portion of the service header containing the>>> chain information, and the outbound transport header.  &= nbsp; The
>>> service function may look at the entirety of the = service header and
>>> would look at the encapsulated packet.<= br>>>>
>>> Ron
>>>
>>>
>= >> -----Original Message----- From: Dave Dolson
>>> [mailto:ddolson@sandvine.com] Sent:= Wednesday, February 12, 2014
>>> 5:18 PM To: Joel M. Halpern; = Ron Parker; Paul Quinn (paulq) Cc:
>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] =
>>> Framework
>>>
>>> The forwarding p= lane might not even need to look at the encapsulated
>>> packe= t.
>>>
>>> For example, (if the SF Identifier is a = VLAN tag), an Ethernet
>>> switch can forward packets of the f= orm: Ether | VLAN | BLOB.
>>>
>>>
>>><= br>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
>>> On Beh= alf Of Joel M. Halpern Sent:
>>> Wednesday, February 12, 2014 4= :30 PM To: Ron Parker; Dave Dolson;
>>> Paul Quinn (paulq) Cc:= Sumandra Majee; sfc@ietf.org; Linda Du= nbar
>>> Subject: Re: [sfc] Framework
>>>
>&g= t;> I agree as well. Yours, Joel
>>>
>>> On 2/12= /14, 4:24 PM, Ron Parker wrote:
>>>> Hi, Dave.
>>&g= t;>
>>>> I Agree with your statement.    And i= f the total length of the
>>>> header is
>>> con= tained in the mandatory portion, the hardware implementation can
>&g= t;> easily locate the encapsulated packet.
>>>>
>&g= t;>> Ron
>>>>
>>>>
>>>> = -----Original Message----- From: Dave Dolson
>>>> [mailto:ddolson@sandvine.com] Sent: Wed= nesday, February 12,
>>>> 2014 4:10 PM To: Ron Parker; Paul = Quinn (paulq) Cc: Joel M.
>>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject:
>= >>> RE: [sfc] Framework
>>>>
>>>> I = think a good approach would be:
>>>>
>>>> The= information required for forwarding (the SF Identifier) should
>>= ;>> be in
>>> a mandatory fixed-size header.
>>&= gt;>
>>>> Optional information (if any) is NOT to be used= for forwarding, but
>>>> is
>>> for consumptio= n by one or more of the applications in the chain.
>>>>
&= gt;>>> Then the forwarding plane, and even the PDP, can be agnosti= c about
>>>> the
>>> meta-data.
>>>= >
>>>> -Dave
>>>>
>>>>
&= gt;>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
>>>> On= Behalf Of Ron Parker Sent:
>>>> Wednesday, February 12, 201= 4 4:05 PM To: Paul Quinn (paulq) Cc:
>>>> Joel M. Halpern; S= umandra Majee; sfc@ietf.org; Linda Dunb= ar
>>>> Subject: Re: [sfc] Framework
>>>>
= >>>> Paul,
>>>>
>>>> That is why = I am proposing a hybrid where extensions or options can
>>>>= ; be
>>> added but the total length is contained in the fixed p= ortion.   I
>>> can envision certain deployments (e.g., En= terprise) where perhaps
>>> extensions are not needed and the = SFC functionality is realized
>>> in hardware.   And, I ca= n envision certain other deployments
>>> (e.g., 3gpp) where the= extension headers add sufficient value to
>>> justify softwar= e based implementations.
>>>>
>>>> Ron
>= ;>>>
>>>>
>>>> -----Original Message= ----- From: Paul Quinn (paulq)
>>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014=
>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunba= r; Joel M.
>>>> Halpern; sf= c@ietf.org Subject: Re: [sfc] Framework
>>>>
>>= >> Hi,
>>>>
>>>> We certainly need to b= e very careful with variable length headers
>>>> when
&g= t;>> hardware platform are in play.
>>>>
>>&g= t;> Ron, your examples of IP options and v6 EH have both suffered from>>> significant implementation and deployment hurdles due to the=
>>> complexity and cost associated with hardware support for = the
>>> option/EH.
>>>>
>>>> Pau= l
>>>>
>>>> On Feb 12, 2014, at 3:10 PM, Ron = Parker
>>>> <Ron_Parker@affirmednetworks.com>
>>> wrote:
&= gt;>>>
>>>>> Hi, Sumandra.
>>>>&g= t;
>>>>> Regarding service header flexibility, I complete= ly agree.   I
>>>>> might
>>> suggest a = compromise between hardware friendliness and software
>>> flexi= bility.    If the header had the ability to add extensions
>= ;>> (perhaps similar to IPv6) but also had the header length encoded = in
>>> the mandatory part (like IPv4), then a hardware impleme= ntation would
>>> be free to skip over the extensions (in case= s where the deployment
>>> justifies ignoring the extensions).=
>>>>>
>>>>> Ron
>>>>>= ;
>>>>>
>>>>> -----Original Message----= - From: Sumandra Majee
>>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014
&g= t;>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; <= br>>>>>> sfc@ietf.org Su= bject: Re: [sfc] Framework
>>>>>
>>>>>&= gt;> For all of those reasons, I strongly support a canonical service >>>>>>> header that is independent of the transport = methodology.
>>>>>
>>>>>
>>>= ;>> I agree. However the format of service header should be
>&= gt;>>> standardized in
>>> a way that is flexible. Som= e of us would like to see variable length
>>> header that is a= lso HW friendly. The service header can be
>>> represented as = a mandotory fixed length header (like IP
>>> header) along with= an optional variable length attribute field.
>>> Different ser= vices can be interested in different metadata, for
>>> example= subscriber ID could be of interest in the mobile core
>>> ser= vice chain only.
>>>>>
>>>>> Sumandra>>>>>
>>>>> On 2/12/14, 11:32 AM, "Ron P= arker"
>>>>> <Ron_Parker@affirmednetworks.com>
>>> wrote:>>>>>
>>>>>> Linda,
>>>&g= t;>>
>>>>>> My interpretation of the architectur= e docs is that the service
>>>>>> function chain is b= uilt in an abstract manner (i.e., SF-A then
>>>>>> SF= -B
>>> then SF-C).
>>>>>> Separately, a lo= cator table provides network location for
>>>>>> each = of those service functions.   In this way, you can
>>>>= >> locate the service functions
>>> in
>>>>= ;>> a manner appropriate to the type of transport you are
>>= >>>> using.   If you want that to be interface+VLAN,
&g= t;>>>>> gateway-IP+MPLS label stack, IP
>>> addr= ess,
>>>>>> GRE tunnel remote IP + key, etc., you can = do that.    You
>>>>>> can even potentially = locate different service functions that
>>>>>> reside= in the same chain with different flavors of
>>>>>> ne= twork locators.    Another justification to separate the
>&= gt;>>>> identity of a service function from its network locatio= n is
>>>>>> load balancing.   If, for example, SF= -A had 3 IP addresses,
>>>>>> that would imply load ba= lancing to 3 instances using IP as a
>>>>>> transport= layer.
>>>>>>
>>>>>> For all of = those reasons, I strongly support a canonical service
>>>>&= gt;> header that is independent of the transport
>>>>>= > methodology.    At a particular node, the decision as to
= >>>>>> where to go next should be based solely on informa= tion carried in
>>>>>> the canonical service header a= nd not on the
>>> fields
>>>>>> in the tra= nsport header.   That is, the SFC node discards
>>>>>= ;> the transport header and extracts the chain ID from the
>>&g= t;>>> service header.    Through mechanisms we have not = yet begun
>>>>>> to discuss, the SFC node knows how to= interpret the chain ID and
>>>>>> ultimately how to = progress the packet.
>>>>>>
>>>>>>= ; Ron
>>>>>>
>>>>>>
>>&g= t;>>> -----Original Message----- From: sfc
>>>>>= ;> [mailto:sfc-bounces@ietf.org<= /a>] On Behalf Of Linda Dunbar
>>>>>> Sent: Wednesday,= February 12, 2014 12:01 PM To: Joel M.
>>>>>> Halpern= ; sfc@ietf.org Subject: Re: [sfc] Frame= work
>>>>>>
>>>>>> Agree with Joe= l's statement.
>>>>>>
>>>>>> I th= ink a simple sentence below should be added Section 5.2 (SFC
>>>= ;>>> Classifier) to emphasize this point.
>>>>>&= gt;
>>>>>> "A Service Chain Classifier node can associ= ate a unique Layer 2
>>>>>> or 3 Label (e.g. VLAN, MP= LS label) to the packets in the flow.
>>>>>> Those Lay= er 2 or 3 Label makes it easier for subsequent nodes
>>>>&g= t;> along the flow path to steer the flow to the service functions
&= gt;>>>>> specified by the flow's service chain."
>>= >>>>
>>>>>>
>>>>>> Li= nda -----Original Message----- From: sfc
>>>>>> [mailto:sfc-bounces@ietf.org] On Beh= alf Of Joel M. Halpern
>>>>>> Sent: Wednesday, Februar= y 12, 2014 10:20 AM To:
>>>>>> sfc@ietf.org Subject: [sfc] Framework
>>>>>&= gt;
>>>>>> I was looking at the framework proposal. Th= e proposal has a very
>>>>>> specific model of the sc= ope of the transport header (that it is
>>>>>> derive= d from, and relates only to, the first service function to
>>>= >>> which the packet will be directed. That is clearly an operatio= nal
>>>>>> model we need to support.
>>>&= gt;>>
>>>>>> However, I would like to allow othe= r transport operational
>>>>>> models, such as the us= e of a VLAN to direct traffic along a
>>>>>> chain. = Or the use of an MPLS label, or an MPLS label stack.
>>>>>= ;>
>>>>>> Yours, Joel M. Halpern
>>>>= ;>>
>>>>>> _____________________________________= __________ 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
>>>>&= gt;>
>>>>>> _______________________________________= ________ sfc mailing list
>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>>>&g= t;
>>>>> _______________________________________________ = sfc mailing list
>>>>> s= fc@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
&= gt;>>
>>> _______________________________________________= 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
------=_Part_37514_1906702098.1392312065689-- From nobody Thu Feb 13 10:16:07 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF931A03D9 for ; Thu, 13 Feb 2014 10:16:05 -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 5nNcDVjfxC5P for ; Thu, 13 Feb 2014 10:16:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id AAB341A0384 for ; Thu, 13 Feb 2014 10:16:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C40CA1BDB4C0; Thu, 13 Feb 2014 10:16:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 413221BDB4BF; Thu, 13 Feb 2014 10:15:58 -0800 (PST) Message-ID: <52FD0BE3.7050903@joelhalpern.com> Date: Thu, 13 Feb 2014 13:16:03 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jerome Moisand , Dave Dolson , "'Ron_Parker@affirmednetworks.com'" , "'mohamed.boucadair@orange.com'" , "'Nicolas.BOUTHORS@qosmos.com'" , "'paulq@cisco.com'" References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5Ra2AOWtzC5MNvQEAQDdON9j3ME Cc: "'S.Majee@F5.com'" , "'sfc@ietf.org'" , "'linda.dunbar@huawei.com'" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:16:05 -0000 The variable length shim header is needed even if every individual piece of metadata has a fixed length. Different service chains will need different combinations of metadata. So the metadata portion of the header needs to be variable length. I think the approach of a fixed length initial part, and a variable length extension part, is the right model. Yours, Joel On 2/13/14, 11:13 AM, Jerome Moisand wrote: > Yes, fragmentation and variable headers are usually a really bad thing for forwarding performance. Let's not forget that we live in a 100G-ish kind of world nowadays. > > Now the question should be: WHY would we want to do that (variable headers leading to fragmentation issues)? > > For example, the type of metadata that may require variable-length fields might be a better candidate for some out-of-band signaling mechanism. If this is service authorization data (e.g. a service profile/policy), this sounds likely. Not 100% sure this is true for all use cases though. Only a good understanding of use cases, grounded by reflecting on existing network architectures (notably broadband, fixed or mobile), would tell us if one approach or another is the most appropriate. > > Anyhoo, we're jumping way deep in the detailed protocol design here. This seems a tad premature. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Thursday, February 13, 2014 11:03 AM > To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; 'mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; 'paulq@cisco.com' > Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' > Subject: Re: [sfc] Framework > > it is overall more efficient to support PMTU discovery rather than fragmenting every large packet. The is why TCP adopted it so early on. > > The fragmenting also puts huge performance burden on the service functions. > Fragmenting may also affect the ability of load balancers to get each fragment to the correct destination. > > So PMTU discovery SHOULD be used, in my opinion. By this I mean the client or server is informed that its packets are too big (for IPv6 or IPv4 with DF=1). > > Some operators may wish to incur the extra cost to hide the existence of the tunneling, when the elements of the chain can support it, so we could consider that as an optional mechanism. > > -Dave > > > ----- Original Message ----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 10:31 AM > To: Ron Parker ; mohamed.boucadair@orange.com ; Dave Dolson; 'Nicolas.BOUTHORS@qosmos.com' ; 'paulq@cisco.com' > Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; 'linda.dunbar@huawei.com' > Subject: Re: [sfc] Framework > > I mostly agree with you Ron. I can probably come up with some other variations, but your second point is that the transport must deal with the issue of frame size / fit. > > I would note that if we assume that the carrying encaps (IPv4/v6 outer) is being fragmented, then we are assuming that the exit from service chaining can and will reassemble. > > Yours, > Joel > > On 2/13/14, 10:18 AM, Ron Parker wrote: >> Joel, >> >> That is an excellent point to consider when choosing transport >> encapsulations. If the transport encapsulation is IPv4 or IPv6 >> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then >> fragmentation and defragmentation are naturally supported. If the >> transport encapsulation is VLAN, MPLS, etc., then I believe one of the >> following must be true: >> >> * The end-to-end path is known to support the resulting larger frames >> * A path discovery mechanism is mandated by SFC when non-IP transports >> are used * An SFC-specific fragmentation header and mechanisms must be >> defined (i.e., >> SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) >> >> Ron >> >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10 >> AM To: mohamed.boucadair@orange.com; Dave Dolson; >> 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: >> 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: >> Re: [sfc] Framework >> >> There is a related complexity. I hope that we expect to support IPv6. >> IPv6 explicitly prohibits network elements from fragmenting end user >> packets. >> >> Yours, Joel >> >> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>> >>> FWIW, one of the existing architecture drafts includes the following >>> behavior >>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6): >>> >>> >>> > " >>> 6. Fragmentation Considerations >>> >>> If adding the Service Chaining Header would result in a fragmented >>> packet, the classifier should include a Service Chaining Header in >>> each fragment. Doing so would prevent SF Nodes to dedicate resource >>> to handle fragments. " >>> >>> Cheers, Med >>> >>> >>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >>>> De la part de Dave Dolson Envoyé : >>>> jeudi 13 février 2014 13:39 À : 'Nicolas.BOUTHORS@qosmos.com'; >>>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com'; >>>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; >>>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>>> >>>> Good point to consider fragmentation. >>>> >>>> We should design the encapsulation such that the forwarding >>>> functions do not need to reassemble. Each fragment should be >>>> independently forwardable; some SFs may choose to ignore these >>>> packets. >>>> >>>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>>> Otherwise, a reassembly layer could be added after the forwarding >>>> coordinates. Think of something like the IPv6 reassembly option >>>> after a GRE header, for instance. >>>> >>>> IP | GRE | reassem | frag data >>>> >>>> We could alternatively mandate the inner IP be fragmented and that >>>> path-MTU discovery be supported. >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- From: Nicolas BOUTHORS >>>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>>> 2014 04:13 AM To: Ron Parker ; >>>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>>> (paulq) Cc: Sumandra Majee ; >>>> sfc@ietf.org ; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> If we do not enforce a fix header size we have other implication. >>>> >>>> There is the question of segmentation and reassembly responsibility >>>> as well. >>>> >>>> If adding length to the service header forces segmentation, then >>>> whose responsibility is it to reassemble the payload before passing >>>> it to the SF. >>>> >>>> Similar question for packet re-ordering. >>>> >>>> >>>> ________________________________________ From: Ron Parker >>>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>> Re: [sfc] Framework >>>> >>>> Dave, >>>> >>>> Yes, that is a good point if we logically separate the forwarding >>>> function from the SFC-aware service function, as we should. The >>>> forwarding function is concerned with only the inbound transport >>>> header, the fixed portion of the service header containing the >>>> chain information, and the outbound transport header. The >>>> service function may look at the entirety of the service header and >>>> would look at the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] >>>> Framework >>>> >>>> The forwarding plane might not even need to look at the encapsulated >>>> packet. >>>> >>>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>>> switch can forward packets of the form: Ether | VLAN | BLOB. >>>> >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>> On Behalf Of Joel M. Halpern Sent: >>>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> I agree as well. Yours, Joel >>>> >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> Hi, Dave. >>>>> >>>>> I Agree with your statement. And if the total length of the >>>>> header is >>>> contained in the mandatory portion, the hardware implementation can >>>> easily locate the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dolson >>>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>>> RE: [sfc] Framework >>>>> >>>>> I think a good approach would be: >>>>> >>>>> The information required for forwarding (the SF Identifier) should >>>>> be in >>>> a mandatory fixed-size header. >>>>> >>>>> Optional information (if any) is NOT to be used for forwarding, but >>>>> is >>>> for consumption by one or more of the applications in the chain. >>>>> >>>>> Then the forwarding plane, and even the PDP, can be agnostic about >>>>> the >>>> meta-data. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of Ron Parker Sent: >>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Paul, >>>>> >>>>> That is why I am proposing a hybrid where extensions or options can >>>>> be >>>> added but the total length is contained in the fixed portion. I >>>> can envision certain deployments (e.g., Enterprise) where perhaps >>>> extensions are not needed and the SFC functionality is realized >>>> in hardware. And, I can envision certain other deployments >>>> (e.g., 3gpp) where the extension headers add sufficient value to >>>> justify software based implementations. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Paul Quinn (paulq) >>>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. >>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>> >>>>> Hi, >>>>> >>>>> We certainly need to be very careful with variable length headers >>>>> when >>>> hardware platform are in play. >>>>> >>>>> Ron, your examples of IP options and v6 EH have both suffered from >>>> significant implementation and deployment hurdles due to the >>>> complexity and cost associated with hardware support for the >>>> option/EH. >>>>> >>>>> Paul >>>>> >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>>> >>>> wrote: >>>>> >>>>>> Hi, Sumandra. >>>>>> >>>>>> Regarding service header flexibility, I completely agree. I >>>>>> might >>>> suggest a compromise between hardware friendliness and software >>>> flexibility. If the header had the ability to add extensions >>>> (perhaps similar to IPv6) but also had the header length encoded in >>>> the mandatory part (like IPv4), then a hardware implementation would >>>> be free to skip over the extensions (in cases where the deployment >>>> justifies ignoring the extensions). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Sumandra Majee >>>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>>> header that is independent of the transport methodology. >>>>>> >>>>>> >>>>>> I agree. However the format of service header should be >>>>>> standardized in >>>> a way that is flexible. Some of us would like to see variable length >>>> header that is also HW friendly. The service header can be >>>> represented as a mandotory fixed length header (like IP >>>> header) along with an optional variable length attribute field. >>>> Different services can be interested in different metadata, for >>>> example subscriber ID could be of interest in the mobile core >>>> service chain only. >>>>>> >>>>>> Sumandra >>>>>> >>>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>>> >>>> wrote: >>>>>> >>>>>>> Linda, >>>>>>> >>>>>>> My interpretation of the architecture docs is that the service >>>>>>> function chain is built in an abstract manner (i.e., SF-A then >>>>>>> SF-B >>>> then SF-C). >>>>>>> Separately, a locator table provides network location for >>>>>>> each of those service functions. In this way, you can >>>>>>> locate the service functions >>>> in >>>>>>> a manner appropriate to the type of transport you are >>>>>>> using. If you want that to be interface+VLAN, >>>>>>> gateway-IP+MPLS label stack, IP >>>> address, >>>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>>> can even potentially locate different service functions that >>>>>>> reside in the same chain with different flavors of >>>>>>> network locators. Another justification to separate the >>>>>>> identity of a service function from its network location is >>>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>>> that would imply load balancing to 3 instances using IP as a >>>>>>> transport layer. >>>>>>> >>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>> header that is independent of the transport >>>>>>> methodology. At a particular node, the decision as to >>>>>>> where to go next should be based solely on information carried in >>>>>>> the canonical service header and not on the >>>> fields >>>>>>> in the transport header. That is, the SFC node discards >>>>>>> the transport header and extracts the chain ID from the >>>>>>> service header. Through mechanisms we have not yet begun >>>>>>> to discuss, the SFC node knows how to interpret the chain ID and >>>>>>> ultimately how to progress the packet. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>> >>>>>>> Agree with Joel's statement. >>>>>>> >>>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>>> Classifier) to emphasize this point. >>>>>>> >>>>>>> "A Service Chain Classifier node can associate a unique Layer 2 >>>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes >>>>>>> along the flow path to steer the flow to the service functions >>>>>>> specified by the flow's service chain." >>>>>>> >>>>>>> >>>>>>> Linda -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>>> >>>>>>> I was looking at the framework proposal. The proposal has a very >>>>>>> specific model of the scope of the transport header (that it is >>>>>>> derived from, and relates only to, the first service function to >>>>>>> which the packet will be directed. That is clearly an operational >>>>>>> model we need to support. >>>>>>> >>>>>>> However, I would like to allow other transport operational >>>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>>> >>>>>>> Yours, Joel M. Halpern >>>>>>> >>>>>>> _______________________________________________ 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 >>>>> >>>>> _______________________________________________ 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 >>> >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > From nobody Thu Feb 13 10:22:41 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104A51A03EE for ; Thu, 13 Feb 2014 10:22:38 -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 f1OAzCRzBBGQ for ; Thu, 13 Feb 2014 10:22:35 -0800 (PST) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0833B1A03B1 for ; Thu, 13 Feb 2014 10:22:34 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB015.mail.lan) by p01c12o147.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 96d0df25.0.12150.00-110.33342.p01c12o147.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 11:22:34 -0700 (MST) X-MXL-Hash: 52fd0d6a7560c4db-e869f3147521df32f4b1f594c9938feee97a29fb Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 13 Feb 2014 13:22:27 -0500 From: Kevin J Ma To: "sfc@ietf.org" Date: Thu, 13 Feb 2014 13:22:25 -0500 Thread-Topic: New Version Notification for draft-ma-sfc-decomposition-01.txt Thread-Index: Ac8o561Bk/UzopikQCuWJNv1lYNAqAAACSmw Message-ID: <291CC3F9E50E7641901A54E85D0977C6D54172F386@MAILR002.mail.lan> References: <20140213181605.23259.38895.idtracker@ietfa.amsl.com> In-Reply-To: <20140213181605.23259.38895.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/s8BfAvmkfJVEKA0MbT7HvwgQx9g Subject: [sfc] FW: New Version Notification for draft-ma-sfc-decomposition-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: Thu, 13 Feb 2014 18:22:38 -0000 SGkgQWxsLA0KDQogIEp1c3QgdXBsb2FkZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBkcmFm dC4NCiAgV2UgYWRkZWQgc29tZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG9uIGhpZXJhcmNoaWNh bCBjaGFpbmluZw0KICBhbmQgZGlyZWN0IHNlcnZpY2UgZnVuY3Rpb24gbm9kZSBhY2Nlc3MgZm9y IG1lc3NhZ2UtYmFzZWQNCiAgaW5ncmVzcyBjbGFzc2lmaWNhdGlvbi4gIEFzIGFsd2F5cywgY29t bWVudHMgd2VsY29tZS4NCg0KdGhhbnguDQoNCi0tIEtldmluIEouIE1hICANCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMs IDIwMTQgMToxNiBQTQ0KVG86IFJvbiBQYXJrZXI7IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IEtl dmluIEogTWENClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWEt c2ZjLWRlY29tcG9zaXRpb24tMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LW1hLXNmYy1kZWNvbXBvc2l0aW9uLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBLZXZpbiBKLiBNYSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtbWEtc2ZjLWRlY29tcG9zaXRpb24NClJldmlzaW9uOgkwMQ0KVGl0bGU6 CQlTRkMgU2VydmljZSBEZWNvbXBvc2l0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTEzDQpH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hLXNmYy1kZWNvbXBv c2l0aW9uLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LW1hLXNmYy1kZWNvbXBvc2l0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hLXNmYy1kZWNvbXBvc2l0aW9uLTAxDQpEaWZm OiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWEtc2Zj LWRlY29tcG9zaXRpb24tMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRpc2N1c3Nl cyB0aGUgcm9sZSBvZiBjb21wb3NpdGUgKG1vbm9saXRoaWMpIHNlcnZpY2UNCiAgIGZ1bmN0aW9u cyBpbiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLCBhbmQgZGVzY3JpYmVzIGEgbWV0aG9kIGZv cg0KICAgc3VwcG9ydGluZyBjb21wb3NpdGUgc2VydmljZSBmdW5jdGlvbiBkZWNvbXBvc2l0aW9u Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Feb 13 10:40:49 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DD71A03AF for ; Thu, 13 Feb 2014 10:40:48 -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 H5WP6sP5jXBP for ; Thu, 13 Feb 2014 10:40:42 -0800 (PST) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D401D1A03BC for ; Thu, 13 Feb 2014 10:40:41 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id p6so8294327vbe.6 for ; Thu, 13 Feb 2014 10:40:40 -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=/o0n1L8MqhIt0UpwjTvbyc0wCT+CRG1rfU3DkcjuFXI=; b=MEuJ0eNvKUVpwEL24fESL8/6wY9LXqkxOrZh0+8CkkwSVgvs4odTsBFXkSrTFZSxKd tiRWaG+jGZWOu9v8k6ycKjPlsz+RnCajEdtITCvEj6hy8CIBaQqxOa7/dEXo8FCczW9T ENrukUehtpyaIld0OPAqGmRcR5bp7wkIE0Zc7oFM9XDe1NtM7WF50Tek8Mz/dHCpkF/g +Ly6ki3PKIECIeZuX/zzZrG6hBINErVrLJBSuvOGhGuvCAgiTrYGLiZ+1qFggojoTKOz aVxkOrB6ZqJsdkkjWnVL/HzOTCYdUWLFmlU0WmBS4M8HfnLqzi1BcY9OfqQ8pj1Ft+h+ Xnkw== MIME-Version: 1.0 X-Received: by 10.220.53.66 with SMTP id l2mr1114772vcg.33.1392316840357; Thu, 13 Feb 2014 10:40:40 -0800 (PST) Received: by 10.58.133.109 with HTTP; Thu, 13 Feb 2014 10:40:40 -0800 (PST) In-Reply-To: References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> <52FD0BE3.7050903@joelhalpern.com> Date: Thu, 13 Feb 2014 13:40:40 -0500 Message-ID: From: Bruno Rijsman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c2b8daaf355904f24e0615 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GS9ZTjmCKncUDG97t5sj5bKUqss Cc: "sfc@ietf.org" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:40:48 -0000 --001a11c2b8daaf355904f24e0615 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable resend to avoid "too many recipients" warning On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman wrot= e: > There are ways to signal variable length amounts of metadata without > needing an additional variable-length header on each data packet. > > draft-rijsman-sfc-metadata-considerations-00 discusses some of the > possible approaches: out-of-band signaling (congruent or non-congruent) o= r > a hybrid approach using a fix-length in-band correlator and out-of-band > additional metadata. See sections 3.3, 3.4 and 3.5 in the draft. > > The issue of fixed-length encoding versus variable length encoding is > discussion in the challenges chapter in section 4.3. I should probably > mention the MTU and segmentation issues as well in that section. > > > On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern wro= te: > >> The variable length shim header is needed even if every individual piece >> of metadata has a fixed length. Different service chains will need >> different combinations of metadata. So the metadata portion of the head= er >> needs to be variable length. >> >> I think the approach of a fixed length initial part, and a variable >> length extension part, is the right model. >> >> Yours, >> Joel >> >> >> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >> >>> Yes, fragmentation and variable headers are usually a really bad thing >>> for forwarding performance. Let's not forget that we live in a 100G-ish >>> kind of world nowadays. >>> >>> Now the question should be: WHY would we want to do that (variable >>> headers leading to fragmentation issues)? >>> >>> For example, the type of metadata that may require variable-length >>> fields might be a better candidate for some out-of-band signaling >>> mechanism. If this is service authorization data (e.g. a service >>> profile/policy), this sounds likely. Not 100% sure this is true for all= use >>> cases though. Only a good understanding of use cases, grounded by >>> reflecting on existing network architectures (notably broadband, fixed = or >>> mobile), would tell us if one approach or another is the most appropria= te. >>> >>> Anyhoo, we're jumping way deep in the detailed protocol design here. >>> This seems a tad premature. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Thursday, February 13, 2014 11:03 AM >>> To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; ' >>> mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; ' >>> paulq@cisco.com' >>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >>> Subject: Re: [sfc] Framework >>> >>> it is overall more efficient to support PMTU discovery rather than >>> fragmenting every large packet. The is why TCP adopted it so early on. >>> >>> The fragmenting also puts huge performance burden on the service >>> functions. >>> Fragmenting may also affect the ability of load balancers to get each >>> fragment to the correct destination. >>> >>> So PMTU discovery SHOULD be used, in my opinion. By this I mean the >>> client or server is informed that its packets are too big (for IPv6 or = IPv4 >>> with DF=3D1). >>> >>> Some operators may wish to incur the extra cost to hide the existence o= f >>> the tunneling, when the elements of the chain can support it, so we cou= ld >>> consider that as an optional mechanism. >>> >>> -Dave >>> >>> >>> ----- Original Message ----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Thursday, February 13, 2014 10:31 AM >>> To: Ron Parker ; >>> mohamed.boucadair@orange.com ; Dave >>> Dolson; 'Nicolas.BOUTHORS@qosmos.com' ; ' >>> paulq@cisco.com' >>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; ' >>> linda.dunbar@huawei.com' >>> Subject: Re: [sfc] Framework >>> >>> I mostly agree with you Ron. I can probably come up with some other >>> variations, but your second point is that the transport must deal with = the >>> issue of frame size / fit. >>> >>> I would note that if we assume that the carrying encaps (IPv4/v6 outer) >>> is being fragmented, then we are assuming that the exit from service >>> chaining can and will reassemble. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>> >>>> Joel, >>>> >>>> That is an excellent point to consider when choosing transport >>>> encapsulations. If the transport encapsulation is IPv4 or IPv6 >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then >>>> fragmentation and defragmentation are naturally supported. If the >>>> transport encapsulation is VLAN, MPLS, etc., then I believe one of the >>>> following must be true: >>>> >>>> * The end-to-end path is known to support the resulting larger frames >>>> * A path discovery mechanism is mandated by SFC when non-IP transports >>>> are used * An SFC-specific fragmentation header and mechanisms must be >>>> defined (i.e., >>>> SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10 >>>> AM To: mohamed.boucadair@orange.com; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: >>>> 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: >>>> Re: [sfc] Framework >>>> >>>> There is a related complexity. I hope that we expect to support IPv6. >>>> IPv6 explicitly prohibits network elements from fragmenting end user >>>> packets. >>>> >>>> Yours, Joel >>>> >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >>>> >>>>> Re-, >>>>> >>>>> FWIW, one of the existing architecture drafts includes the following >>>>> behavior >>>>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-= 6 >>>>> ): >>>>> >>>>> >>>>> >>>>> " >>> >>>> 6. Fragmentation Considerations >>>>> >>>>> If adding the Service Chaining Header would result in a fragmented >>>>> packet, the classifier should include a Service Chaining Header in >>>>> each fragment. Doing so would prevent SF Nodes to dedicate resource >>>>> to handle fragments. " >>>>> >>>>> Cheers, Med >>>>> >>>>> >>>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com'; >>>>>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com'; >>>>>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; >>>>>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>>>>> >>>>>> Good point to consider fragmentation. >>>>>> >>>>>> We should design the encapsulation such that the forwarding >>>>>> functions do not need to reassemble. Each fragment should be >>>>>> independently forwardable; some SFs may choose to ignore these >>>>>> packets. >>>>>> >>>>>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>>>>> Otherwise, a reassembly layer could be added after the forwarding >>>>>> coordinates. Think of something like the IPv6 reassembly option >>>>>> after a GRE header, for instance. >>>>>> >>>>>> IP | GRE | reassem | frag data >>>>>> >>>>>> We could alternatively mandate the inner IP be fragmented and that >>>>>> path-MTU discovery be supported. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: Nicolas BOUTHORS >>>>>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>>>>> 2014 04:13 AM To: Ron Parker ; >>>>>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>>>>> (paulq) Cc: Sumandra Majee ; >>>>>> sfc@ietf.org ; Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> If we do not enforce a fix header size we have other implication. >>>>>> >>>>>> There is the question of segmentation and reassembly responsibility >>>>>> as well. >>>>>> >>>>>> If adding length to the service header forces segmentation, then >>>>>> whose responsibility is it to reassemble the payload before passing >>>>>> it to the SF. >>>>>> >>>>>> Similar question for packet re-ordering. >>>>>> >>>>>> >>>>>> ________________________________________ From: Ron Parker >>>>>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> Dave, >>>>>> >>>>>> Yes, that is a good point if we logically separate the forwarding >>>>>> function from the SFC-aware service function, as we should. The >>>>>> forwarding function is concerned with only the inbound transport >>>>>> header, the fixed portion of the service header containing the >>>>>> chain information, and the outbound transport header. The >>>>>> service function may look at the entirety of the service header and >>>>>> would look at the encapsulated packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Dave Dolson >>>>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>>>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] >>>>>> Framework >>>>>> >>>>>> The forwarding plane might not even need to look at the encapsulated >>>>>> packet. >>>>>> >>>>>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>>>>> switch can forward packets of the form: Ether | VLAN | BLOB. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I agree as well. Yours, Joel >>>>>> >>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>> >>>>>>> Hi, Dave. >>>>>>> >>>>>>> I Agree with your statement. And if the total length of the >>>>>>> header is >>>>>>> >>>>>> contained in the mandatory portion, the hardware implementation can >>>>>> easily locate the encapsulated packet. >>>>>> >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: Dave Dolson >>>>>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>>>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>>>>> RE: [sfc] Framework >>>>>>> >>>>>>> I think a good approach would be: >>>>>>> >>>>>>> The information required for forwarding (the SF Identifier) should >>>>>>> be in >>>>>>> >>>>>> a mandatory fixed-size header. >>>>>> >>>>>>> >>>>>>> Optional information (if any) is NOT to be used for forwarding, but >>>>>>> is >>>>>>> >>>>>> for consumption by one or more of the applications in the chain. >>>>>> >>>>>>> >>>>>>> Then the forwarding plane, and even the PDP, can be agnostic about >>>>>>> the >>>>>>> >>>>>> meta-data. >>>>>> >>>>>>> >>>>>>> -Dave >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>>>> On Behalf Of Ron Parker Sent: >>>>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>>>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>>>>> Subject: Re: [sfc] Framework >>>>>>> >>>>>>> Paul, >>>>>>> >>>>>>> That is why I am proposing a hybrid where extensions or options can >>>>>>> be >>>>>>> >>>>>> added but the total length is contained in the fixed portion. I >>>>>> can envision certain deployments (e.g., Enterprise) where perhaps >>>>>> extensions are not needed and the SFC functionality is realized >>>>>> in hardware. And, I can envision certain other deployments >>>>>> (e.g., 3gpp) where the extension headers add sufficient value to >>>>>> justify software based implementations. >>>>>> >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: Paul Quinn (paulq) >>>>>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. >>>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We certainly need to be very careful with variable length headers >>>>>>> when >>>>>>> >>>>>> hardware platform are in play. >>>>>> >>>>>>> >>>>>>> Ron, your examples of IP options and v6 EH have both suffered from >>>>>>> >>>>>> significant implementation and deployment hurdles due to the >>>>>> complexity and cost associated with hardware support for the >>>>>> option/EH. >>>>>> >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>>>>> >>>>>>> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Hi, Sumandra. >>>>>>>> >>>>>>>> Regarding service header flexibility, I completely agree. I >>>>>>>> might >>>>>>>> >>>>>>> suggest a compromise between hardware friendliness and software >>>>>> flexibility. If the header had the ability to add extensions >>>>>> (perhaps similar to IPv6) but also had the header length encoded in >>>>>> the mandatory part (like IPv4), then a hardware implementation would >>>>>> be free to skip over the extensions (in cases where the deployment >>>>>> justifies ignoring the extensions). >>>>>> >>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>>> >>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>>>>> header that is independent of the transport methodology. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I agree. However the format of service header should be >>>>>>>> standardized in >>>>>>>> >>>>>>> a way that is flexible. Some of us would like to see variable lengt= h >>>>>> header that is also HW friendly. The service header can be >>>>>> represented as a mandotory fixed length header (like IP >>>>>> header) along with an optional variable length attribute field. >>>>>> Different services can be interested in different metadata, for >>>>>> example subscriber ID could be of interest in the mobile core >>>>>> service chain only. >>>>>> >>>>>>> >>>>>>>> Sumandra >>>>>>>> >>>>>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>>>>> >>>>>>>> >>>>>>> wrote: >>>>>> >>>>>>> >>>>>>>> Linda, >>>>>>>>> >>>>>>>>> My interpretation of the architecture docs is that the service >>>>>>>>> function chain is built in an abstract manner (i.e., SF-A then >>>>>>>>> SF-B >>>>>>>>> >>>>>>>> then SF-C). >>>>>> >>>>>>> Separately, a locator table provides network location for >>>>>>>>> each of those service functions. In this way, you can >>>>>>>>> locate the service functions >>>>>>>>> >>>>>>>> in >>>>>> >>>>>>> a manner appropriate to the type of transport you are >>>>>>>>> using. If you want that to be interface+VLAN, >>>>>>>>> gateway-IP+MPLS label stack, IP >>>>>>>>> >>>>>>>> address, >>>>>> >>>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>>>>> can even potentially locate different service functions that >>>>>>>>> reside in the same chain with different flavors of >>>>>>>>> network locators. Another justification to separate the >>>>>>>>> identity of a service function from its network location is >>>>>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>>>>> that would imply load balancing to 3 instances using IP as a >>>>>>>>> transport layer. >>>>>>>>> >>>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>>>> header that is independent of the transport >>>>>>>>> methodology. At a particular node, the decision as to >>>>>>>>> where to go next should be based solely on information carried in >>>>>>>>> the canonical service header and not on the >>>>>>>>> >>>>>>>> fields >>>>>> >>>>>>> in the transport header. That is, the SFC node discards >>>>>>>>> the transport header and extracts the chain ID from the >>>>>>>>> service header. Through mechanisms we have not yet begun >>>>>>>>> to discuss, the SFC node knows how to interpret the chain ID and >>>>>>>>> ultimately how to progress the packet. >>>>>>>>> >>>>>>>>> Ron >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>>>> >>>>>>>>> Agree with Joel's statement. >>>>>>>>> >>>>>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>>>>> Classifier) to emphasize this point. >>>>>>>>> >>>>>>>>> "A Service Chain Classifier node can associate a unique Layer 2 >>>>>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes >>>>>>>>> along the flow path to steer the flow to the service functions >>>>>>>>> specified by the flow's service chain." >>>>>>>>> >>>>>>>>> >>>>>>>>> Linda -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>>>>> >>>>>>>>> I was looking at the framework proposal. The proposal has a very >>>>>>>>> specific model of the scope of the transport header (that it is >>>>>>>>> derived from, and relates only to, the first service function to >>>>>>>>> which the packet will be directed. That is clearly an operational >>>>>>>>> model we need to support. >>>>>>>>> >>>>>>>>> However, I would like to allow other transport operational >>>>>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>>>>> >>>>>>>>> Yours, Joel M. Halpern >>>>>>>>> >>>>>>>>> _______________________________________________ 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 >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ 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 >>>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> 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 >> > > --001a11c2b8daaf355904f24e0615 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
resend to avoid "too many recipients" warning


On Thu, Feb = 13, 2014 at 1:39 PM, Bruno Rijsman <brunorijsman@gmail.com> wrote:
There are ways to signal va= riable length amounts of metadata without needing an additional variable-le= ngth header on each data packet.

draft-rijsman-sfc-metadata-considerations-00 discusses some = of the possible approaches: out-of-band signaling (congruent or non-congrue= nt) or a hybrid approach using a fix-length in-band correlator and out-of-b= and additional metadata. =A0See sections 3.3, 3.4 and 3.5 in the draft. =A0=

The issue of fixed-length encoding versus variabl= e length encoding is discussion in the challenges chapter in section 4.3. = =A0I should probably mention the MTU and segmentation issues as well in tha= t section.

On Thu, Feb 13, 2014 at 1:16 PM, Joel M. H= alpern <jmh@joelhalpern.com> wrote:
The variable length shim header is needed ev= en if every individual piece of metadata has a fixed length. =A0Different s= ervice chains will need different combinations of metadata. =A0So the metad= ata portion of the header needs to be variable length.

I think the approach of a fixed length initial part, and a variable length = extension part, is the right model.

Yours,
Joel


On 2/13/14, 11:13 AM, Jerome Moisand wrote:
Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kin= d of world nowadays.

Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)?

For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate.

Anyhoo, we're jumping way deep in the detailed protocol design here. Th= is seems a tad premature.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: 'jmh@joelh= alpern.com'; 'Ron_Parker@affirmednetworks.com'; '<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; '<= a href=3D"mailto:paulq@cisco.com" target=3D"_blank">paulq@cisco.com'= ;
Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Subject: Re: [sfc] Framework

it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.

The fragmenting also puts huge performance burden on the service functions.=
Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination.

So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).

Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.

-Dave


----- Original Message -----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>; mohamed.boucadair@orang= e.com <mohamed.boucadair@orange.com>; Dave Dolson; 'Nicolas.BOUTHORS@= qosmos.com' <Nicolas.BOUTHORS@qosmos.com>; 'paulq@cisco.com' <paulq@cisco.com>
Cc: 'S.Majee@F5.com' <S.Majee@F5.com>; 'sfc@ietf.org' <sfc@ietf.org>; 'linda.dunbar@huawei.com&= #39; <linda= .dunbar@huawei.com>
Subject: Re: [sfc] Framework

I mostly agree with you Ron. =A0I can probably come up with some other vari= ations, but your second point is that the transport must deal with the issu= e of frame size / fit.

I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble.

Yours,
Joel

On 2/13/14, 10:18 AM, Ron Parker wrote:
Joel,

That is an excellent point to consider when choosing transport
encapsulations. =A0 If the transport encapsulation is IPv4 or IPv6
based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then
fragmentation and defragmentation are naturally supported. =A0 =A0If the transport encapsulation is VLAN, MPLS, etc., then I believe one of the
following must be true:

* The end-to-end path is known to support the resulting larger frames
* A path discovery mechanism is mandated by SFC when non-IP transports
are used * An SFC-specific fragmentation header and mechanisms must be
defined (i.e.,
SFC-transport/SFC-fragmentation/SFC-service/original-packet-o= r-frame)

=A0 Ron


-----Original Message----- From: Joel M. Halpern
[mailto:jmh@joelha= lpern.com] Sent: Thursday, February 13, 2014 10:10
AM To: mo= hamed.boucadair@orange.com; Dave Dolson;
'Nicol= as.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc:
'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject:
Re: [sfc] Framework

There is a related complexity. I hope that we expect to support IPv6.
IPv6 explicitly prohibits network elements from fragmenting end user
packets.

Yours, Joel

On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote:
Re-,

FWIW, one of the existing architecture drafts includes the following
behavior
(http://tools.ietf.org/html/draft-boucadair= -sfc-framework-02#section-6):



"
6. Fragmentation Considerations

If adding the Service Chaining Header would result in a fragmented
packet, the classifier should include a Service Chaining Header in
each fragment. =A0Doing so would prevent SF Nodes to dedicate resource
to handle fragments. "

Cheers, Med


-----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]
De la part de Dave Dolson Envoy=E9 :
jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';
'R= on_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';
'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';
'linda.dun= bar@huawei.com' Objet : Re: [sfc] Framework

Good point to consider fragmentation.

We should design the encapsulation such that the forwarding
functions do not need to reassemble. Each fragment should be
independently forwardable; some SFs may choose to ignore these
packets.

Any layer 2.5 protocol like VLAN or MPLS would support this.
Otherwise, a reassembly layer could be added after the forwarding
coordinates. Think of something like the IPv6 reassembly option
after a GRE header, for instance.

IP | GRE | reassem | frag data

We could alternatively mandate the inner IP be fragmented and that
path-MTU discovery be supported.




----- Original Message ----- From: Nicolas BOUTHORS
[mailto:Ni= colas.BOUTHORS@qosmos.com] Sent: Thursday, February 13,
2014 04:13 AM To: Ron Parker <Ron_Parker@affirmednetworks.com>;<= br> Dave Dolson; Joel M. Halpern <jmh@joelhalpern.com>; Paul Quinn
(paulq) <paulq@cisc= o.com> Cc: Sumandra Majee <S.Majee@F5.com>;
sfc@ietf.org <sfc@ietf.org>; Linda D= unbar <lind= a.dunbar@huawei.com>
Subject: Re: [sfc] Framework

If we do not enforce a fix header size we have other implication.

There is the question of segmentation and reassembly responsibility
as well.

If adding length to the service header forces segmentation, then
whose responsibility is it to reassemble the payload before passing
it to the SF.

Similar question for packet re-ordering.


________________________________________ From: Ron Parker
[Ron_P= arker@affirmednetworks.com] Sent: Wednesday, February 12,
2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn
(paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject:
Re: [sfc] Framework

Dave,

Yes, that is a good point if we logically separate the forwarding
function from the SFC-aware service function, as we should. =A0 The
forwarding function is concerned with only the inbound transport
header, the fixed =A0portion of the service header containing the
chain information, and the outbound transport header. =A0 =A0The
service function may look at the entirety of the service header and
would look at the encapsulated packet.

Ron


-----Original Message----- From: Dave Dolson
[mailto:ddolson@s= andvine.com] Sent: Wednesday, February 12, 2014
5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc:
Sumandra Majee; sfc@ietf.= org; Linda Dunbar Subject: RE: [sfc]
Framework

The forwarding plane might not even need to look at the encapsulated
packet.

For example, (if the SF Identifier is a VLAN tag), an Ethernet
switch can forward packets of the form: =A0Ether | VLAN | BLOB.



-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Joel M. Halpern Sent:
Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;
Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well. Yours, Joel

On 2/12/14, 4:24 PM, Ron Parker wrote:
Hi, Dave.

I =A0Agree with your statement. =A0 =A0And if the total length of the
header is
contained in the mandatory portion, the hardware implementation can
easily locate the encapsulated packet.

Ron


-----Original Message----- From: Dave Dolson
[mailto:ddolson@s= andvine.com] Sent: Wednesday, February 12,
2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M.
Halpern; Sumandra Majee; = sfc@ietf.org; Linda Dunbar Subject:
RE: [sfc] Framework

I think a good approach would be:

The information required for forwarding (the SF Identifier) should
be in
a mandatory fixed-size header.

Optional information (if any) is NOT to be used for forwarding, but
is
for consumption by one or more of the applications in the chain.

Then the forwarding plane, and even the PDP, can be agnostic about
the
meta-data.

-Dave


-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Ron Parker Sent:
Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc:
Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc] Framework

Paul,

That is why I am proposing a hybrid where extensions or options can
be
added but the total length is contained in the fixed portion. =A0 I
can envision certain deployments (e.g., Enterprise) where perhaps
extensions are not needed and the SFC functionality is realized
in hardware. =A0 And, I can envision certain other deployments
(e.g., 3gpp) where the extension headers add sufficient value to
justify software based implementations.

Ron


-----Original Message----- From: Paul Quinn (paulq)
[mailto:paulq@cisco.co= m] Sent: Wednesday, February 12, 2014
3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.
Halpern; sfc@ietf.org= Subject: Re: [sfc] Framework

Hi,

We certainly need to be very careful with variable length headers
when
hardware platform are in play.

Ron, your examples of IP options and v6 EH have both suffered from
significant implementation and deployment hurdles due to the
complexity and cost associated with hardware support for the
option/EH.

Paul

On Feb 12, 2014, at 3:10 PM, Ron Parker
<Ro= n_Parker@affirmednetworks.com>
wrote:

Hi, Sumandra.

Regarding service header flexibility, I completely agree. =A0 I
might
suggest a compromise between hardware friendliness and software
flexibility. =A0 =A0If the header had the ability to add extensions
(perhaps similar to IPv6) but also had the header length encoded in
the mandatory part (like IPv4), then a hardware implementation would
be free to skip over the extensions (in cases where the deployment
justifies ignoring the extensions).

Ron


-----Original Message----- From: Sumandra Majee
[mailto:S.Majee@F5.com<= /a>] Sent: Wednesday, February 12, 2014
3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;
sfc@ietf.org Subject:= Re: [sfc] Framework

For all of those reasons, I strongly support a canonical service
header that is independent of the transport methodology.


I agree. However the format of service header should be
standardized in
a way that is flexible. Some of us would like to see variable length
header that is also HW friendly. The service header can be
represented as a mandotory fixed length header (like IP
header) along with an optional variable length attribute field.
Different services can be interested in different metadata, for
example subscriber ID could be of interest in the mobile core
service chain only.

Sumandra

On 2/12/14, 11:32 AM, "Ron Parker"
<Ro= n_Parker@affirmednetworks.com>
wrote:

Linda,

My interpretation of the architecture docs is that the service
function chain is built in an abstract manner (i.e., SF-A then
SF-B
then SF-C).
Separately, a locator table provides network location for
each of those service functions. =A0 In this way, you can
locate the service functions
in
a manner appropriate to the type of transport you are
using. =A0 If you want that to be interface+VLAN,
gateway-IP+MPLS label stack, IP
address,
GRE tunnel remote IP + key, etc., you can do that. =A0 =A0You
can even potentially locate different service functions that
reside in the same chain with different flavors of
network locators. =A0 =A0Another justification to separate the
identity of a service function from its network location is
load balancing. =A0 If, for example, SF-A had 3 IP addresses,
that would imply load balancing to 3 instances using IP as a
transport layer.

For all of those reasons, I strongly support a canonical service
header that is independent of the transport
methodology. =A0 =A0At a particular node, the decision as to
where to go next should be based solely on information carried in
the canonical service header and not on the
fields
in the transport header. =A0 That is, the SFC node discards
the transport header and extracts the chain ID from the
service header. =A0 =A0Through mechanisms we have not yet begun
to discuss, the SFC node knows how to interpret the chain ID and
ultimately how to progress the packet.

Ron


-----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M.
Halpern; sfc@ietf.org= Subject: Re: [sfc] Framework

Agree with Joel's statement.

I think a simple sentence below should be added Section 5.2 (SFC
Classifier) to emphasize this point.

"A Service Chain Classifier node can associate a unique Layer 2
or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow.
Those Layer 2 or 3 Label makes it easier for subsequent nodes
along the flow path to steer the flow to the service functions
specified by the flow's service chain."


Linda -----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 10:20 AM To:
sfc@ietf.org Subject:= [sfc] Framework

I was looking at the framework proposal. The proposal has a very
specific model of the scope of the transport header (that it is
derived from, and relates only to, the first service function to
which the packet will be directed. That is clearly an operational
model we need to support.

However, I would like to allow other transport operational
models, such as the use of a VLAN to direct traffic along a
chain. =A0Or the use of an MPLS label, or an MPLS label stack.

Yours, Joel M. Halpern

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc


_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc



_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc



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





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


--001a11c2b8daaf355904f24e0615-- From nobody Thu Feb 13 11:15:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C81A03FA for ; Thu, 13 Feb 2014 11:15:10 -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 ITNJPXl8zm9n for ; Thu, 13 Feb 2014 11:15:05 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7858E1A03C3 for ; Thu, 13 Feb 2014 11:15:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 94D403E0473; Thu, 13 Feb 2014 11:15:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CFE253E0471; Thu, 13 Feb 2014 11:15:01 -0800 (PST) Message-ID: <52FD19BC.3060607@joelhalpern.com> Date: Thu, 13 Feb 2014 14:15:08 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bruno Rijsman References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> <52FD0BE3.7050903@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KxrJQsIngbLdBkZ3aFgdbAKj-VE Cc: "sfc@ietf.org" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:15:10 -0000 While there are cases where out-of-band metadata makes sense, There are many cases I would not want to try to cover that way. The best examples are situations where the metadata changes from packet to packet (such as the data produced by a DPI engine for consumption by other applications in the chain.) More importantly, if you are putting correlators in the packet, it is still very complex if you want to use one correlator to handle metadata produced by several different entities (the initial classifer, the DPI engine, ...) You quickly end up deciding that you need several correlators. At which point we are back to variable amounts of metadata. The alternative is to require exceedingly specific and strong coupling to a mandated out-of-band mechanism. That seems to me to be a very bad idea. Yours, Joel On 2/13/14, 1:40 PM, Bruno Rijsman wrote: > resend to avoid "too many recipients" warning > > > On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman > wrote: > > There are ways to signal variable length amounts of metadata without > needing an additional variable-length header on each data packet. > > draft-rijsman-sfc-metadata-considerations-00 discusses some of the > possible approaches: out-of-band signaling (congruent or > non-congruent) or a hybrid approach using a fix-length in-band > correlator and out-of-band additional metadata. See sections 3.3, > 3.4 and 3.5 in the draft. > > The issue of fixed-length encoding versus variable length encoding > is discussion in the challenges chapter in section 4.3. I should > probably mention the MTU and segmentation issues as well in that > section. > > > On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern > > wrote: > > The variable length shim header is needed even if every > individual piece of metadata has a fixed length. Different > service chains will need different combinations of metadata. So > the metadata portion of the header needs to be variable length. > > I think the approach of a fixed length initial part, and a > variable length extension part, is the right model. > > Yours, > Joel > > > On 2/13/14, 11:13 AM, Jerome Moisand wrote: > > Yes, fragmentation and variable headers are usually a really > bad thing for forwarding performance. Let's not forget that > we live in a 100G-ish kind of world nowadays. > > Now the question should be: WHY would we want to do that > (variable headers leading to fragmentation issues)? > > For example, the type of metadata that may require > variable-length fields might be a better candidate for some > out-of-band signaling mechanism. If this is service > authorization data (e.g. a service profile/policy), this > sounds likely. Not 100% sure this is true for all use cases > though. Only a good understanding of use cases, grounded by > reflecting on existing network architectures (notably > broadband, fixed or mobile), would tell us if one approach > or another is the most appropriate. > > Anyhoo, we're jumping way deep in the detailed protocol > design here. This seems a tad premature. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org > ] On Behalf Of Dave Dolson > Sent: Thursday, February 13, 2014 11:03 AM > To: 'jmh@joelhalpern.com '; > 'Ron_Parker@affirmednetworks.__com > '; > 'mohamed.boucadair@orange.com > '__; > 'Nicolas.BOUTHORS@qosmos.com > '; 'paulq@cisco.com > ' > Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; > 'linda.dunbar@huawei.com ' > Subject: Re: [sfc] Framework > > it is overall more efficient to support PMTU discovery > rather than fragmenting every large packet. The is why TCP > adopted it so early on. > > The fragmenting also puts huge performance burden on the > service functions. > Fragmenting may also affect the ability of load balancers to > get each fragment to the correct destination. > > So PMTU discovery SHOULD be used, in my opinion. By this I > mean the client or server is informed that its packets are > too big (for IPv6 or IPv4 with DF=1). > > Some operators may wish to incur the extra cost to hide the > existence of the tunneling, when the elements of the chain > can support it, so we could consider that as an optional > mechanism. > > -Dave > > > ----- Original Message ----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com > ] > Sent: Thursday, February 13, 2014 10:31 AM > To: Ron Parker >; > mohamed.boucadair@orange.com > > >__; Dave Dolson; > 'Nicolas.BOUTHORS@qosmos.com > ' > >; 'paulq@cisco.com > ' > > Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org > ' >; > 'linda.dunbar@huawei.com ' > > > Subject: Re: [sfc] Framework > > I mostly agree with you Ron. I can probably come up with > some other variations, but your second point is that the > transport must deal with the issue of frame size / fit. > > I would note that if we assume that the carrying encaps > (IPv4/v6 outer) is being fragmented, then we are assuming > that the exit from service chaining can and will reassemble. > > Yours, > Joel > > On 2/13/14, 10:18 AM, Ron Parker wrote: > > Joel, > > That is an excellent point to consider when choosing > transport > encapsulations. If the transport encapsulation is IPv4 > or IPv6 > based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then > fragmentation and defragmentation are naturally > supported. If the > transport encapsulation is VLAN, MPLS, etc., then I > believe one of the > following must be true: > > * The end-to-end path is known to support the resulting > larger frames > * A path discovery mechanism is mandated by SFC when > non-IP transports > are used * An SFC-specific fragmentation header and > mechanisms must be > defined (i.e., > SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-frame) > > Ron > > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com > ] Sent: Thursday, February > 13, 2014 10:10 > AM To: mohamed.boucadair@orange.com > ; Dave Dolson; > 'Nicolas.BOUTHORS@qosmos.com > '; Ron Parker; > 'paulq@cisco.com ' Cc: > 'S.Majee@F5.com'; 'sfc@ietf.org '; > 'linda.dunbar@huawei.com > ' Subject: > Re: [sfc] Framework > > There is a related complexity. I hope that we expect to > support IPv6. > IPv6 explicitly prohibits network elements from > fragmenting end user > packets. > > Yours, Joel > > On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com > wrote: > > Re-, > > FWIW, one of the existing architecture drafts > includes the following > behavior > (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#section-6 > ): > > > > " > > 6. Fragmentation Considerations > > If adding the Service Chaining Header would result > in a fragmented > packet, the classifier should include a Service > Chaining Header in > each fragment. Doing so would prevent SF Nodes to > dedicate resource > to handle fragments. " > > Cheers, Med > > > -----Message d'origine----- De : sfc > [mailto:sfc-bounces@ietf.org > ] > De la part de Dave Dolson Envoyé : > jeudi 13 février 2014 13:39 À : > 'Nicolas.BOUTHORS@qosmos.com > '; > 'Ron_Parker@affirmednetworks.__com > '; > 'jmh@joelhalpern.com '; > 'paulq@cisco.com ' Cc : > 'S.Majee@F5.com'; 'sfc@ietf.org > '; > 'linda.dunbar@huawei.com > ' Objet : Re: > [sfc] Framework > > Good point to consider fragmentation. > > We should design the encapsulation such that the > forwarding > functions do not need to reassemble. Each > fragment should be > independently forwardable; some SFs may choose > to ignore these > packets. > > Any layer 2.5 protocol like VLAN or MPLS would > support this. > Otherwise, a reassembly layer could be added > after the forwarding > coordinates. Think of something like the IPv6 > reassembly option > after a GRE header, for instance. > > IP | GRE | reassem | frag data > > We could alternatively mandate the inner IP be > fragmented and that > path-MTU discovery be supported. > > > > > ----- Original Message ----- From: Nicolas BOUTHORS > [mailto:Nicolas.BOUTHORS@__qosmos.com > ] Sent: > Thursday, February 13, > 2014 04:13 AM To: Ron Parker > >; > Dave Dolson; Joel M. Halpern > >; Paul Quinn > (paulq) > Cc: Sumandra Majee > ; > sfc@ietf.org >; Linda Dunbar > > > Subject: Re: [sfc] Framework > > If we do not enforce a fix header size we have > other implication. > > There is the question of segmentation and > reassembly responsibility > as well. > > If adding length to the service header forces > segmentation, then > whose responsibility is it to reassemble the > payload before passing > it to the SF. > > Similar question for packet re-ordering. > > > __________________________________________ From: > Ron Parker > [Ron_Parker@affirmednetworks.__com > ] Sent: > Wednesday, February 12, > 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; > Paul Quinn > (paulq) Cc: Sumandra Majee; sfc@ietf.org > ; Linda Dunbar Subject: > Re: [sfc] Framework > > Dave, > > Yes, that is a good point if we logically > separate the forwarding > function from the SFC-aware service function, as > we should. The > forwarding function is concerned with only the > inbound transport > header, the fixed portion of the service header > containing the > chain information, and the outbound transport > header. The > service function may look at the entirety of the > service header and > would look at the encapsulated packet. > > Ron > > > -----Original Message----- From: Dave Dolson > [mailto:ddolson@sandvine.com > ] Sent: Wednesday, > February 12, 2014 > 5:18 PM To: Joel M. Halpern; Ron Parker; Paul > Quinn (paulq) Cc: > Sumandra Majee; sfc@ietf.org > ; Linda Dunbar Subject: RE: > [sfc] > Framework > > The forwarding plane might not even need to look > at the encapsulated > packet. > > For example, (if the SF Identifier is a VLAN > tag), an Ethernet > switch can forward packets of the form: Ether | > VLAN | BLOB. > > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] > On Behalf Of Joel M. Halpern Sent: > Wednesday, February 12, 2014 4:30 PM To: Ron > Parker; Dave Dolson; > Paul Quinn (paulq) Cc: Sumandra Majee; > sfc@ietf.org ; Linda Dunbar > Subject: Re: [sfc] Framework > > I agree as well. Yours, Joel > > On 2/12/14, 4:24 PM, Ron Parker wrote: > > Hi, Dave. > > I Agree with your statement. And if the > total length of the > header is > > contained in the mandatory portion, the hardware > implementation can > easily locate the encapsulated packet. > > > Ron > > > -----Original Message----- From: Dave Dolson > [mailto:ddolson@sandvine.com > ] Sent: > Wednesday, February 12, > 2014 4:10 PM To: Ron Parker; Paul Quinn > (paulq) Cc: Joel M. > Halpern; Sumandra Majee; sfc@ietf.org > ; Linda Dunbar Subject: > RE: [sfc] Framework > > I think a good approach would be: > > The information required for forwarding (the > SF Identifier) should > be in > > a mandatory fixed-size header. > > > Optional information (if any) is NOT to be > used for forwarding, but > is > > for consumption by one or more of the > applications in the chain. > > > Then the forwarding plane, and even the PDP, > can be agnostic about > the > > meta-data. > > > -Dave > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] > On Behalf Of Ron Parker Sent: > Wednesday, February 12, 2014 4:05 PM To: > Paul Quinn (paulq) Cc: > Joel M. Halpern; Sumandra Majee; > sfc@ietf.org ; Linda Dunbar > Subject: Re: [sfc] Framework > > Paul, > > That is why I am proposing a hybrid where > extensions or options can > be > > added but the total length is contained in the > fixed portion. I > can envision certain deployments (e.g., > Enterprise) where perhaps > extensions are not needed and the SFC > functionality is realized > in hardware. And, I can envision certain other > deployments > (e.g., 3gpp) where the extension headers add > sufficient value to > justify software based implementations. > > > Ron > > > -----Original Message----- From: Paul Quinn > (paulq) > [mailto:paulq@cisco.com > ] Sent: Wednesday, > February 12, 2014 > 3:40 PM To: Ron Parker Cc: Sumandra Majee; > Linda Dunbar; Joel M. > Halpern; sfc@ietf.org > Subject: Re: [sfc] Framework > > Hi, > > We certainly need to be very careful with > variable length headers > when > > hardware platform are in play. > > > Ron, your examples of IP options and v6 EH > have both suffered from > > significant implementation and deployment > hurdles due to the > complexity and cost associated with hardware > support for the > option/EH. > > > Paul > > On Feb 12, 2014, at 3:10 PM, Ron Parker > > > > wrote: > > > Hi, Sumandra. > > Regarding service header flexibility, I > completely agree. I > might > > suggest a compromise between hardware > friendliness and software > flexibility. If the header had the ability to > add extensions > (perhaps similar to IPv6) but also had the > header length encoded in > the mandatory part (like IPv4), then a hardware > implementation would > be free to skip over the extensions (in cases > where the deployment > justifies ignoring the extensions). > > > Ron > > > -----Original Message----- From: > Sumandra Majee > [mailto:S.Majee@F5.com > ] Sent: > Wednesday, February 12, 2014 > 3:04 PM To: Ron Parker; Linda Dunbar; > Joel M. Halpern; > sfc@ietf.org > Subject: Re: [sfc] Framework > > For all of those reasons, I > strongly support a canonical service > header that is independent of > the transport methodology. > > > > I agree. However the format of service > header should be > standardized in > > a way that is flexible. Some of us would like to > see variable length > header that is also HW friendly. The service > header can be > represented as a mandotory fixed length header > (like IP > header) along with an optional variable length > attribute field. > Different services can be interested in > different metadata, for > example subscriber ID could be of interest in > the mobile core > service chain only. > > > Sumandra > > On 2/12/14, 11:32 AM, "Ron Parker" > > > > wrote: > > > Linda, > > My interpretation of the > architecture docs is that the service > function chain is built in an > abstract manner (i.e., SF-A then > SF-B > > then SF-C). > > Separately, a locator table provides > network location for > each of those service functions. > In this way, you can > locate the service functions > > in > > a manner appropriate to the type of > transport you are > using. If you want that to be > interface+VLAN, > gateway-IP+MPLS label stack, IP > > address, > > GRE tunnel remote IP + key, etc., > you can do that. You > can even potentially locate > different service functions that > reside in the same chain with > different flavors of > network locators. Another > justification to separate the > identity of a service function from > its network location is > load balancing. If, for example, > SF-A had 3 IP addresses, > that would imply load balancing to 3 > instances using IP as a > transport layer. > > For all of those reasons, I strongly > support a canonical service > header that is independent of the > transport > methodology. At a particular > node, the decision as to > where to go next should be based > solely on information carried in > the canonical service header and not > on the > > fields > > in the transport header. That is, > the SFC node discards > the transport header and extracts > the chain ID from the > service header. Through > mechanisms we have not yet begun > to discuss, the SFC node knows how > to interpret the chain ID and > ultimately how to progress the packet. > > Ron > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] On > Behalf Of Linda Dunbar > Sent: Wednesday, February 12, 2014 > 12:01 PM To: Joel M. > Halpern; sfc@ietf.org > Subject: Re: > [sfc] Framework > > Agree with Joel's statement. > > I think a simple sentence below > should be added Section 5.2 (SFC > Classifier) to emphasize this point. > > "A Service Chain Classifier node can > associate a unique Layer 2 > or 3 Label (e.g. VLAN, MPLS label) > to the packets in the flow. > Those Layer 2 or 3 Label makes it > easier for subsequent nodes > along the flow path to steer the > flow to the service functions > specified by the flow's service chain." > > > Linda -----Original Message----- > From: sfc > [mailto:sfc-bounces@ietf.org > ] On > Behalf Of Joel M. Halpern > Sent: Wednesday, February 12, 2014 > 10:20 AM To: > sfc@ietf.org > Subject: [sfc] Framework > > I was looking at the framework > proposal. The proposal has a very > specific model of the scope of the > transport header (that it is > derived from, and relates only to, > the first service function to > which the packet will be directed. > That is clearly an operational > model we need to support. > > However, I would like to allow other > transport operational > models, such as the use of a VLAN to > direct traffic along a > chain. Or the use of an MPLS label, > or an MPLS label stack. > > Yours, Joel M. Halpern > > _________________________________________________ > 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 > > > > _________________________________________________ > 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 > > > > > > _________________________________________________ > 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 Feb 13 11:23:07 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8A1A0414 for ; Thu, 13 Feb 2014 11:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NliXRpBJfdH0 for ; Thu, 13 Feb 2014 11:23:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3B80E1A0350 for ; Thu, 13 Feb 2014 11:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36629; q=dns/txt; s=iport; t=1392319367; x=1393528967; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sOWSQQ7H5j0dZXh0wsL/WAxNoEe75RBvldf+mpTXQhA=; b=kgFOjqrnPR+b/IWQq8viNdOSz+Id1uRY/K9Oi6VcHKgJnsX+CFh02LQ7 +46TjA2PZLiQ3ncdRzIlV1jLNqumBBGf168f4o7CEX5zmwaVm9YJV+Epq wf2D1EyAixJvENkEp4qjaA6TrxAfVf9eQ0NxSDFgwpXm4OIaY/YvPk6We g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHka/VKtJV2c/2dsb2JhbABQCYMGOFe/ToEZFnSCJQEBAQMBAQEBF0sCBwsMBgEIEQEDAQEBJygGCxQDBggCBAENBYdxAwkIDb8bDYg8F4xfgT8wKwcCBIQyBIkQjTCBbIEyiyyFRYMtgio X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="303877871" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 19:22:46 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DJMkkN022237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 19:22:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 13:22:45 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , Bruno Rijsman Thread-Topic: [sfc] Framework Thread-Index: AQHPKOsjqfPMMzky7EWt5S69NDqHNJqz8o8A//98BAA= Date: Thu, 13 Feb 2014 19:22:44 +0000 Message-ID: In-Reply-To: <52FD19BC.3060607@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.125.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <131BC86364B48743B798807380776F87@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6wyzfxfCyR0qMio88ycg-5WRWiA Cc: "sfc@ietf.org" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:23:06 -0000 There is draft about transport independent metadata. http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01 The complexities you mention are discussed there: variable-encoding, direction, security of metadata, etc. Thanks, -RP On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >While there are cases where out-of-band metadata makes sense, There are >many cases I would not want to try to cover that way. The best examples >are situations where the metadata changes from packet to packet (such as >the data produced by a DPI engine for consumption by other applications >in the chain.) > >More importantly, if you are putting correlators in the packet, it is >still very complex if you want to use one correlator to handle metadata >produced by several different entities (the initial classifer, the DPI >engine, ...) You quickly end up deciding that you need several >correlators. At which point we are back to variable amounts of metadata. > >The alternative is to require exceedingly specific and strong coupling >to a mandated out-of-band mechanism. That seems to me to be a very bad >idea. > >Yours, >Joel > >On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >> resend to avoid "too many recipients" warning >> >> >> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman > > wrote: >> >> There are ways to signal variable length amounts of metadata without >> needing an additional variable-length header on each data packet. >> >> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >> possible approaches: out-of-band signaling (congruent or >> non-congruent) or a hybrid approach using a fix-length in-band >> correlator and out-of-band additional metadata. See sections 3.3, >> 3.4 and 3.5 in the draft. >> >> The issue of fixed-length encoding versus variable length encoding >> is discussion in the challenges chapter in section 4.3. I should >> probably mention the MTU and segmentation issues as well in that >> section. >> >> >> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >> > wrote: >> >> The variable length shim header is needed even if every >> individual piece of metadata has a fixed length. Different >> service chains will need different combinations of metadata. So >> the metadata portion of the header needs to be variable length. >> >> I think the approach of a fixed length initial part, and a >> variable length extension part, is the right model. >> >> Yours, >> Joel >> >> >> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >> >> Yes, fragmentation and variable headers are usually a really >> bad thing for forwarding performance. Let's not forget that >> we live in a 100G-ish kind of world nowadays. >> >> Now the question should be: WHY would we want to do that >> (variable headers leading to fragmentation issues)? >> >> For example, the type of metadata that may require >> variable-length fields might be a better candidate for some >> out-of-band signaling mechanism. If this is service >> authorization data (e.g. a service profile/policy), this >> sounds likely. Not 100% sure this is true for all use cases >> though. Only a good understanding of use cases, grounded by >> reflecting on existing network architectures (notably >> broadband, fixed or mobile), would tell us if one approach >> or another is the most appropriate. >> >> Anyhoo, we're jumping way deep in the detailed protocol >> design here. This seems a tad premature. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org >> ] On Behalf Of Dave Dolson >> Sent: Thursday, February 13, 2014 11:03 AM >> To: 'jmh@joelhalpern.com '; >> 'Ron_Parker@affirmednetworks.__com >> '; >> 'mohamed.boucadair@orange.com >> '__; >> 'Nicolas.BOUTHORS@qosmos.com >> '; 'paulq@cisco.com >> ' >> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >> 'linda.dunbar@huawei.com ' >> Subject: Re: [sfc] Framework >> >> it is overall more efficient to support PMTU discovery >> rather than fragmenting every large packet. The is why TCP >> adopted it so early on. >> >> The fragmenting also puts huge performance burden on the >> service functions. >> Fragmenting may also affect the ability of load balancers to >> get each fragment to the correct destination. >> >> So PMTU discovery SHOULD be used, in my opinion. By this I >> mean the client or server is informed that its packets are >> too big (for IPv6 or IPv4 with DF=3D1). >> >> Some operators may wish to incur the extra cost to hide the >> existence of the tunneling, when the elements of the chain >> can support it, so we could consider that as an optional >> mechanism. >> >> -Dave >> >> >> ----- Original Message ----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >> Sent: Thursday, February 13, 2014 10:31 AM >> To: Ron Parker > >; >> mohamed.boucadair@orange.com >> >> > >__; Dave Dolson; >> 'Nicolas.BOUTHORS@qosmos.com >> ' >> > >; 'paulq@cisco.com >> ' > > >> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >> ' >; >> 'linda.dunbar@huawei.com ' >> > >> Subject: Re: [sfc] Framework >> >> I mostly agree with you Ron. I can probably come up with >> some other variations, but your second point is that the >> transport must deal with the issue of frame size / fit. >> >> I would note that if we assume that the carrying encaps >> (IPv4/v6 outer) is being fragmented, then we are assuming >> that the exit from service chaining can and will reassemble. >> >> Yours, >> Joel >> >> On 2/13/14, 10:18 AM, Ron Parker wrote: >> >> Joel, >> >> That is an excellent point to consider when choosing >> transport >> encapsulations. If the transport encapsulation is IPv4 >> or IPv6 >> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), >>then >> fragmentation and defragmentation are naturally >> supported. If the >> transport encapsulation is VLAN, MPLS, etc., then I >> believe one of the >> following must be true: >> >> * The end-to-end path is known to support the resulting >> larger frames >> * A path discovery mechanism is mandated by SFC when >> non-IP transports >> are used * An SFC-specific fragmentation header and >> mechanisms must be >> defined (i.e., >> =20 >>SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-frame) >> >> Ron >> >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com >> ] Sent: Thursday, February >> 13, 2014 10:10 >> AM To: mohamed.boucadair@orange.com >> ; Dave Dolson; >> 'Nicolas.BOUTHORS@qosmos.com >> '; Ron Parker; >> 'paulq@cisco.com ' Cc: >> 'S.Majee@F5.com'; 'sfc@ietf.org '; >> 'linda.dunbar@huawei.com >> ' Subject: >> Re: [sfc] Framework >> >> There is a related complexity. I hope that we expect to >> support IPv6. >> IPv6 explicitly prohibits network elements from >> fragmenting end user >> packets. >> >> Yours, Joel >> >> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >> wrote: >> >> Re-, >> >> FWIW, one of the existing architecture drafts >> includes the following >> behavior >> =20 >>(http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#section- >>6 >> =20 >>): >> >> >> >> " >> >> 6. Fragmentation Considerations >> >> If adding the Service Chaining Header would result >> in a fragmented >> packet, the classifier should include a Service >> Chaining Header in >> each fragment. Doing so would prevent SF Nodes to >> dedicate resource >> to handle fragments. " >> >> Cheers, Med >> >> >> -----Message d'origine----- De : sfc >> [mailto:sfc-bounces@ietf.org >> ] >> De la part de Dave Dolson Envoy=E9 : >> jeudi 13 f=E9vrier 2014 13:39 =C0 : >> 'Nicolas.BOUTHORS@qosmos.com >> '; >> 'Ron_Parker@affirmednetworks.__com >> '; >> 'jmh@joelhalpern.com >>'; >> 'paulq@cisco.com ' Cc : >> 'S.Majee@F5.com'; 'sfc@ietf.org >> '; >> 'linda.dunbar@huawei.com >> ' Objet : Re: >> [sfc] Framework >> >> Good point to consider fragmentation. >> >> We should design the encapsulation such that the >> forwarding >> functions do not need to reassemble. Each >> fragment should be >> independently forwardable; some SFs may choose >> to ignore these >> packets. >> >> Any layer 2.5 protocol like VLAN or MPLS would >> support this. >> Otherwise, a reassembly layer could be added >> after the forwarding >> coordinates. Think of something like the IPv6 >> reassembly option >> after a GRE header, for instance. >> >> IP | GRE | reassem | frag data >> >> We could alternatively mandate the inner IP be >> fragmented and that >> path-MTU discovery be supported. >> >> >> >> >> ----- Original Message ----- From: Nicolas >>BOUTHORS >> [mailto:Nicolas.BOUTHORS@__qosmos.com >> ] Sent: >> Thursday, February 13, >> 2014 04:13 AM To: Ron Parker >> > >; >> Dave Dolson; Joel M. Halpern >> > >; Paul Quinn >> (paulq) > > Cc: Sumandra Majee >> ; >> sfc@ietf.org > >; Linda Dunbar >> > > >> Subject: Re: [sfc] Framework >> >> If we do not enforce a fix header size we have >> other implication. >> >> There is the question of segmentation and >> reassembly responsibility >> as well. >> >> If adding length to the service header forces >> segmentation, then >> whose responsibility is it to reassemble the >> payload before passing >> it to the SF. >> >> Similar question for packet re-ordering. >> >> >> __________________________________________ From: >> Ron Parker >> [Ron_Parker@affirmednetworks.__com >> ] Sent: >> Wednesday, February 12, >> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; >> Paul Quinn >> (paulq) Cc: Sumandra Majee; sfc@ietf.org >> ; Linda Dunbar Subject: >> Re: [sfc] Framework >> >> Dave, >> >> Yes, that is a good point if we logically >> separate the forwarding >> function from the SFC-aware service function, as >> we should. The >> forwarding function is concerned with only the >> inbound transport >> header, the fixed portion of the service header >> containing the >> chain information, and the outbound transport >> header. The >> service function may look at the entirety of the >> service header and >> would look at the encapsulated packet. >> >> Ron >> >> >> -----Original Message----- From: Dave Dolson >> [mailto:ddolson@sandvine.com >> ] Sent: Wednesday, >> February 12, 2014 >> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >> Quinn (paulq) Cc: >> Sumandra Majee; sfc@ietf.org >> ; Linda Dunbar Subject: RE: >> [sfc] >> Framework >> >> The forwarding plane might not even need to look >> at the encapsulated >> packet. >> >> For example, (if the SF Identifier is a VLAN >> tag), an Ethernet >> switch can forward packets of the form: Ether | >> VLAN | BLOB. >> >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] >> On Behalf Of Joel M. Halpern Sent: >> Wednesday, February 12, 2014 4:30 PM To: Ron >> Parker; Dave Dolson; >> Paul Quinn (paulq) Cc: Sumandra Majee; >> sfc@ietf.org ; Linda Dunbar >> Subject: Re: [sfc] Framework >> >> I agree as well. Yours, Joel >> >> On 2/12/14, 4:24 PM, Ron Parker wrote: >> >> Hi, Dave. >> >> I Agree with your statement. And if the >> total length of the >> header is >> >> contained in the mandatory portion, the hardware >> implementation can >> easily locate the encapsulated packet. >> >> >> Ron >> >> >> -----Original Message----- From: Dave Dolson >> [mailto:ddolson@sandvine.com >> ] Sent: >> Wednesday, February 12, >> 2014 4:10 PM To: Ron Parker; Paul Quinn >> (paulq) Cc: Joel M. >> Halpern; Sumandra Majee; sfc@ietf.org >> ; Linda Dunbar Subject: >> RE: [sfc] Framework >> >> I think a good approach would be: >> >> The information required for forwarding (the >> SF Identifier) should >> be in >> >> a mandatory fixed-size header. >> >> >> Optional information (if any) is NOT to be >> used for forwarding, but >> is >> >> for consumption by one or more of the >> applications in the chain. >> >> >> Then the forwarding plane, and even the PDP, >> can be agnostic about >> the >> >> meta-data. >> >> >> -Dave >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] >> On Behalf Of Ron Parker Sent: >> Wednesday, February 12, 2014 4:05 PM To: >> Paul Quinn (paulq) Cc: >> Joel M. Halpern; Sumandra Majee; >> sfc@ietf.org ; Linda >>Dunbar >> Subject: Re: [sfc] Framework >> >> Paul, >> >> That is why I am proposing a hybrid where >> extensions or options can >> be >> >> added but the total length is contained in the >> fixed portion. I >> can envision certain deployments (e.g., >> Enterprise) where perhaps >> extensions are not needed and the SFC >> functionality is realized >> in hardware. And, I can envision certain other >> deployments >> (e.g., 3gpp) where the extension headers add >> sufficient value to >> justify software based implementations. >> >> >> Ron >> >> >> -----Original Message----- From: Paul Quinn >> (paulq) >> [mailto:paulq@cisco.com >> ] Sent: Wednesday, >> February 12, 2014 >> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >> Linda Dunbar; Joel M. >> Halpern; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> Hi, >> >> We certainly need to be very careful with >> variable length headers >> when >> >> hardware platform are in play. >> >> >> Ron, your examples of IP options and v6 EH >> have both suffered from >> >> significant implementation and deployment >> hurdles due to the >> complexity and cost associated with hardware >> support for the >> option/EH. >> >> >> Paul >> >> On Feb 12, 2014, at 3:10 PM, Ron Parker >> > > >> >> wrote: >> >> >> Hi, Sumandra. >> >> Regarding service header flexibility, I >> completely agree. I >> might >> >> suggest a compromise between hardware >> friendliness and software >> flexibility. If the header had the ability to >> add extensions >> (perhaps similar to IPv6) but also had the >> header length encoded in >> the mandatory part (like IPv4), then a hardware >> implementation would >> be free to skip over the extensions (in cases >> where the deployment >> justifies ignoring the extensions). >> >> >> Ron >> >> >> -----Original Message----- From: >> Sumandra Majee >> [mailto:S.Majee@F5.com >> ] Sent: >> Wednesday, February 12, 2014 >> 3:04 PM To: Ron Parker; Linda Dunbar; >> Joel M. Halpern; >> sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> For all of those reasons, I >> strongly support a canonical >>service >> header that is independent of >> the transport methodology. >> >> >> >> I agree. However the format of service >> header should be >> standardized in >> >> a way that is flexible. Some of us would like to >> see variable length >> header that is also HW friendly. The service >> header can be >> represented as a mandotory fixed length header >> (like IP >> header) along with an optional variable length >> attribute field. >> Different services can be interested in >> different metadata, for >> example subscriber ID could be of interest in >> the mobile core >> service chain only. >> >> >> Sumandra >> >> On 2/12/14, 11:32 AM, "Ron Parker" >> > =20 >>> >> >> wrote: >> >> >> Linda, >> >> My interpretation of the >> architecture docs is that the >>service >> function chain is built in an >> abstract manner (i.e., SF-A then >> SF-B >> >> then SF-C). >> >> Separately, a locator table provides >> network location for >> each of those service functions. >> In this way, you can >> locate the service functions >> >> in >> >> a manner appropriate to the type of >> transport you are >> using. If you want that to be >> interface+VLAN, >> gateway-IP+MPLS label stack, IP >> >> address, >> >> GRE tunnel remote IP + key, etc., >> you can do that. You >> can even potentially locate >> different service functions that >> reside in the same chain with >> different flavors of >> network locators. Another >> justification to separate the >> identity of a service function from >> its network location is >> load balancing. If, for example, >> SF-A had 3 IP addresses, >> that would imply load balancing to 3 >> instances using IP as a >> transport layer. >> >> For all of those reasons, I strongly >> support a canonical service >> header that is independent of the >> transport >> methodology. At a particular >> node, the decision as to >> where to go next should be based >> solely on information carried in >> the canonical service header and not >> on the >> >> fields >> >> in the transport header. That is, >> the SFC node discards >> the transport header and extracts >> the chain ID from the >> service header. Through >> mechanisms we have not yet begun >> to discuss, the SFC node knows how >> to interpret the chain ID and >> ultimately how to progress the >>packet. >> >> Ron >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] On >> Behalf Of Linda Dunbar >> Sent: Wednesday, February 12, 2014 >> 12:01 PM To: Joel M. >> Halpern; sfc@ietf.org >> Subject: Re: >> [sfc] Framework >> >> Agree with Joel's statement. >> >> I think a simple sentence below >> should be added Section 5.2 (SFC >> Classifier) to emphasize this point. >> >> "A Service Chain Classifier node can >> associate a unique Layer 2 >> or 3 Label (e.g. VLAN, MPLS label) >> to the packets in the flow. >> Those Layer 2 or 3 Label makes it >> easier for subsequent nodes >> along the flow path to steer the >> flow to the service functions >> specified by the flow's service >>chain." >> >> >> Linda -----Original Message----- >> From: sfc >> [mailto:sfc-bounces@ietf.org >> ] On >> Behalf Of Joel M. Halpern >> Sent: Wednesday, February 12, 2014 >> 10:20 AM To: >> sfc@ietf.org >> Subject: [sfc] Framework >> >> I was looking at the framework >> proposal. The proposal has a very >> specific model of the scope of the >> transport header (that it is >> derived from, and relates only to, >> the first service function to >> which the packet will be directed. >> That is clearly an operational >> model we need to support. >> >> However, I would like to allow other >> transport operational >> models, such as the use of a VLAN to >> direct traffic along a >> chain. Or the use of an MPLS label, >> or an MPLS label stack. >> >> Yours, Joel M. Halpern >> >> =20 >>_________________________________________________ >> sfc mailing list >> sfc@ietf.org >> =20 >>https://www.ietf.org/mailman/__listinfo/sfc >> =20 >> >> >> =20 >>_________________________________________________ >> sfc mailing list >> sfc@ietf.org >> =20 >>https://www.ietf.org/mailman/__listinfo/sfc >> =20 >> >> >> =20 >>_________________________________________________ >> sfc mailing list >> sfc@ietf.org >> =20 >>https://www.ietf.org/mailman/__listinfo/sfc >> =20 >> >> >> >> =20 >>_________________________________________________ >> sfc mailing list >> sfc@ietf.org >> =20 >>https://www.ietf.org/mailman/__listinfo/sfc >> =20 >> >> >> >> =20 >>_________________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/__listinfo/sfc >> >> >> >> =20 >>_________________________________________________ sfc >> mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/__listinfo/sfc >> >> >> >> >> =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 >> >> >> >> >> >> _________________________________________________ >> 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 Feb 13 11:29:11 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9528D1A0404 for ; Thu, 13 Feb 2014 11:29:09 -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 AjHY5Iyb7Ckb for ; Thu, 13 Feb 2014 11:29:04 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9961A034A for ; Thu, 13 Feb 2014 11:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4192C3E0632 for ; Thu, 13 Feb 2014 11:29:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 501483E05A4 for ; Thu, 13 Feb 2014 11:29:00 -0800 (PST) Message-ID: <52FD1D03.9030905@joelhalpern.com> Date: Thu, 13 Feb 2014 14:29:07 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RwJ_vdEwVWr_IOx5Zy5vRF0ndsE Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:29:09 -0000 As I understand it, the tsvwg (and aeon) work is about flow metadata. That is long-lived metadata of use across many packets. That does indeed seem well-suited to out-of-band cases. My concern is that in SFC, there are many cases which are at best badly-addressed if we insist that they be solved using out-of-band metadata. Yours, Joel On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: > There is draft about transport independent metadata. > > http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01 > > The complexities you mention are discussed there: variable-encoding, > direction, security of metadata, etc. > > Thanks, > > -RP > > > On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: > >> While there are cases where out-of-band metadata makes sense, There are >> many cases I would not want to try to cover that way. The best examples >> are situations where the metadata changes from packet to packet (such as >> the data produced by a DPI engine for consumption by other applications >> in the chain.) >> >> More importantly, if you are putting correlators in the packet, it is >> still very complex if you want to use one correlator to handle metadata >> produced by several different entities (the initial classifer, the DPI >> engine, ...) You quickly end up deciding that you need several >> correlators. At which point we are back to variable amounts of metadata. >> >> The alternative is to require exceedingly specific and strong coupling >> to a mandated out-of-band mechanism. That seems to me to be a very bad >> idea. >> >> Yours, >> Joel >> >> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>> resend to avoid "too many recipients" warning >>> >>> >>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >> > wrote: >>> >>> There are ways to signal variable length amounts of metadata without >>> needing an additional variable-length header on each data packet. >>> >>> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >>> possible approaches: out-of-band signaling (congruent or >>> non-congruent) or a hybrid approach using a fix-length in-band >>> correlator and out-of-band additional metadata. See sections 3.3, >>> 3.4 and 3.5 in the draft. >>> >>> The issue of fixed-length encoding versus variable length encoding >>> is discussion in the challenges chapter in section 4.3. I should >>> probably mention the MTU and segmentation issues as well in that >>> section. >>> >>> >>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>> > wrote: >>> >>> The variable length shim header is needed even if every >>> individual piece of metadata has a fixed length. Different >>> service chains will need different combinations of metadata. So >>> the metadata portion of the header needs to be variable length. >>> >>> I think the approach of a fixed length initial part, and a >>> variable length extension part, is the right model. >>> >>> Yours, >>> Joel >>> >>> >>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>> >>> Yes, fragmentation and variable headers are usually a really >>> bad thing for forwarding performance. Let's not forget that >>> we live in a 100G-ish kind of world nowadays. >>> >>> Now the question should be: WHY would we want to do that >>> (variable headers leading to fragmentation issues)? >>> >>> For example, the type of metadata that may require >>> variable-length fields might be a better candidate for some >>> out-of-band signaling mechanism. If this is service >>> authorization data (e.g. a service profile/policy), this >>> sounds likely. Not 100% sure this is true for all use cases >>> though. Only a good understanding of use cases, grounded by >>> reflecting on existing network architectures (notably >>> broadband, fixed or mobile), would tell us if one approach >>> or another is the most appropriate. >>> >>> Anyhoo, we're jumping way deep in the detailed protocol >>> design here. This seems a tad premature. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Dave Dolson >>> Sent: Thursday, February 13, 2014 11:03 AM >>> To: 'jmh@joelhalpern.com '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'mohamed.boucadair@orange.com >>> '__; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; 'paulq@cisco.com >>> ' >>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>> 'linda.dunbar@huawei.com ' >>> Subject: Re: [sfc] Framework >>> >>> it is overall more efficient to support PMTU discovery >>> rather than fragmenting every large packet. The is why TCP >>> adopted it so early on. >>> >>> The fragmenting also puts huge performance burden on the >>> service functions. >>> Fragmenting may also affect the ability of load balancers to >>> get each fragment to the correct destination. >>> >>> So PMTU discovery SHOULD be used, in my opinion. By this I >>> mean the client or server is informed that its packets are >>> too big (for IPv6 or IPv4 with DF=1). >>> >>> Some operators may wish to incur the extra cost to hide the >>> existence of the tunneling, when the elements of the chain >>> can support it, so we could consider that as an optional >>> mechanism. >>> >>> -Dave >>> >>> >>> ----- Original Message ----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>> Sent: Thursday, February 13, 2014 10:31 AM >>> To: Ron Parker >> >; >>> mohamed.boucadair@orange.com >>> >>> >> >__; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> ' >>> >> >; 'paulq@cisco.com >>> ' >> > >>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>> ' >; >>> 'linda.dunbar@huawei.com ' >>> > >>> Subject: Re: [sfc] Framework >>> >>> I mostly agree with you Ron. I can probably come up with >>> some other variations, but your second point is that the >>> transport must deal with the issue of frame size / fit. >>> >>> I would note that if we assume that the carrying encaps >>> (IPv4/v6 outer) is being fragmented, then we are assuming >>> that the exit from service chaining can and will reassemble. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>> >>> Joel, >>> >>> That is an excellent point to consider when choosing >>> transport >>> encapsulations. If the transport encapsulation is IPv4 >>> or IPv6 >>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), >>> then >>> fragmentation and defragmentation are naturally >>> supported. If the >>> transport encapsulation is VLAN, MPLS, etc., then I >>> believe one of the >>> following must be true: >>> >>> * The end-to-end path is known to support the resulting >>> larger frames >>> * A path discovery mechanism is mandated by SFC when >>> non-IP transports >>> are used * An SFC-specific fragmentation header and >>> mechanisms must be >>> defined (i.e., >>> >>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-frame) >>> >>> Ron >>> >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Sent: Thursday, February >>> 13, 2014 10:10 >>> AM To: mohamed.boucadair@orange.com >>> ; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; Ron Parker; >>> 'paulq@cisco.com ' Cc: >>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>> 'linda.dunbar@huawei.com >>> ' Subject: >>> Re: [sfc] Framework >>> >>> There is a related complexity. I hope that we expect to >>> support IPv6. >>> IPv6 explicitly prohibits network elements from >>> fragmenting end user >>> packets. >>> >>> Yours, Joel >>> >>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>> wrote: >>> >>> Re-, >>> >>> FWIW, one of the existing architecture drafts >>> includes the following >>> behavior >>> >>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#section- >>> 6 >>> >>> ): >>> >>> >>> >>> " >>> >>> 6. Fragmentation Considerations >>> >>> If adding the Service Chaining Header would result >>> in a fragmented >>> packet, the classifier should include a Service >>> Chaining Header in >>> each fragment. Doing so would prevent SF Nodes to >>> dedicate resource >>> to handle fragments. " >>> >>> Cheers, Med >>> >>> >>> -----Message d'origine----- De : sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> De la part de Dave Dolson Envoyé : >>> jeudi 13 février 2014 13:39 À : >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'jmh@joelhalpern.com >>> '; >>> 'paulq@cisco.com ' Cc : >>> 'S.Majee@F5.com'; 'sfc@ietf.org >>> '; >>> 'linda.dunbar@huawei.com >>> ' Objet : Re: >>> [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that the >>> forwarding >>> functions do not need to reassemble. Each >>> fragment should be >>> independently forwardable; some SFs may choose >>> to ignore these >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would >>> support this. >>> Otherwise, a reassembly layer could be added >>> after the forwarding >>> coordinates. Think of something like the IPv6 >>> reassembly option >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be >>> fragmented and that >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas >>> BOUTHORS >>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>> ] Sent: >>> Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker >>> >> >; >>> Dave Dolson; Joel M. Halpern >>> >> >; Paul Quinn >>> (paulq) >> > Cc: Sumandra Majee >>> ; >>> sfc@ietf.org >> >; Linda Dunbar >>> >> > >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have >>> other implication. >>> >>> There is the question of segmentation and >>> reassembly responsibility >>> as well. >>> >>> If adding length to the service header forces >>> segmentation, then >>> whose responsibility is it to reassemble the >>> payload before passing >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> __________________________________________ From: >>> Ron Parker >>> [Ron_Parker@affirmednetworks.__com >>> ] Sent: >>> Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; >>> Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically >>> separate the forwarding >>> function from the SFC-aware service function, as >>> we should. The >>> forwarding function is concerned with only the >>> inbound transport >>> header, the fixed portion of the service header >>> containing the >>> chain information, and the outbound transport >>> header. The >>> service function may look at the entirety of the >>> service header and >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com >>> ] Sent: Wednesday, >>> February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>> Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: RE: >>> [sfc] >>> Framework >>> >>> The forwarding plane might not even need to look >>> at the encapsulated >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN >>> tag), an Ethernet >>> switch can forward packets of the form: Ether | >>> VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron >>> Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; >>> sfc@ietf.org ; Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>> >>> Hi, Dave. >>> >>> I Agree with your statement. And if the >>> total length of the >>> header is >>> >>> contained in the mandatory portion, the hardware >>> implementation can >>> easily locate the encapsulated packet. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com >>> ] Sent: >>> Wednesday, February 12, >>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>> (paulq) Cc: Joel M. >>> Halpern; Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: >>> RE: [sfc] Framework >>> >>> I think a good approach would be: >>> >>> The information required for forwarding (the >>> SF Identifier) should >>> be in >>> >>> a mandatory fixed-size header. >>> >>> >>> Optional information (if any) is NOT to be >>> used for forwarding, but >>> is >>> >>> for consumption by one or more of the >>> applications in the chain. >>> >>> >>> Then the forwarding plane, and even the PDP, >>> can be agnostic about >>> the >>> >>> meta-data. >>> >>> >>> -Dave >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Ron Parker Sent: >>> Wednesday, February 12, 2014 4:05 PM To: >>> Paul Quinn (paulq) Cc: >>> Joel M. Halpern; Sumandra Majee; >>> sfc@ietf.org ; Linda >>> Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Paul, >>> >>> That is why I am proposing a hybrid where >>> extensions or options can >>> be >>> >>> added but the total length is contained in the >>> fixed portion. I >>> can envision certain deployments (e.g., >>> Enterprise) where perhaps >>> extensions are not needed and the SFC >>> functionality is realized >>> in hardware. And, I can envision certain other >>> deployments >>> (e.g., 3gpp) where the extension headers add >>> sufficient value to >>> justify software based implementations. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Paul Quinn >>> (paulq) >>> [mailto:paulq@cisco.com >>> ] Sent: Wednesday, >>> February 12, 2014 >>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>> Linda Dunbar; Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Hi, >>> >>> We certainly need to be very careful with >>> variable length headers >>> when >>> >>> hardware platform are in play. >>> >>> >>> Ron, your examples of IP options and v6 EH >>> have both suffered from >>> >>> significant implementation and deployment >>> hurdles due to the >>> complexity and cost associated with hardware >>> support for the >>> option/EH. >>> >>> >>> Paul >>> >>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>> >> > >>> >>> wrote: >>> >>> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, I >>> completely agree. I >>> might >>> >>> suggest a compromise between hardware >>> friendliness and software >>> flexibility. If the header had the ability to >>> add extensions >>> (perhaps similar to IPv6) but also had the >>> header length encoded in >>> the mandatory part (like IPv4), then a hardware >>> implementation would >>> be free to skip over the extensions (in cases >>> where the deployment >>> justifies ignoring the extensions). >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: >>> Sumandra Majee >>> [mailto:S.Majee@F5.com >>> ] Sent: >>> Wednesday, February 12, 2014 >>> 3:04 PM To: Ron Parker; Linda Dunbar; >>> Joel M. Halpern; >>> sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> For all of those reasons, I >>> strongly support a canonical >>> service >>> header that is independent of >>> the transport methodology. >>> >>> >>> >>> I agree. However the format of service >>> header should be >>> standardized in >>> >>> a way that is flexible. Some of us would like to >>> see variable length >>> header that is also HW friendly. The service >>> header can be >>> represented as a mandotory fixed length header >>> (like IP >>> header) along with an optional variable length >>> attribute field. >>> Different services can be interested in >>> different metadata, for >>> example subscriber ID could be of interest in >>> the mobile core >>> service chain only. >>> >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >>> >> >>> > >>> >>> wrote: >>> >>> >>> Linda, >>> >>> My interpretation of the >>> architecture docs is that the >>> service >>> function chain is built in an >>> abstract manner (i.e., SF-A then >>> SF-B >>> >>> then SF-C). >>> >>> Separately, a locator table provides >>> network location for >>> each of those service functions. >>> In this way, you can >>> locate the service functions >>> >>> in >>> >>> a manner appropriate to the type of >>> transport you are >>> using. If you want that to be >>> interface+VLAN, >>> gateway-IP+MPLS label stack, IP >>> >>> address, >>> >>> GRE tunnel remote IP + key, etc., >>> you can do that. You >>> can even potentially locate >>> different service functions that >>> reside in the same chain with >>> different flavors of >>> network locators. Another >>> justification to separate the >>> identity of a service function from >>> its network location is >>> load balancing. If, for example, >>> SF-A had 3 IP addresses, >>> that would imply load balancing to 3 >>> instances using IP as a >>> transport layer. >>> >>> For all of those reasons, I strongly >>> support a canonical service >>> header that is independent of the >>> transport >>> methodology. At a particular >>> node, the decision as to >>> where to go next should be based >>> solely on information carried in >>> the canonical service header and not >>> on the >>> >>> fields >>> >>> in the transport header. That is, >>> the SFC node discards >>> the transport header and extracts >>> the chain ID from the >>> service header. Through >>> mechanisms we have not yet begun >>> to discuss, the SFC node knows how >>> to interpret the chain ID and >>> ultimately how to progress the >>> packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 >>> 12:01 PM To: Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: >>> [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below >>> should be added Section 5.2 (SFC >>> Classifier) to emphasize this point. >>> >>> "A Service Chain Classifier node can >>> associate a unique Layer 2 >>> or 3 Label (e.g. VLAN, MPLS label) >>> to the packets in the flow. >>> Those Layer 2 or 3 Label makes it >>> easier for subsequent nodes >>> along the flow path to steer the >>> flow to the service functions >>> specified by the flow's service >>> chain." >>> >>> >>> Linda -----Original Message----- >>> From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 >>> 10:20 AM To: >>> sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework >>> proposal. The proposal has a very >>> specific model of the scope of the >>> transport header (that it is >>> derived from, and relates only to, >>> the first service function to >>> which the packet will be directed. >>> That is clearly an operational >>> model we need to support. >>> >>> However, I would like to allow other >>> transport operational >>> models, such as the use of a VLAN to >>> direct traffic along a >>> chain. Or the use of an MPLS label, >>> or an MPLS label stack. >>> >>> Yours, Joel M. Halpern >>> >>> >>> _________________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> _________________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> _________________________________________________ >>> 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 Feb 13 11:33:59 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1228B1A0417 for ; Thu, 13 Feb 2014 11:33:58 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeciUu1giy1J for ; Thu, 13 Feb 2014 11:33:52 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 161681A0421 for ; Thu, 13 Feb 2014 11:33:52 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 11:33:50 -0800 From: Ron Parker To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAcmAgACF7vA= Date: Thu, 13 Feb 2014 19:33:49 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> In-Reply-To: <52FD1D03.9030905@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/skWXMEdIc37XvE_fwgLJWA-qBrg Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:33:58 -0000 Joel, I agree. I think SFC can lend itself to lots of innovation if it is flex= ible enough to carry metadata flexibly. Take, Kevin Ma's draft on decomp= osition of L7 transactions, http://datatracker.ietf.org/doc/draft-ma-sfc-de= composition. This draft lends itself very well to service-function-specif= ic correlation ID's (perhaps more than 1 in the same packet). Likewise, i= n Vancouver, the use cases presentation called out a service-function-speci= fic discard-eligibility conclusion that was conveyed from one SF to another= non-adjacent SF. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 2:29 PM To: sfc@ietf.org Subject: Re: [sfc] Framework As I understand it, the tsvwg (and aeon) work is about flow metadata.=20 That is long-lived metadata of use across many packets. That does indeed s= eem well-suited to out-of-band cases. My concern is that in SFC, there are many cases which are at best badly-add= ressed if we insist that they be solved using out-of-band metadata. Yours, Joel On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: > There is draft about transport independent metadata. > > http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding- > 01 > > The complexities you mention are discussed there: variable-encoding,=20 > direction, security of metadata, etc. > > Thanks, > > -RP > > > On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: > >> While there are cases where out-of-band metadata makes sense, There=20 >> are many cases I would not want to try to cover that way. The best=20 >> examples are situations where the metadata changes from packet to=20 >> packet (such as the data produced by a DPI engine for consumption by=20 >> other applications in the chain.) >> >> More importantly, if you are putting correlators in the packet, it is=20 >> still very complex if you want to use one correlator to handle=20 >> metadata produced by several different entities (the initial=20 >> classifer, the DPI engine, ...) You quickly end up deciding that you=20 >> need several correlators. At which point we are back to variable amount= s of metadata. >> >> The alternative is to require exceedingly specific and strong=20 >> coupling to a mandated out-of-band mechanism. That seems to me to be=20 >> a very bad idea. >> >> Yours, >> Joel >> >> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>> resend to avoid "too many recipients" warning >>> >>> >>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>> > wrote: >>> >>> There are ways to signal variable length amounts of metadata witho= ut >>> needing an additional variable-length header on each data packet. >>> >>> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >>> possible approaches: out-of-band signaling (congruent or >>> non-congruent) or a hybrid approach using a fix-length in-band >>> correlator and out-of-band additional metadata. See sections 3.3, >>> 3.4 and 3.5 in the draft. >>> >>> The issue of fixed-length encoding versus variable length encoding >>> is discussion in the challenges chapter in section 4.3. I should >>> probably mention the MTU and segmentation issues as well in that >>> section. >>> >>> >>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>> > wrote: >>> >>> The variable length shim header is needed even if every >>> individual piece of metadata has a fixed length. Different >>> service chains will need different combinations of metadata. = So >>> the metadata portion of the header needs to be variable length= . >>> >>> I think the approach of a fixed length initial part, and a >>> variable length extension part, is the right model. >>> >>> Yours, >>> Joel >>> >>> >>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>> >>> Yes, fragmentation and variable headers are usually a real= ly >>> bad thing for forwarding performance. Let's not forget tha= t >>> we live in a 100G-ish kind of world nowadays. >>> >>> Now the question should be: WHY would we want to do that >>> (variable headers leading to fragmentation issues)? >>> >>> For example, the type of metadata that may require >>> variable-length fields might be a better candidate for som= e >>> out-of-band signaling mechanism. If this is service >>> authorization data (e.g. a service profile/policy), this >>> sounds likely. Not 100% sure this is true for all use case= s >>> though. Only a good understanding of use cases, grounded b= y >>> reflecting on existing network architectures (notably >>> broadband, fixed or mobile), would tell us if one approach >>> or another is the most appropriate. >>> >>> Anyhoo, we're jumping way deep in the detailed protocol >>> design here. This seems a tad premature. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Dave Dolson >>> Sent: Thursday, February 13, 2014 11:03 AM >>> To: 'jmh@joelhalpern.com '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'mohamed.boucadair@orange.com >>> '__; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; 'paulq@cisco.com >>> ' >>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '= ; >>> 'linda.dunbar@huawei.com ' >>> Subject: Re: [sfc] Framework >>> >>> it is overall more efficient to support PMTU discovery >>> rather than fragmenting every large packet. The is why TCP >>> adopted it so early on. >>> >>> The fragmenting also puts huge performance burden on the >>> service functions. >>> Fragmenting may also affect the ability of load balancers = to >>> get each fragment to the correct destination. >>> >>> So PMTU discovery SHOULD be used, in my opinion. By this I >>> mean the client or server is informed that its packets are >>> too big (for IPv6 or IPv4 with DF=3D1). >>> >>> Some operators may wish to incur the extra cost to hide th= e >>> existence of the tunneling, when the elements of the chain >>> can support it, so we could consider that as an optional >>> mechanism. >>> >>> -Dave >>> >>> >>> ----- Original Message ----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>> Sent: Thursday, February 13, 2014 10:31 AM >>> To: Ron Parker >> >; >>> mohamed.boucadair@orange.com >>> >>> >> >__; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> ' >>> >> >; 'paulq@cisco.com >>> ' >> > >>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>> ' = >; >>> 'linda.dunbar@huawei.com ' >>> > >>> Subject: Re: [sfc] Framework >>> >>> I mostly agree with you Ron. I can probably come up with >>> some other variations, but your second point is that the >>> transport must deal with the issue of frame size / fit. >>> >>> I would note that if we assume that the carrying encaps >>> (IPv4/v6 outer) is being fragmented, then we are assuming >>> that the exit from service chaining can and will reassembl= e. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>> >>> Joel, >>> >>> That is an excellent point to consider when choosing >>> transport >>> encapsulations. If the transport encapsulation is IP= v4 >>> or IPv6 >>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>> etc.), then >>> fragmentation and defragmentation are naturally >>> supported. If the >>> transport encapsulation is VLAN, MPLS, etc., then I >>> believe one of the >>> following must be true: >>> >>> * The end-to-end path is known to support the resultin= g >>> larger frames >>> * A path discovery mechanism is mandated by SFC when >>> non-IP transports >>> are used * An SFC-specific fragmentation header and >>> mechanisms must be >>> defined (i.e., >>> >>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-f >>> rame) >>> >>> Ron >>> >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Sent: Thursday, February >>> 13, 2014 10:10 >>> AM To: mohamed.boucadair@orange.com >>> ; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; Ron Parker; >>> 'paulq@cisco.com ' Cc: >>> 'S.Majee@F5.com'; 'sfc@ietf.org '= ; >>> 'linda.dunbar@huawei.com >>> ' Subject: >>> Re: [sfc] Framework >>> >>> There is a related complexity. I hope that we expect t= o >>> support IPv6. >>> IPv6 explicitly prohibits network elements from >>> fragmenting end user >>> packets. >>> >>> Yours, Joel >>> >>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>> wrote: >>> >>> Re-, >>> >>> FWIW, one of the existing architecture drafts >>> includes the following >>> behavior >>> >>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec >>> tion- >>> 6 >>> >>> = ): >>> >>> >>> >>> " >>> >>> 6. Fragmentation Considerations >>> >>> If adding the Service Chaining Header would result >>> in a fragmented >>> packet, the classifier should include a Service >>> Chaining Header in >>> each fragment. Doing so would prevent SF Nodes to >>> dedicate resource >>> to handle fragments. " >>> >>> Cheers, Med >>> >>> >>> -----Message d'origine----- De : sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'jmh@joelhalpern.com=20 >>> '; >>> 'paulq@cisco.com ' Cc = : >>> 'S.Majee@F5.com'; 'sfc@ietf.org >>> '; >>> 'linda.dunbar@huawei.com >>> ' Objet : Re: >>> [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that t= he >>> forwarding >>> functions do not need to reassemble. Each >>> fragment should be >>> independently forwardable; some SFs may choose >>> to ignore these >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would >>> support this. >>> Otherwise, a reassembly layer could be added >>> after the forwarding >>> coordinates. Think of something like the IPv6 >>> reassembly option >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be >>> fragmented and that >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas=20 >>> BOUTHORS >>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>> ] Sent: >>> Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker >>> >> >; >>> Dave Dolson; Joel M. Halpern >>> >> >; Paul Quinn >>> (paulq) >> > Cc: Sumandra Majee >>> ; >>> sfc@ietf.org >> >; Linda Dunbar >>> >> > >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have >>> other implication. >>> >>> There is the question of segmentation and >>> reassembly responsibility >>> as well. >>> >>> If adding length to the service header forces >>> segmentation, then >>> whose responsibility is it to reassemble the >>> payload before passing >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> __________________________________________ Fro= m: >>> Ron Parker >>> [Ron_Parker@affirmednetworks.__com >>> ] Sent= : >>> Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern= ; >>> Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically >>> separate the forwarding >>> function from the SFC-aware service function, = as >>> we should. The >>> forwarding function is concerned with only the >>> inbound transport >>> header, the fixed portion of the service head= er >>> containing the >>> chain information, and the outbound transport >>> header. The >>> service function may look at the entirety of t= he >>> service header and >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com >>> ] Sent: Wednesday= , >>> February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>> Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: R= E: >>> [sfc] >>> Framework >>> >>> The forwarding plane might not even need to lo= ok >>> at the encapsulated >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN >>> tag), an Ethernet >>> switch can forward packets of the form: Ether= | >>> VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron >>> Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; >>> sfc@ietf.org ; Linda Dunb= ar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>> >>> Hi, Dave. >>> >>> I Agree with your statement. And if th= e >>> total length of the >>> header is >>> >>> contained in the mandatory portion, the hardwa= re >>> implementation can >>> easily locate the encapsulated packet. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dols= on >>> [mailto:ddolson@sandvine.com >>> ] Sent: >>> Wednesday, February 12, >>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>> (paulq) Cc: Joel M. >>> Halpern; Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subjec= t: >>> RE: [sfc] Framework >>> >>> I think a good approach would be: >>> >>> The information required for forwarding (t= he >>> SF Identifier) should >>> be in >>> >>> a mandatory fixed-size header. >>> >>> >>> Optional information (if any) is NOT to be >>> used for forwarding, but >>> is >>> >>> for consumption by one or more of the >>> applications in the chain. >>> >>> >>> Then the forwarding plane, and even the PD= P, >>> can be agnostic about >>> the >>> >>> meta-data. >>> >>> >>> -Dave >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Ron Parker Sent: >>> Wednesday, February 12, 2014 4:05 PM To: >>> Paul Quinn (paulq) Cc: >>> Joel M. Halpern; Sumandra Majee; >>> sfc@ietf.org ;=20 >>> Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Paul, >>> >>> That is why I am proposing a hybrid where >>> extensions or options can >>> be >>> >>> added but the total length is contained in the >>> fixed portion. I >>> can envision certain deployments (e.g., >>> Enterprise) where perhaps >>> extensions are not needed and the SFC >>> functionality is realized >>> in hardware. And, I can envision certain oth= er >>> deployments >>> (e.g., 3gpp) where the extension headers add >>> sufficient value to >>> justify software based implementations. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Paul Quin= n >>> (paulq) >>> [mailto:paulq@cisco.com >>> ] Sent: Wednesday, >>> February 12, 2014 >>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>> Linda Dunbar; Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Hi, >>> >>> We certainly need to be very careful with >>> variable length headers >>> when >>> >>> hardware platform are in play. >>> >>> >>> Ron, your examples of IP options and v6 EH >>> have both suffered from >>> >>> significant implementation and deployment >>> hurdles due to the >>> complexity and cost associated with hardware >>> support for the >>> option/EH. >>> >>> >>> Paul >>> >>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>> >> =20 >>> > >>> >>> wrote: >>> >>> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, = I >>> completely agree. I >>> might >>> >>> suggest a compromise between hardware >>> friendliness and software >>> flexibility. If the header had the ability = to >>> add extensions >>> (perhaps similar to IPv6) but also had the >>> header length encoded in >>> the mandatory part (like IPv4), then a hardwar= e >>> implementation would >>> be free to skip over the extensions (in cases >>> where the deployment >>> justifies ignoring the extensions). >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: >>> Sumandra Majee >>> [mailto:S.Majee@F5.com >>> ] Sent: >>> Wednesday, February 12, 2014 >>> 3:04 PM To: Ron Parker; Linda Dunbar; >>> Joel M. Halpern; >>> sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> For all of those reasons, I >>> strongly support a=20 >>> canonical service >>> header that is independent of >>> the transport methodology. >>> >>> >>> >>> I agree. However the format of service >>> header should be >>> standardized in >>> >>> a way that is flexible. Some of us would like = to >>> see variable length >>> header that is also HW friendly. The service >>> header can be >>> represented as a mandotory fixed length header >>> (like IP >>> header) along with an optional variable length >>> attribute field. >>> Different services can be interested in >>> different metadata, for >>> example subscriber ID could be of interest in >>> the mobile core >>> service chain only. >>> >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >>> >> >>> > >>> >>> wrote: >>> >>> >>> Linda, >>> >>> My interpretation of the >>> architecture docs is that the=20 >>> service >>> function chain is built in an >>> abstract manner (i.e., SF-A then >>> SF-B >>> >>> then SF-C). >>> >>> Separately, a locator table provid= es >>> network location for >>> each of those service functions. >>> In this way, you can >>> locate the service functions >>> >>> in >>> >>> a manner appropriate to the type o= f >>> transport you are >>> using. If you want that to be >>> interface+VLAN, >>> gateway-IP+MPLS label stack, IP >>> >>> address, >>> >>> GRE tunnel remote IP + key, etc., >>> you can do that. You >>> can even potentially locate >>> different service functions that >>> reside in the same chain with >>> different flavors of >>> network locators. Another >>> justification to separate the >>> identity of a service function fro= m >>> its network location is >>> load balancing. If, for example, >>> SF-A had 3 IP addresses, >>> that would imply load balancing to= 3 >>> instances using IP as a >>> transport layer. >>> >>> For all of those reasons, I strong= ly >>> support a canonical service >>> header that is independent of the >>> transport >>> methodology. At a particular >>> node, the decision as to >>> where to go next should be based >>> solely on information carried in >>> the canonical service header and n= ot >>> on the >>> >>> fields >>> >>> in the transport header. That is= , >>> the SFC node discards >>> the transport header and extracts >>> the chain ID from the >>> service header. Through >>> mechanisms we have not yet begun >>> to discuss, the SFC node knows how >>> to interpret the chain ID and >>> ultimately how to progress the=20 >>> packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: s= fc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 >>> 12:01 PM To: Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: >>> [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below >>> should be added Section 5.2 (SFC >>> Classifier) to emphasize this poin= t. >>> >>> "A Service Chain Classifier node c= an >>> associate a unique Layer 2 >>> or 3 Label (e.g. VLAN, MPLS label) >>> to the packets in the flow. >>> Those Layer 2 or 3 Label makes it >>> easier for subsequent nodes >>> along the flow path to steer the >>> flow to the service functions >>> specified by the flow's service=20 >>> chain." >>> >>> >>> Linda -----Original Message----- >>> From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 >>> 10:20 AM To: >>> sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework >>> proposal. The proposal has a very >>> specific model of the scope of the >>> transport header (that it is >>> derived from, and relates only to, >>> the first service function to >>> which the packet will be directed. >>> That is clearly an operational >>> model we need to support. >>> >>> However, I would like to allow oth= er >>> transport operational >>> models, such as the use of a VLAN = to >>> direct traffic along a >>> chain. Or the use of an MPLS labe= l, >>> or an MPLS label stack. >>> >>> Yours, Joel M. Halpern >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> 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/sf= c >>> =20 >>> >>> >>> >>> >>> _________________________________________________ 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 >>> >>> >>> >>> >>> >>> >>> _________________________________________________ >>> 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 Feb 13 11:36:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA681A0424 for ; Thu, 13 Feb 2014 11:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UqsEEqoZXwr for ; Thu, 13 Feb 2014 11:35:55 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id F092A1A0405 for ; Thu, 13 Feb 2014 11:35:54 -0800 (PST) Received: from mail164-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 19:35:53 +0000 Received: from mail164-va3 (localhost [127.0.0.1]) by mail164-va3-R.bigfish.com (Postfix) with ESMTP id 20E4A400265; Thu, 13 Feb 2014 19:35:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -75 X-BigFish: VPS-75(zzbb2dI98dI9371Ic89bh148cI542I1432I15caKJ4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail164-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(24454002)(13464003)(55784002)(199002)(189002)(51704005)(52604005)(377454003)(479174003)(85306002)(65816001)(561944002)(95416001)(19580395003)(54316002)(80976001)(56776001)(77982001)(19580405001)(59766001)(80022001)(54356001)(53806001)(66066001)(51856001)(76482001)(63696002)(46102001)(94316002)(47446002)(74662001)(86362001)(93516002)(31966008)(83322001)(74502001)(33646001)(56816005)(94946001)(15975445006)(50986001)(47736001)(47976001)(81816001)(81686001)(93136001)(49866001)(85852003)(69226001)(4396001)(74366001)(90146001)(74316001)(74876001)(2656002)(87266001)(81342001)(87936001)(81542001)(74706001)(92566001)(95666001)(79102001)(83072002)(15202345003)(76576001)(76796001)(76786001)(24736002)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB713; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:E66DF9D9.A7FA9383.B9C17173.82A5DB49.209F2; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail164-va3 (localhost.localdomain [127.0.0.1]) by mail164-va3 (MessageSwitch) id 1392320149453207_9399; Thu, 13 Feb 2014 19:35:49 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.245]) by mail164-va3.bigfish.com (Postfix) with ESMTP id DB0B526004D; Thu, 13 Feb 2014 19:35:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 19:35:35 +0000 Received: from CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 19:35:35 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB713.namprd05.prod.outlook.com (10.141.228.147) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 19:35:33 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 19:35:33 +0000 From: Jerome Moisand To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKO/ox4fmGuSHEU24oNCjTCFRY5qzkBAAgAAByYCAAABOIA== Date: Thu, 13 Feb 2014 19:35:32 +0000 Message-ID: <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> References: <52FD1D03.9030905@joelhalpern.com> In-Reply-To: <52FD1D03.9030905@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0121F24F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uRDKx-AYs1Q8LSHxAQ9WhfaEqt4 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:36:06 -0000 Joel, Protocols like GTP and L2TP work exactly that, with a form of session corre= lator between the data plane and the control plane. This is very handy for = subscriber and service management. Also if a correlator is defined as an op= aque and unique number, then one can avoid some of the pitfalls you describ= ed. Long-lived metadata is clearly useful (and thanks for sharing, Reinaldo= , will read), and there is clear applicability to various service chaining = needs. Now this is just one way. The I-D Bruno referred to was just listing this a= pproach as one possible way among others. I totally agree with you that oth= er forms of metadata (like an outcome of the classification of a packet or = a sequence of a few packets) may not be suitable for out-of-band signaling.= =20 Bottomline seems to be that we have too many options to choose from, and no= ne of them solving it all... Tough. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 2:29 PM To: sfc@ietf.org Subject: Re: [sfc] Framework As I understand it, the tsvwg (and aeon) work is about flow metadata.=20 That is long-lived metadata of use across many packets. That does indeed s= eem well-suited to out-of-band cases. My concern is that in SFC, there are many cases which are at best badly-add= ressed if we insist that they be solved using out-of-band metadata. Yours, Joel On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: > There is draft about transport independent metadata. > > http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding- > 01 > > The complexities you mention are discussed there: variable-encoding,=20 > direction, security of metadata, etc. > > Thanks, > > -RP > > > On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: > >> While there are cases where out-of-band metadata makes sense, There=20 >> are many cases I would not want to try to cover that way. The best=20 >> examples are situations where the metadata changes from packet to=20 >> packet (such as the data produced by a DPI engine for consumption by=20 >> other applications in the chain.) >> >> More importantly, if you are putting correlators in the packet, it is=20 >> still very complex if you want to use one correlator to handle=20 >> metadata produced by several different entities (the initial=20 >> classifer, the DPI engine, ...) You quickly end up deciding that you=20 >> need several correlators. At which point we are back to variable amount= s of metadata. >> >> The alternative is to require exceedingly specific and strong=20 >> coupling to a mandated out-of-band mechanism. That seems to me to be=20 >> a very bad idea. >> >> Yours, >> Joel >> >> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>> resend to avoid "too many recipients" warning >>> >>> >>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>> > wrote: >>> >>> There are ways to signal variable length amounts of metadata witho= ut >>> needing an additional variable-length header on each data packet. >>> >>> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >>> possible approaches: out-of-band signaling (congruent or >>> non-congruent) or a hybrid approach using a fix-length in-band >>> correlator and out-of-band additional metadata. See sections 3.3, >>> 3.4 and 3.5 in the draft. >>> >>> The issue of fixed-length encoding versus variable length encoding >>> is discussion in the challenges chapter in section 4.3. I should >>> probably mention the MTU and segmentation issues as well in that >>> section. >>> >>> >>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>> > wrote: >>> >>> The variable length shim header is needed even if every >>> individual piece of metadata has a fixed length. Different >>> service chains will need different combinations of metadata. = So >>> the metadata portion of the header needs to be variable length= . >>> >>> I think the approach of a fixed length initial part, and a >>> variable length extension part, is the right model. >>> >>> Yours, >>> Joel >>> >>> >>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>> >>> Yes, fragmentation and variable headers are usually a real= ly >>> bad thing for forwarding performance. Let's not forget tha= t >>> we live in a 100G-ish kind of world nowadays. >>> >>> Now the question should be: WHY would we want to do that >>> (variable headers leading to fragmentation issues)? >>> >>> For example, the type of metadata that may require >>> variable-length fields might be a better candidate for som= e >>> out-of-band signaling mechanism. If this is service >>> authorization data (e.g. a service profile/policy), this >>> sounds likely. Not 100% sure this is true for all use case= s >>> though. Only a good understanding of use cases, grounded b= y >>> reflecting on existing network architectures (notably >>> broadband, fixed or mobile), would tell us if one approach >>> or another is the most appropriate. >>> >>> Anyhoo, we're jumping way deep in the detailed protocol >>> design here. This seems a tad premature. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Dave Dolson >>> Sent: Thursday, February 13, 2014 11:03 AM >>> To: 'jmh@joelhalpern.com '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'mohamed.boucadair@orange.com >>> '__; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; 'paulq@cisco.com >>> ' >>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '= ; >>> 'linda.dunbar@huawei.com ' >>> Subject: Re: [sfc] Framework >>> >>> it is overall more efficient to support PMTU discovery >>> rather than fragmenting every large packet. The is why TCP >>> adopted it so early on. >>> >>> The fragmenting also puts huge performance burden on the >>> service functions. >>> Fragmenting may also affect the ability of load balancers = to >>> get each fragment to the correct destination. >>> >>> So PMTU discovery SHOULD be used, in my opinion. By this I >>> mean the client or server is informed that its packets are >>> too big (for IPv6 or IPv4 with DF=3D1). >>> >>> Some operators may wish to incur the extra cost to hide th= e >>> existence of the tunneling, when the elements of the chain >>> can support it, so we could consider that as an optional >>> mechanism. >>> >>> -Dave >>> >>> >>> ----- Original Message ----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] >>> Sent: Thursday, February 13, 2014 10:31 AM >>> To: Ron Parker >> >; >>> mohamed.boucadair@orange.com >>> >>> >> >__; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> ' >>> >> >; 'paulq@cisco.com >>> ' >> > >>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>> ' = >; >>> 'linda.dunbar@huawei.com ' >>> > >>> Subject: Re: [sfc] Framework >>> >>> I mostly agree with you Ron. I can probably come up with >>> some other variations, but your second point is that the >>> transport must deal with the issue of frame size / fit. >>> >>> I would note that if we assume that the carrying encaps >>> (IPv4/v6 outer) is being fragmented, then we are assuming >>> that the exit from service chaining can and will reassembl= e. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>> >>> Joel, >>> >>> That is an excellent point to consider when choosing >>> transport >>> encapsulations. If the transport encapsulation is IP= v4 >>> or IPv6 >>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>> etc.), then >>> fragmentation and defragmentation are naturally >>> supported. If the >>> transport encapsulation is VLAN, MPLS, etc., then I >>> believe one of the >>> following must be true: >>> >>> * The end-to-end path is known to support the resultin= g >>> larger frames >>> * A path discovery mechanism is mandated by SFC when >>> non-IP transports >>> are used * An SFC-specific fragmentation header and >>> mechanisms must be >>> defined (i.e., >>> >>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-f >>> rame) >>> >>> Ron >>> >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Sent: Thursday, February >>> 13, 2014 10:10 >>> AM To: mohamed.boucadair@orange.com >>> ; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; Ron Parker; >>> 'paulq@cisco.com ' Cc: >>> 'S.Majee@F5.com'; 'sfc@ietf.org '= ; >>> 'linda.dunbar@huawei.com >>> ' Subject: >>> Re: [sfc] Framework >>> >>> There is a related complexity. I hope that we expect t= o >>> support IPv6. >>> IPv6 explicitly prohibits network elements from >>> fragmenting end user >>> packets. >>> >>> Yours, Joel >>> >>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>> wrote: >>> >>> Re-, >>> >>> FWIW, one of the existing architecture drafts >>> includes the following >>> behavior >>> >>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec >>> tion- >>> 6 >>> >>> = ): >>> >>> >>> >>> " >>> >>> 6. Fragmentation Considerations >>> >>> If adding the Service Chaining Header would result >>> in a fragmented >>> packet, the classifier should include a Service >>> Chaining Header in >>> each fragment. Doing so would prevent SF Nodes to >>> dedicate resource >>> to handle fragments. " >>> >>> Cheers, Med >>> >>> >>> -----Message d'origine----- De : sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> De la part de Dave Dolson Envoy=E9 : >>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>> 'Nicolas.BOUTHORS@qosmos.com >>> '; >>> 'Ron_Parker@affirmednetworks.__com >>> '; >>> 'jmh@joelhalpern.com=20 >>> '; >>> 'paulq@cisco.com ' Cc = : >>> 'S.Majee@F5.com'; 'sfc@ietf.org >>> '; >>> 'linda.dunbar@huawei.com >>> ' Objet : Re: >>> [sfc] Framework >>> >>> Good point to consider fragmentation. >>> >>> We should design the encapsulation such that t= he >>> forwarding >>> functions do not need to reassemble. Each >>> fragment should be >>> independently forwardable; some SFs may choose >>> to ignore these >>> packets. >>> >>> Any layer 2.5 protocol like VLAN or MPLS would >>> support this. >>> Otherwise, a reassembly layer could be added >>> after the forwarding >>> coordinates. Think of something like the IPv6 >>> reassembly option >>> after a GRE header, for instance. >>> >>> IP | GRE | reassem | frag data >>> >>> We could alternatively mandate the inner IP be >>> fragmented and that >>> path-MTU discovery be supported. >>> >>> >>> >>> >>> ----- Original Message ----- From: Nicolas=20 >>> BOUTHORS >>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>> ] Sent: >>> Thursday, February 13, >>> 2014 04:13 AM To: Ron Parker >>> >> >; >>> Dave Dolson; Joel M. Halpern >>> >> >; Paul Quinn >>> (paulq) >> > Cc: Sumandra Majee >>> ; >>> sfc@ietf.org >> >; Linda Dunbar >>> >> > >>> Subject: Re: [sfc] Framework >>> >>> If we do not enforce a fix header size we have >>> other implication. >>> >>> There is the question of segmentation and >>> reassembly responsibility >>> as well. >>> >>> If adding length to the service header forces >>> segmentation, then >>> whose responsibility is it to reassemble the >>> payload before passing >>> it to the SF. >>> >>> Similar question for packet re-ordering. >>> >>> >>> __________________________________________ Fro= m: >>> Ron Parker >>> [Ron_Parker@affirmednetworks.__com >>> ] Sent= : >>> Wednesday, February 12, >>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern= ; >>> Paul Quinn >>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: >>> Re: [sfc] Framework >>> >>> Dave, >>> >>> Yes, that is a good point if we logically >>> separate the forwarding >>> function from the SFC-aware service function, = as >>> we should. The >>> forwarding function is concerned with only the >>> inbound transport >>> header, the fixed portion of the service head= er >>> containing the >>> chain information, and the outbound transport >>> header. The >>> service function may look at the entirety of t= he >>> service header and >>> would look at the encapsulated packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dolson >>> [mailto:ddolson@sandvine.com >>> ] Sent: Wednesday= , >>> February 12, 2014 >>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>> Quinn (paulq) Cc: >>> Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subject: R= E: >>> [sfc] >>> Framework >>> >>> The forwarding plane might not even need to lo= ok >>> at the encapsulated >>> packet. >>> >>> For example, (if the SF Identifier is a VLAN >>> tag), an Ethernet >>> switch can forward packets of the form: Ether= | >>> VLAN | BLOB. >>> >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Joel M. Halpern Sent: >>> Wednesday, February 12, 2014 4:30 PM To: Ron >>> Parker; Dave Dolson; >>> Paul Quinn (paulq) Cc: Sumandra Majee; >>> sfc@ietf.org ; Linda Dunb= ar >>> Subject: Re: [sfc] Framework >>> >>> I agree as well. Yours, Joel >>> >>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>> >>> Hi, Dave. >>> >>> I Agree with your statement. And if th= e >>> total length of the >>> header is >>> >>> contained in the mandatory portion, the hardwa= re >>> implementation can >>> easily locate the encapsulated packet. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Dave Dols= on >>> [mailto:ddolson@sandvine.com >>> ] Sent: >>> Wednesday, February 12, >>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>> (paulq) Cc: Joel M. >>> Halpern; Sumandra Majee; sfc@ietf.org >>> ; Linda Dunbar Subjec= t: >>> RE: [sfc] Framework >>> >>> I think a good approach would be: >>> >>> The information required for forwarding (t= he >>> SF Identifier) should >>> be in >>> >>> a mandatory fixed-size header. >>> >>> >>> Optional information (if any) is NOT to be >>> used for forwarding, but >>> is >>> >>> for consumption by one or more of the >>> applications in the chain. >>> >>> >>> Then the forwarding plane, and even the PD= P, >>> can be agnostic about >>> the >>> >>> meta-data. >>> >>> >>> -Dave >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of Ron Parker Sent: >>> Wednesday, February 12, 2014 4:05 PM To: >>> Paul Quinn (paulq) Cc: >>> Joel M. Halpern; Sumandra Majee; >>> sfc@ietf.org ;=20 >>> Linda Dunbar >>> Subject: Re: [sfc] Framework >>> >>> Paul, >>> >>> That is why I am proposing a hybrid where >>> extensions or options can >>> be >>> >>> added but the total length is contained in the >>> fixed portion. I >>> can envision certain deployments (e.g., >>> Enterprise) where perhaps >>> extensions are not needed and the SFC >>> functionality is realized >>> in hardware. And, I can envision certain oth= er >>> deployments >>> (e.g., 3gpp) where the extension headers add >>> sufficient value to >>> justify software based implementations. >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: Paul Quin= n >>> (paulq) >>> [mailto:paulq@cisco.com >>> ] Sent: Wednesday, >>> February 12, 2014 >>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>> Linda Dunbar; Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> Hi, >>> >>> We certainly need to be very careful with >>> variable length headers >>> when >>> >>> hardware platform are in play. >>> >>> >>> Ron, your examples of IP options and v6 EH >>> have both suffered from >>> >>> significant implementation and deployment >>> hurdles due to the >>> complexity and cost associated with hardware >>> support for the >>> option/EH. >>> >>> >>> Paul >>> >>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>> >> =20 >>> > >>> >>> wrote: >>> >>> >>> Hi, Sumandra. >>> >>> Regarding service header flexibility, = I >>> completely agree. I >>> might >>> >>> suggest a compromise between hardware >>> friendliness and software >>> flexibility. If the header had the ability = to >>> add extensions >>> (perhaps similar to IPv6) but also had the >>> header length encoded in >>> the mandatory part (like IPv4), then a hardwar= e >>> implementation would >>> be free to skip over the extensions (in cases >>> where the deployment >>> justifies ignoring the extensions). >>> >>> >>> Ron >>> >>> >>> -----Original Message----- From: >>> Sumandra Majee >>> [mailto:S.Majee@F5.com >>> ] Sent: >>> Wednesday, February 12, 2014 >>> 3:04 PM To: Ron Parker; Linda Dunbar; >>> Joel M. Halpern; >>> sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> For all of those reasons, I >>> strongly support a=20 >>> canonical service >>> header that is independent of >>> the transport methodology. >>> >>> >>> >>> I agree. However the format of service >>> header should be >>> standardized in >>> >>> a way that is flexible. Some of us would like = to >>> see variable length >>> header that is also HW friendly. The service >>> header can be >>> represented as a mandotory fixed length header >>> (like IP >>> header) along with an optional variable length >>> attribute field. >>> Different services can be interested in >>> different metadata, for >>> example subscriber ID could be of interest in >>> the mobile core >>> service chain only. >>> >>> >>> Sumandra >>> >>> On 2/12/14, 11:32 AM, "Ron Parker" >>> >> >>> > >>> >>> wrote: >>> >>> >>> Linda, >>> >>> My interpretation of the >>> architecture docs is that the=20 >>> service >>> function chain is built in an >>> abstract manner (i.e., SF-A then >>> SF-B >>> >>> then SF-C). >>> >>> Separately, a locator table provid= es >>> network location for >>> each of those service functions. >>> In this way, you can >>> locate the service functions >>> >>> in >>> >>> a manner appropriate to the type o= f >>> transport you are >>> using. If you want that to be >>> interface+VLAN, >>> gateway-IP+MPLS label stack, IP >>> >>> address, >>> >>> GRE tunnel remote IP + key, etc., >>> you can do that. You >>> can even potentially locate >>> different service functions that >>> reside in the same chain with >>> different flavors of >>> network locators. Another >>> justification to separate the >>> identity of a service function fro= m >>> its network location is >>> load balancing. If, for example, >>> SF-A had 3 IP addresses, >>> that would imply load balancing to= 3 >>> instances using IP as a >>> transport layer. >>> >>> For all of those reasons, I strong= ly >>> support a canonical service >>> header that is independent of the >>> transport >>> methodology. At a particular >>> node, the decision as to >>> where to go next should be based >>> solely on information carried in >>> the canonical service header and n= ot >>> on the >>> >>> fields >>> >>> in the transport header. That is= , >>> the SFC node discards >>> the transport header and extracts >>> the chain ID from the >>> service header. Through >>> mechanisms we have not yet begun >>> to discuss, the SFC node knows how >>> to interpret the chain ID and >>> ultimately how to progress the=20 >>> packet. >>> >>> Ron >>> >>> >>> -----Original Message----- From: s= fc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Linda Dunbar >>> Sent: Wednesday, February 12, 2014 >>> 12:01 PM To: Joel M. >>> Halpern; sfc@ietf.org >>> Subject: Re: >>> [sfc] Framework >>> >>> Agree with Joel's statement. >>> >>> I think a simple sentence below >>> should be added Section 5.2 (SFC >>> Classifier) to emphasize this poin= t. >>> >>> "A Service Chain Classifier node c= an >>> associate a unique Layer 2 >>> or 3 Label (e.g. VLAN, MPLS label) >>> to the packets in the flow. >>> Those Layer 2 or 3 Label makes it >>> easier for subsequent nodes >>> along the flow path to steer the >>> flow to the service functions >>> specified by the flow's service=20 >>> chain." >>> >>> >>> Linda -----Original Message----- >>> From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of Joel M. Halpern >>> Sent: Wednesday, February 12, 2014 >>> 10:20 AM To: >>> sfc@ietf.org >>> Subject: [sfc] Framework >>> >>> I was looking at the framework >>> proposal. The proposal has a very >>> specific model of the scope of the >>> transport header (that it is >>> derived from, and relates only to, >>> the first service function to >>> which the packet will be directed. >>> That is clearly an operational >>> model we need to support. >>> >>> However, I would like to allow oth= er >>> transport operational >>> models, such as the use of a VLAN = to >>> direct traffic along a >>> chain. Or the use of an MPLS labe= l, >>> or an MPLS label stack. >>> >>> Yours, Joel M. Halpern >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> https://www.ietf.org/mailman/__listinfo/sfc >>> >>> >>> >>> >>> _________________________________________________ >>> sfc mailing list >>> sfc@ietf.org=20 >>> >>> >>> 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/sf= c >>> =20 >>> >>> >>> >>> >>> _________________________________________________ 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 >>> >>> >>> >>> >>> >>> >>> _________________________________________________ >>> 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 Feb 13 11:38:24 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6E1A0421 for ; Thu, 13 Feb 2014 11:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtYHviAoXzW4 for ; Thu, 13 Feb 2014 11:38:17 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7C1A03FA for ; Thu, 13 Feb 2014 11:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39590; q=dns/txt; s=iport; t=1392320296; x=1393529896; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=E9XVu+OOJWxSCbH6kfe2kbWnGW0lpbmUOD+coW17pzM=; b=QgNR5UQBocTyUYuZgyt7oQjA2dGcDrfavmdFsF3GWr196Yp5AiV3COex hgAlcppA83mtVoUqcxxZxb6/RQUtlJgVMuqb3W/nO/R95uQLb/YlTMOKF SALepunExmec2a/N4kOIJ+lBdk6rvF+Ns5zSauPwo3hiKpmdpq9RzJZBV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKke/VKtJV2Z/2dsb2JhbABQCYMGOFe/ToEaFnSCJQEBAQQBAQEXSwIHFwYBCBEBAwEBAScoBgsUAwYIAgQBEodxAxENvxUNiDwXjF+BPzAyAgSEMgSJEI0wgWyBMosshUWDLYIq X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="20279283" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 13 Feb 2014 19:38:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1DJcFXU017213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 19:38:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 13:38:14 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKOsjqfPMMzky7EWt5S69NDqHNJqz8o8A//98BACAAIflgP//fG6A Date: Thu, 13 Feb 2014 19:38:13 +0000 Message-ID: In-Reply-To: <52FD1D03.9030905@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.125.214] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <54055621D93E4E4EBF2A0D52D47AF984@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_wvaM6POn41RyxOSIAC2OAm0-Jg Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:38:23 -0000 On 2/13/14, 11:29 AM, "Joel M. Halpern" wrote: >As I understand it, the tsvwg (and aeon) work is about flow metadata. >That is long-lived metadata of use across many packets. That does >indeed seem well-suited to out-of-band cases. > >My concern is that in SFC, there are many cases which are at best >badly-addressed if we insist that they be solved using out-of-band >metadata. [RP] The draft only describes the encoding and framework which can be used in and out of band. > >Yours, >Joel > >On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >> There is draft about transport independent metadata. >> >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01 >> >> The complexities you mention are discussed there: variable-encoding, >> direction, security of metadata, etc. >> >> Thanks, >> >> -RP >> >> >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >> >>> While there are cases where out-of-band metadata makes sense, There are >>> many cases I would not want to try to cover that way. The best >>>examples >>> are situations where the metadata changes from packet to packet (such >>>as >>> the data produced by a DPI engine for consumption by other applications >>> in the chain.) >>> >>> More importantly, if you are putting correlators in the packet, it is >>> still very complex if you want to use one correlator to handle metadata >>> produced by several different entities (the initial classifer, the DPI >>> engine, ...) You quickly end up deciding that you need several >>> correlators. At which point we are back to variable amounts of >>>metadata. >>> >>> The alternative is to require exceedingly specific and strong coupling >>> to a mandated out-of-band mechanism. That seems to me to be a very bad >>> idea. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>> resend to avoid "too many recipients" warning >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >>> > wrote: >>>> >>>> There are ways to signal variable length amounts of metadata >>>>without >>>> needing an additional variable-length header on each data packet. >>>> >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of >>>>the >>>> possible approaches: out-of-band signaling (congruent or >>>> non-congruent) or a hybrid approach using a fix-length in-band >>>> correlator and out-of-band additional metadata. See sections >>>>3.3, >>>> 3.4 and 3.5 in the draft. >>>> >>>> The issue of fixed-length encoding versus variable length >>>>encoding >>>> is discussion in the challenges chapter in section 4.3. I should >>>> probably mention the MTU and segmentation issues as well in that >>>> section. >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>> > wrote: >>>> >>>> The variable length shim header is needed even if every >>>> individual piece of metadata has a fixed length. Different >>>> service chains will need different combinations of metadata. >>>> So >>>> the metadata portion of the header needs to be variable >>>>length. >>>> >>>> I think the approach of a fixed length initial part, and a >>>> variable length extension part, is the right model. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>> >>>> Yes, fragmentation and variable headers are usually a >>>>really >>>> bad thing for forwarding performance. Let's not forget >>>>that >>>> we live in a 100G-ish kind of world nowadays. >>>> >>>> Now the question should be: WHY would we want to do that >>>> (variable headers leading to fragmentation issues)? >>>> >>>> For example, the type of metadata that may require >>>> variable-length fields might be a better candidate for >>>>some >>>> out-of-band signaling mechanism. If this is service >>>> authorization data (e.g. a service profile/policy), this >>>> sounds likely. Not 100% sure this is true for all use >>>>cases >>>> though. Only a good understanding of use cases, grounded >>>>by >>>> reflecting on existing network architectures (notably >>>> broadband, fixed or mobile), would tell us if one >>>>approach >>>> or another is the most appropriate. >>>> >>>> Anyhoo, we're jumping way deep in the detailed protocol >>>> design here. This seems a tad premature. >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org >>>> ] On Behalf Of Dave Dolson >>>> Sent: Thursday, February 13, 2014 11:03 AM >>>> To: 'jmh@joelhalpern.com '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'mohamed.boucadair@orange.com >>>> '__; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; 'paulq@cisco.com >>>> ' >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org >>>>'; >>>> 'linda.dunbar@huawei.com >>>>' >>>> Subject: Re: [sfc] Framework >>>> >>>> it is overall more efficient to support PMTU discovery >>>> rather than fragmenting every large packet. The is why >>>>TCP >>>> adopted it so early on. >>>> >>>> The fragmenting also puts huge performance burden on the >>>> service functions. >>>> Fragmenting may also affect the ability of load >>>>balancers to >>>> get each fragment to the correct destination. >>>> >>>> So PMTU discovery SHOULD be used, in my opinion. By this >>>>I >>>> mean the client or server is informed that its packets >>>>are >>>> too big (for IPv6 or IPv4 with DF=3D1). >>>> >>>> Some operators may wish to incur the extra cost to hide >>>>the >>>> existence of the tunneling, when the elements of the >>>>chain >>>> can support it, so we could consider that as an optional >>>> mechanism. >>>> >>>> -Dave >>>> >>>> >>>> ----- Original Message ----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>> ] >>>> Sent: Thursday, February 13, 2014 10:31 AM >>>> To: Ron Parker >>> >; >>>> mohamed.boucadair@orange.com >>>> >>>> >>> >__; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> ' >>>> >>> >; 'paulq@cisco.com >>>> ' >>> > >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>> ' >>>>; >>>> 'linda.dunbar@huawei.com >>>>' >>>> >>>> >>>> Subject: Re: [sfc] Framework >>>> >>>> I mostly agree with you Ron. I can probably come up with >>>> some other variations, but your second point is that the >>>> transport must deal with the issue of frame size / fit. >>>> >>>> I would note that if we assume that the carrying encaps >>>> (IPv4/v6 outer) is being fragmented, then we are assuming >>>> that the exit from service chaining can and will >>>>reassemble. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>> >>>> Joel, >>>> >>>> That is an excellent point to consider when choosing >>>> transport >>>> encapsulations. If the transport encapsulation is >>>>IPv4 >>>> or IPv6 >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), >>>> then >>>> fragmentation and defragmentation are naturally >>>> supported. If the >>>> transport encapsulation is VLAN, MPLS, etc., then I >>>> believe one of the >>>> following must be true: >>>> >>>> * The end-to-end path is known to support the >>>>resulting >>>> larger frames >>>> * A path discovery mechanism is mandated by SFC when >>>> non-IP transports >>>> are used * An SFC-specific fragmentation header and >>>> mechanisms must be >>>> defined (i.e., >>>> >>>>=20 >>>>SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-fram >>>>e) >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com >>>> ] Sent: Thursday, >>>>February >>>> 13, 2014 10:10 >>>> AM To: mohamed.boucadair@orange.com >>>> ; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; Ron Parker; >>>> 'paulq@cisco.com ' Cc: >>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>'; >>>> 'linda.dunbar@huawei.com >>>> ' Subject: >>>> Re: [sfc] Framework >>>> >>>> There is a related complexity. I hope that we expect >>>>to >>>> support IPv6. >>>> IPv6 explicitly prohibits network elements from >>>> fragmenting end user >>>> packets. >>>> >>>> Yours, Joel >>>> >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>> wrote: >>>> >>>> Re-, >>>> >>>> FWIW, one of the existing architecture drafts >>>> includes the following >>>> behavior >>>> >>>>=20 >>>>(http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sectio >>>>n- >>>> 6 >>>> >>>>=20 >>>> >>>>): >>>> >>>> >>>> >>>> " >>>> >>>> 6. Fragmentation Considerations >>>> >>>> If adding the Service Chaining Header would >>>>result >>>> in a fragmented >>>> packet, the classifier should include a Service >>>> Chaining Header in >>>> each fragment. Doing so would prevent SF Nodes >>>>to >>>> dedicate resource >>>> to handle fragments. " >>>> >>>> Cheers, Med >>>> >>>> >>>> -----Message d'origine----- De : sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> De la part de Dave Dolson Envoy=E9 : >>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'jmh@joelhalpern.com >>>> '; >>>> 'paulq@cisco.com ' >>>>Cc : >>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>> '; >>>> 'linda.dunbar@huawei.com >>>> ' Objet : Re: >>>> [sfc] Framework >>>> >>>> Good point to consider fragmentation. >>>> >>>> We should design the encapsulation such that >>>>the >>>> forwarding >>>> functions do not need to reassemble. Each >>>> fragment should be >>>> independently forwardable; some SFs may >>>>choose >>>> to ignore these >>>> packets. >>>> >>>> Any layer 2.5 protocol like VLAN or MPLS >>>>would >>>> support this. >>>> Otherwise, a reassembly layer could be added >>>> after the forwarding >>>> coordinates. Think of something like the IPv6 >>>> reassembly option >>>> after a GRE header, for instance. >>>> >>>> IP | GRE | reassem | frag data >>>> >>>> We could alternatively mandate the inner IP >>>>be >>>> fragmented and that >>>> path-MTU discovery be supported. >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- From: Nicolas >>>> BOUTHORS >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>> ] Sent: >>>> Thursday, February 13, >>>> 2014 04:13 AM To: Ron Parker >>>> >>> >; >>>> Dave Dolson; Joel M. Halpern >>>> >>> >; Paul Quinn >>>> (paulq) >>> > Cc: Sumandra Majee >>>> ; >>>> sfc@ietf.org >>>>>>> >; Linda Dunbar >>>> >>> > >>>> Subject: Re: [sfc] Framework >>>> >>>> If we do not enforce a fix header size we >>>>have >>>> other implication. >>>> >>>> There is the question of segmentation and >>>> reassembly responsibility >>>> as well. >>>> >>>> If adding length to the service header forces >>>> segmentation, then >>>> whose responsibility is it to reassemble the >>>> payload before passing >>>> it to the SF. >>>> >>>> Similar question for packet re-ordering. >>>> >>>> >>>> __________________________________________ >>>>From: >>>> Ron Parker >>>> [Ron_Parker@affirmednetworks.__com >>>> ] >>>>Sent: >>>> Wednesday, February 12, >>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>Halpern; >>>> Paul Quinn >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: >>>> Re: [sfc] Framework >>>> >>>> Dave, >>>> >>>> Yes, that is a good point if we logically >>>> separate the forwarding >>>> function from the SFC-aware service >>>>function, as >>>> we should. The >>>> forwarding function is concerned with only >>>>the >>>> inbound transport >>>> header, the fixed portion of the service >>>>header >>>> containing the >>>> chain information, and the outbound transport >>>> header. The >>>> service function may look at the entirety of >>>>the >>>> service header and >>>> would look at the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: >>>>Wednesday, >>>> February 12, 2014 >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>>> Quinn (paulq) Cc: >>>> Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: >>>>RE: >>>> [sfc] >>>> Framework >>>> >>>> The forwarding plane might not even need to >>>>look >>>> at the encapsulated >>>> packet. >>>> >>>> For example, (if the SF Identifier is a VLAN >>>> tag), an Ethernet >>>> switch can forward packets of the form: >>>>Ether | >>>> VLAN | BLOB. >>>> >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Joel M. Halpern Sent: >>>> Wednesday, February 12, 2014 4:30 PM To: Ron >>>> Parker; Dave Dolson; >>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>> sfc@ietf.org ; Linda >>>>Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> I agree as well. Yours, Joel >>>> >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if >>>>the >>>> total length of the >>>> header is >>>> >>>> contained in the mandatory portion, the >>>>hardware >>>> implementation can >>>> easily locate the encapsulated packet. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave >>>>Dolson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: >>>> Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>>> (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar >>>>Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding >>>>(the >>>> SF Identifier) should >>>> be in >>>> >>>> a mandatory fixed-size header. >>>> >>>> >>>> Optional information (if any) is NOT to >>>>be >>>> used for forwarding, but >>>> is >>>> >>>> for consumption by one or more of the >>>> applications in the chain. >>>> >>>> >>>> Then the forwarding plane, and even the >>>>PDP, >>>> can be agnostic about >>>> the >>>> >>>> meta-data. >>>> >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: >>>> Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; >>>> sfc@ietf.org ; Linda >>>> Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where >>>> extensions or options can >>>> be >>>> >>>> added but the total length is contained in >>>>the >>>> fixed portion. I >>>> can envision certain deployments (e.g., >>>> Enterprise) where perhaps >>>> extensions are not needed and the SFC >>>> functionality is realized >>>> in hardware. And, I can envision certain >>>>other >>>> deployments >>>> (e.g., 3gpp) where the extension headers add >>>> sufficient value to >>>> justify software based implementations. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul >>>>Quinn >>>> (paulq) >>>> [mailto:paulq@cisco.com >>>> ] Sent: >>>>Wednesday, >>>> February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra >>>>Majee; >>>> Linda Dunbar; Joel M. >>>> Halpern; sfc@ietf.org >>>> >>>> Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with >>>> variable length headers >>>> when >>>> >>>> hardware platform are in play. >>>> >>>> >>>> Ron, your examples of IP options and v6 >>>>EH >>>> have both suffered from >>>> >>>> significant implementation and deployment >>>> hurdles due to the >>>> complexity and cost associated with hardware >>>> support for the >>>> option/EH. >>>> >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> > >>>> >>>> wrote: >>>> >>>> >>>> Hi, Sumandra. >>>> >>>> Regarding service header >>>>flexibility, I >>>> completely agree. I >>>> might >>>> >>>> suggest a compromise between hardware >>>> friendliness and software >>>> flexibility. If the header had the >>>>ability to >>>> add extensions >>>> (perhaps similar to IPv6) but also had the >>>> header length encoded in >>>> the mandatory part (like IPv4), then a >>>>hardware >>>> implementation would >>>> be free to skip over the extensions (in cases >>>> where the deployment >>>> justifies ignoring the extensions). >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: >>>> Sumandra Majee >>>> [mailto:S.Majee@F5.com >>>> ] Sent: >>>> Wednesday, February 12, 2014 >>>> 3:04 PM To: Ron Parker; Linda Dunbar; >>>> Joel M. Halpern; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> For all of those reasons, I >>>> strongly support a canonical >>>> service >>>> header that is independent of >>>> the transport methodology. >>>> >>>> >>>> >>>> I agree. However the format of >>>>service >>>> header should be >>>> standardized in >>>> >>>> a way that is flexible. Some of us would >>>>like to >>>> see variable length >>>> header that is also HW friendly. The service >>>> header can be >>>> represented as a mandotory fixed length >>>>header >>>> (like IP >>>> header) along with an optional variable >>>>length >>>> attribute field. >>>> Different services can be interested in >>>> different metadata, for >>>> example subscriber ID could be of interest in >>>> the mobile core >>>> service chain only. >>>> >>>> >>>> Sumandra >>>> >>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>> >>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> Linda, >>>> >>>> My interpretation of the >>>> architecture docs is that the >>>> service >>>> function chain is built in an >>>> abstract manner (i.e., SF-A then >>>> SF-B >>>> >>>> then SF-C). >>>> >>>> Separately, a locator table >>>>provides >>>> network location for >>>> each of those service functions. >>>> In this way, you can >>>> locate the service functions >>>> >>>> in >>>> >>>> a manner appropriate to the type >>>>of >>>> transport you are >>>> using. If you want that to be >>>> interface+VLAN, >>>> gateway-IP+MPLS label stack, IP >>>> >>>> address, >>>> >>>> GRE tunnel remote IP + key, etc., >>>> you can do that. You >>>> can even potentially locate >>>> different service functions that >>>> reside in the same chain with >>>> different flavors of >>>> network locators. Another >>>> justification to separate the >>>> identity of a service function >>>>from >>>> its network location is >>>> load balancing. If, for >>>>example, >>>> SF-A had 3 IP addresses, >>>> that would imply load balancing >>>>to 3 >>>> instances using IP as a >>>> transport layer. >>>> >>>> For all of those reasons, I >>>>strongly >>>> support a canonical service >>>> header that is independent of the >>>> transport >>>> methodology. At a particular >>>> node, the decision as to >>>> where to go next should be based >>>> solely on information carried in >>>> the canonical service header and >>>>not >>>> on the >>>> >>>> fields >>>> >>>> in the transport header. That >>>>is, >>>> the SFC node discards >>>> the transport header and extracts >>>> the chain ID from the >>>> service header. Through >>>> mechanisms we have not yet begun >>>> to discuss, the SFC node knows >>>>how >>>> to interpret the chain ID and >>>> ultimately how to progress the >>>> packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: >>>>sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] On >>>> Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, >>>>2014 >>>> 12:01 PM To: Joel M. >>>> Halpern; sfc@ietf.org >>>> Subject: >>>>Re: >>>> [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below >>>> should be added Section 5.2 (SFC >>>> Classifier) to emphasize this >>>>point. >>>> >>>> "A Service Chain Classifier node >>>>can >>>> associate a unique Layer 2 >>>> or 3 Label (e.g. VLAN, MPLS=20 >>>>label) >>>> to the packets in the flow. >>>> Those Layer 2 or 3 Label makes it >>>> easier for subsequent nodes >>>> along the flow path to steer the >>>> flow to the service functions >>>> specified by the flow's service >>>> chain." >>>> >>>> >>>> Linda -----Original Message----- >>>> From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] On >>>> Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12,=20 >>>>2014 >>>> 10:20 AM To: >>>> sfc@ietf.org=20 >>>> >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework >>>> proposal. The proposal has a very >>>> specific model of the scope of=20 >>>>the >>>> transport header (that it is >>>> derived from, and relates only=20 >>>>to, >>>> the first service function to >>>> which the packet will be=20 >>>>directed. >>>> That is clearly an operational >>>> model we need to support. >>>> >>>> However, I would like to allow=20 >>>>other >>>> transport operational >>>> models, such as the use of a=20 >>>>VLAN to >>>> direct traffic along a >>>> chain. Or the use of an MPLS=20 >>>>label, >>>> or an MPLS label stack. >>>> >>>> Yours, Joel M. Halpern >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> 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 >>>> =20 >>>>https://www.ietf.org/mailman/__listinfo/sfc >>>> =20 >>>> >>>> >>>> >>>> >>>> _________________________________________________ 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> 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 Feb 13 11:51:48 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578AB1A0449 for ; Thu, 13 Feb 2014 11:51:38 -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 Dm_NpnCmHL28 for ; Thu, 13 Feb 2014 11:51:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED51A0436 for ; Thu, 13 Feb 2014 11:51:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id AF44646033E; Thu, 13 Feb 2014 11:51:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 59059460329; Thu, 13 Feb 2014 11:51:29 -0800 (PST) Message-ID: <52FD2249.9020802@joelhalpern.com> Date: Thu, 13 Feb 2014 14:51:37 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jerome Moisand , "sfc@ietf.org" References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/X_cCdCDWmcl1o9J69eZGh4yJFdU Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:51:38 -0000 I know very well what GTP does in terms of correlators, and why. If all you need is an identifier for the subscriber, carrying a short identifier, and using it to select the desired behavior that has been pre-populated when the subscribers session starts works really well. That is part of why I am not objecting to having provision for out-of-band metadata. However, claiming that a single such correlator is all that is needed for even 80% of SFC cases (and I very much supporting trying to focus on the 80% cases), just does not seem to work, given the broad range of requirements that we have seen. Yours, Joel On 2/13/14, 2:35 PM, Jerome Moisand wrote: > Joel, > > Protocols like GTP and L2TP work exactly that, with a form of session correlator between the data plane and the control plane. This is very handy for subscriber and service management. Also if a correlator is defined as an opaque and unique number, then one can avoid some of the pitfalls you described. Long-lived metadata is clearly useful (and thanks for sharing, Reinaldo, will read), and there is clear applicability to various service chaining needs. > > Now this is just one way. The I-D Bruno referred to was just listing this approach as one possible way among others. I totally agree with you that other forms of metadata (like an outcome of the classification of a packet or a sequence of a few packets) may not be suitable for out-of-band signaling. > > Bottomline seems to be that we have too many options to choose from, and none of them solving it all... Tough. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, February 13, 2014 2:29 PM > To: sfc@ietf.org > Subject: Re: [sfc] Framework > > As I understand it, the tsvwg (and aeon) work is about flow metadata. > That is long-lived metadata of use across many packets. That does indeed seem well-suited to out-of-band cases. > > My concern is that in SFC, there are many cases which are at best badly-addressed if we insist that they be solved using out-of-band metadata. > > Yours, > Joel > > On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >> There is draft about transport independent metadata. >> >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding- >> 01 >> >> The complexities you mention are discussed there: variable-encoding, >> direction, security of metadata, etc. >> >> Thanks, >> >> -RP >> >> >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >> >>> While there are cases where out-of-band metadata makes sense, There >>> are many cases I would not want to try to cover that way. The best >>> examples are situations where the metadata changes from packet to >>> packet (such as the data produced by a DPI engine for consumption by >>> other applications in the chain.) >>> >>> More importantly, if you are putting correlators in the packet, it is >>> still very complex if you want to use one correlator to handle >>> metadata produced by several different entities (the initial >>> classifer, the DPI engine, ...) You quickly end up deciding that you >>> need several correlators. At which point we are back to variable amounts of metadata. >>> >>> The alternative is to require exceedingly specific and strong >>> coupling to a mandated out-of-band mechanism. That seems to me to be >>> a very bad idea. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>> resend to avoid "too many recipients" warning >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >>>> > wrote: >>>> >>>> There are ways to signal variable length amounts of metadata without >>>> needing an additional variable-length header on each data packet. >>>> >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >>>> possible approaches: out-of-band signaling (congruent or >>>> non-congruent) or a hybrid approach using a fix-length in-band >>>> correlator and out-of-band additional metadata. See sections 3.3, >>>> 3.4 and 3.5 in the draft. >>>> >>>> The issue of fixed-length encoding versus variable length encoding >>>> is discussion in the challenges chapter in section 4.3. I should >>>> probably mention the MTU and segmentation issues as well in that >>>> section. >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>> > wrote: >>>> >>>> The variable length shim header is needed even if every >>>> individual piece of metadata has a fixed length. Different >>>> service chains will need different combinations of metadata. So >>>> the metadata portion of the header needs to be variable length. >>>> >>>> I think the approach of a fixed length initial part, and a >>>> variable length extension part, is the right model. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>> >>>> Yes, fragmentation and variable headers are usually a really >>>> bad thing for forwarding performance. Let's not forget that >>>> we live in a 100G-ish kind of world nowadays. >>>> >>>> Now the question should be: WHY would we want to do that >>>> (variable headers leading to fragmentation issues)? >>>> >>>> For example, the type of metadata that may require >>>> variable-length fields might be a better candidate for some >>>> out-of-band signaling mechanism. If this is service >>>> authorization data (e.g. a service profile/policy), this >>>> sounds likely. Not 100% sure this is true for all use cases >>>> though. Only a good understanding of use cases, grounded by >>>> reflecting on existing network architectures (notably >>>> broadband, fixed or mobile), would tell us if one approach >>>> or another is the most appropriate. >>>> >>>> Anyhoo, we're jumping way deep in the detailed protocol >>>> design here. This seems a tad premature. >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org >>>> ] On Behalf Of Dave Dolson >>>> Sent: Thursday, February 13, 2014 11:03 AM >>>> To: 'jmh@joelhalpern.com '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'mohamed.boucadair@orange.com >>>> '__; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; 'paulq@cisco.com >>>> ' >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>> 'linda.dunbar@huawei.com ' >>>> Subject: Re: [sfc] Framework >>>> >>>> it is overall more efficient to support PMTU discovery >>>> rather than fragmenting every large packet. The is why TCP >>>> adopted it so early on. >>>> >>>> The fragmenting also puts huge performance burden on the >>>> service functions. >>>> Fragmenting may also affect the ability of load balancers to >>>> get each fragment to the correct destination. >>>> >>>> So PMTU discovery SHOULD be used, in my opinion. By this I >>>> mean the client or server is informed that its packets are >>>> too big (for IPv6 or IPv4 with DF=1). >>>> >>>> Some operators may wish to incur the extra cost to hide the >>>> existence of the tunneling, when the elements of the chain >>>> can support it, so we could consider that as an optional >>>> mechanism. >>>> >>>> -Dave >>>> >>>> >>>> ----- Original Message ----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>> ] >>>> Sent: Thursday, February 13, 2014 10:31 AM >>>> To: Ron Parker >>> >; >>>> mohamed.boucadair@orange.com >>>> >>>> >>> >__; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> ' >>>> >>> >; 'paulq@cisco.com >>>> ' >>> > >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>> ' >; >>>> 'linda.dunbar@huawei.com ' >>>> > >>>> Subject: Re: [sfc] Framework >>>> >>>> I mostly agree with you Ron. I can probably come up with >>>> some other variations, but your second point is that the >>>> transport must deal with the issue of frame size / fit. >>>> >>>> I would note that if we assume that the carrying encaps >>>> (IPv4/v6 outer) is being fragmented, then we are assuming >>>> that the exit from service chaining can and will reassemble. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>> >>>> Joel, >>>> >>>> That is an excellent point to consider when choosing >>>> transport >>>> encapsulations. If the transport encapsulation is IPv4 >>>> or IPv6 >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, >>>> etc.), then >>>> fragmentation and defragmentation are naturally >>>> supported. If the >>>> transport encapsulation is VLAN, MPLS, etc., then I >>>> believe one of the >>>> following must be true: >>>> >>>> * The end-to-end path is known to support the resulting >>>> larger frames >>>> * A path discovery mechanism is mandated by SFC when >>>> non-IP transports >>>> are used * An SFC-specific fragmentation header and >>>> mechanisms must be >>>> defined (i.e., >>>> >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-f >>>> rame) >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com >>>> ] Sent: Thursday, February >>>> 13, 2014 10:10 >>>> AM To: mohamed.boucadair@orange.com >>>> ; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; Ron Parker; >>>> 'paulq@cisco.com ' Cc: >>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>> 'linda.dunbar@huawei.com >>>> ' Subject: >>>> Re: [sfc] Framework >>>> >>>> There is a related complexity. I hope that we expect to >>>> support IPv6. >>>> IPv6 explicitly prohibits network elements from >>>> fragmenting end user >>>> packets. >>>> >>>> Yours, Joel >>>> >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>> wrote: >>>> >>>> Re-, >>>> >>>> FWIW, one of the existing architecture drafts >>>> includes the following >>>> behavior >>>> >>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec >>>> tion- >>>> 6 >>>> >>>> ): >>>> >>>> >>>> >>>> " >>>> >>>> 6. Fragmentation Considerations >>>> >>>> If adding the Service Chaining Header would result >>>> in a fragmented >>>> packet, the classifier should include a Service >>>> Chaining Header in >>>> each fragment. Doing so would prevent SF Nodes to >>>> dedicate resource >>>> to handle fragments. " >>>> >>>> Cheers, Med >>>> >>>> >>>> -----Message d'origine----- De : sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> De la part de Dave Dolson Envoyé : >>>> jeudi 13 février 2014 13:39 À : >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'jmh@joelhalpern.com >>>> '; >>>> 'paulq@cisco.com ' Cc : >>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>> '; >>>> 'linda.dunbar@huawei.com >>>> ' Objet : Re: >>>> [sfc] Framework >>>> >>>> Good point to consider fragmentation. >>>> >>>> We should design the encapsulation such that the >>>> forwarding >>>> functions do not need to reassemble. Each >>>> fragment should be >>>> independently forwardable; some SFs may choose >>>> to ignore these >>>> packets. >>>> >>>> Any layer 2.5 protocol like VLAN or MPLS would >>>> support this. >>>> Otherwise, a reassembly layer could be added >>>> after the forwarding >>>> coordinates. Think of something like the IPv6 >>>> reassembly option >>>> after a GRE header, for instance. >>>> >>>> IP | GRE | reassem | frag data >>>> >>>> We could alternatively mandate the inner IP be >>>> fragmented and that >>>> path-MTU discovery be supported. >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- From: Nicolas >>>> BOUTHORS >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>> ] Sent: >>>> Thursday, February 13, >>>> 2014 04:13 AM To: Ron Parker >>>> >>> >; >>>> Dave Dolson; Joel M. Halpern >>>> >>> >; Paul Quinn >>>> (paulq) >>> > Cc: Sumandra Majee >>>> ; >>>> sfc@ietf.org >>> >; Linda Dunbar >>>> >>> > >>>> Subject: Re: [sfc] Framework >>>> >>>> If we do not enforce a fix header size we have >>>> other implication. >>>> >>>> There is the question of segmentation and >>>> reassembly responsibility >>>> as well. >>>> >>>> If adding length to the service header forces >>>> segmentation, then >>>> whose responsibility is it to reassemble the >>>> payload before passing >>>> it to the SF. >>>> >>>> Similar question for packet re-ordering. >>>> >>>> >>>> __________________________________________ From: >>>> Ron Parker >>>> [Ron_Parker@affirmednetworks.__com >>>> ] Sent: >>>> Wednesday, February 12, >>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; >>>> Paul Quinn >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: >>>> Re: [sfc] Framework >>>> >>>> Dave, >>>> >>>> Yes, that is a good point if we logically >>>> separate the forwarding >>>> function from the SFC-aware service function, as >>>> we should. The >>>> forwarding function is concerned with only the >>>> inbound transport >>>> header, the fixed portion of the service header >>>> containing the >>>> chain information, and the outbound transport >>>> header. The >>>> service function may look at the entirety of the >>>> service header and >>>> would look at the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: Wednesday, >>>> February 12, 2014 >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>>> Quinn (paulq) Cc: >>>> Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: RE: >>>> [sfc] >>>> Framework >>>> >>>> The forwarding plane might not even need to look >>>> at the encapsulated >>>> packet. >>>> >>>> For example, (if the SF Identifier is a VLAN >>>> tag), an Ethernet >>>> switch can forward packets of the form: Ether | >>>> VLAN | BLOB. >>>> >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Joel M. Halpern Sent: >>>> Wednesday, February 12, 2014 4:30 PM To: Ron >>>> Parker; Dave Dolson; >>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>> sfc@ietf.org ; Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> I agree as well. Yours, Joel >>>> >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if the >>>> total length of the >>>> header is >>>> >>>> contained in the mandatory portion, the hardware >>>> implementation can >>>> easily locate the encapsulated packet. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: >>>> Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>>> (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding (the >>>> SF Identifier) should >>>> be in >>>> >>>> a mandatory fixed-size header. >>>> >>>> >>>> Optional information (if any) is NOT to be >>>> used for forwarding, but >>>> is >>>> >>>> for consumption by one or more of the >>>> applications in the chain. >>>> >>>> >>>> Then the forwarding plane, and even the PDP, >>>> can be agnostic about >>>> the >>>> >>>> meta-data. >>>> >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: >>>> Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; >>>> sfc@ietf.org ; >>>> Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid where >>>> extensions or options can >>>> be >>>> >>>> added but the total length is contained in the >>>> fixed portion. I >>>> can envision certain deployments (e.g., >>>> Enterprise) where perhaps >>>> extensions are not needed and the SFC >>>> functionality is realized >>>> in hardware. And, I can envision certain other >>>> deployments >>>> (e.g., 3gpp) where the extension headers add >>>> sufficient value to >>>> justify software based implementations. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Quinn >>>> (paulq) >>>> [mailto:paulq@cisco.com >>>> ] Sent: Wednesday, >>>> February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>>> Linda Dunbar; Joel M. >>>> Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful with >>>> variable length headers >>>> when >>>> >>>> hardware platform are in play. >>>> >>>> >>>> Ron, your examples of IP options and v6 EH >>>> have both suffered from >>>> >>>> significant implementation and deployment >>>> hurdles due to the >>>> complexity and cost associated with hardware >>>> support for the >>>> option/EH. >>>> >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> Hi, Sumandra. >>>> >>>> Regarding service header flexibility, I >>>> completely agree. I >>>> might >>>> >>>> suggest a compromise between hardware >>>> friendliness and software >>>> flexibility. If the header had the ability to >>>> add extensions >>>> (perhaps similar to IPv6) but also had the >>>> header length encoded in >>>> the mandatory part (like IPv4), then a hardware >>>> implementation would >>>> be free to skip over the extensions (in cases >>>> where the deployment >>>> justifies ignoring the extensions). >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: >>>> Sumandra Majee >>>> [mailto:S.Majee@F5.com >>>> ] Sent: >>>> Wednesday, February 12, 2014 >>>> 3:04 PM To: Ron Parker; Linda Dunbar; >>>> Joel M. Halpern; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> For all of those reasons, I >>>> strongly support a >>>> canonical service >>>> header that is independent of >>>> the transport methodology. >>>> >>>> >>>> >>>> I agree. However the format of service >>>> header should be >>>> standardized in >>>> >>>> a way that is flexible. Some of us would like to >>>> see variable length >>>> header that is also HW friendly. The service >>>> header can be >>>> represented as a mandotory fixed length header >>>> (like IP >>>> header) along with an optional variable length >>>> attribute field. >>>> Different services can be interested in >>>> different metadata, for >>>> example subscriber ID could be of interest in >>>> the mobile core >>>> service chain only. >>>> >>>> >>>> Sumandra >>>> >>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>> >>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> Linda, >>>> >>>> My interpretation of the >>>> architecture docs is that the >>>> service >>>> function chain is built in an >>>> abstract manner (i.e., SF-A then >>>> SF-B >>>> >>>> then SF-C). >>>> >>>> Separately, a locator table provides >>>> network location for >>>> each of those service functions. >>>> In this way, you can >>>> locate the service functions >>>> >>>> in >>>> >>>> a manner appropriate to the type of >>>> transport you are >>>> using. If you want that to be >>>> interface+VLAN, >>>> gateway-IP+MPLS label stack, IP >>>> >>>> address, >>>> >>>> GRE tunnel remote IP + key, etc., >>>> you can do that. You >>>> can even potentially locate >>>> different service functions that >>>> reside in the same chain with >>>> different flavors of >>>> network locators. Another >>>> justification to separate the >>>> identity of a service function from >>>> its network location is >>>> load balancing. If, for example, >>>> SF-A had 3 IP addresses, >>>> that would imply load balancing to 3 >>>> instances using IP as a >>>> transport layer. >>>> >>>> For all of those reasons, I strongly >>>> support a canonical service >>>> header that is independent of the >>>> transport >>>> methodology. At a particular >>>> node, the decision as to >>>> where to go next should be based >>>> solely on information carried in >>>> the canonical service header and not >>>> on the >>>> >>>> fields >>>> >>>> in the transport header. That is, >>>> the SFC node discards >>>> the transport header and extracts >>>> the chain ID from the >>>> service header. Through >>>> mechanisms we have not yet begun >>>> to discuss, the SFC node knows how >>>> to interpret the chain ID and >>>> ultimately how to progress the >>>> packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] On >>>> Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 2014 >>>> 12:01 PM To: Joel M. >>>> Halpern; sfc@ietf.org >>>> Subject: Re: >>>> [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below >>>> should be added Section 5.2 (SFC >>>> Classifier) to emphasize this point. >>>> >>>> "A Service Chain Classifier node can >>>> associate a unique Layer 2 >>>> or 3 Label (e.g. VLAN, MPLS label) >>>> to the packets in the flow. >>>> Those Layer 2 or 3 Label makes it >>>> easier for subsequent nodes >>>> along the flow path to steer the >>>> flow to the service functions >>>> specified by the flow's service >>>> chain." >>>> >>>> >>>> Linda -----Original Message----- >>>> From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] On >>>> Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 2014 >>>> 10:20 AM To: >>>> sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework >>>> proposal. The proposal has a very >>>> specific model of the scope of the >>>> transport header (that it is >>>> derived from, and relates only to, >>>> the first service function to >>>> which the packet will be directed. >>>> That is clearly an operational >>>> model we need to support. >>>> >>>> However, I would like to allow other >>>> transport operational >>>> models, such as the use of a VLAN to >>>> direct traffic along a >>>> chain. Or the use of an MPLS label, >>>> or an MPLS label stack. >>>> >>>> Yours, Joel M. Halpern >>>> >>>> >>>> _________________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> 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 Feb 13 12:51:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19831A0497 for ; Thu, 13 Feb 2014 12:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 pUlzgdpxy1U0 for ; Thu, 13 Feb 2014 12:51:18 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC11A04B5 for ; Thu, 13 Feb 2014 12:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1392324677; x=1423860677; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RyFcL6pcc0ag8VVRJC2+kKTHmN0wS0v97WhXFJ1BxHc=; b=RnPq6t0YyLinzn5Wi7t3KoBYr2m4IFCxkkQWKriT/hYCryw13/Uf8RXG C0/DQGuchOss2Gidu8Zt3xfj7SzXzsQHFiEM6rfvr90Ouxcsv2kQbFHvt +rDKXjbhC5+GhZm5EyVya8jv8ripReMsIuYwUQ1Mt1SdqXOsEheemxgLN M=; X-IronPort-AV: E=Sophos;i="4.95,840,1384300800"; d="scan'208";a="100320135" X-IPAS-Result: AqMEABAv/VLAqArr/2dsb2JhbABQCYM+V79OgTB0giUBAQEBAwEBARdLAgcXBAIBCA0EAQMBAQEKHQchBgsUAwYIAgQBEgiHaQMev0sNiDwXjF+BPyoGMgIEgx6BFASJEI0vAYMehT2Fb4hygio Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 13 Feb 2014 20:51:13 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 12:51:12 -0800 From: Sumandra Majee To: "Joel M. Halpern" , Jerome Moisand , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5RGY7dwqyrkEqwF+S/DRQfV5qyXfUAgAAqPQD//4LNAIAAiA2AgAAIFwCAAAcXAIAAAViAgAAECgCAAAGugIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAciAgAABywCAAAR/gP//iKTz Date: Thu, 13 Feb 2014 20:51:12 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> In-Reply-To: <52FD2249.9020802@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nijBlHy_v268NK6Z-BAOkO9s-Vk Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:51:25 -0000 I believe most of us agree that an out of bad signalling will not address t= he majority of requirement. Also a typical http flow carries many transacti= ons and each can have different or additional classification. So a metadata= can not be simple connected with one flow either. Current implementations = of proxies and load balancers has addressed this in many ways including cus= tome header insertion. The custom header in this case equivalent of metadat= a vector. =0A= =0A= I think we need an efficient way annotate actual data with inline metadata.= I also strongly believe in solving the 80% of the use case=0A= =0A= Regards=0A= Sumandra=0A= ________________________________________=0A= From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalp= ern.com]=0A= Sent: Thursday, February 13, 2014 11:51 AM=0A= To: Jerome Moisand; sfc@ietf.org=0A= Subject: Re: [sfc] Framework=0A= =0A= I know very well what GTP does in terms of correlators, and why.=0A= If all you need is an identifier for the subscriber, carrying a short=0A= identifier, and using it to select the desired behavior that has been=0A= pre-populated when the subscribers session starts works really well.=0A= That is part of why I am not objecting to having provision for=0A= out-of-band metadata.=0A= =0A= However, claiming that a single such correlator is all that is needed=0A= for even 80% of SFC cases (and I very much supporting trying to focus on=0A= the 80% cases), just does not seem to work, given the broad range of=0A= requirements that we have seen.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 2/13/14, 2:35 PM, Jerome Moisand wrote:=0A= > Joel,=0A= >=0A= > Protocols like GTP and L2TP work exactly that, with a form of session cor= relator between the data plane and the control plane. This is very handy fo= r subscriber and service management. Also if a correlator is defined as an = opaque and unique number, then one can avoid some of the pitfalls you descr= ibed. Long-lived metadata is clearly useful (and thanks for sharing, Reinal= do, will read), and there is clear applicability to various service chainin= g needs.=0A= >=0A= > Now this is just one way. The I-D Bruno referred to was just listing this= approach as one possible way among others. I totally agree with you that o= ther forms of metadata (like an outcome of the classification of a packet o= r a sequence of a few packets) may not be suitable for out-of-band signalin= g.=0A= >=0A= > Bottomline seems to be that we have too many options to choose from, and = none of them solving it all... Tough.=0A= >=0A= > -----Original Message-----=0A= > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= > Sent: Thursday, February 13, 2014 2:29 PM=0A= > To: sfc@ietf.org=0A= > Subject: Re: [sfc] Framework=0A= >=0A= > As I understand it, the tsvwg (and aeon) work is about flow metadata.=0A= > That is long-lived metadata of use across many packets. That does indeed= seem well-suited to out-of-band cases.=0A= >=0A= > My concern is that in SFC, there are many cases which are at best badly-a= ddressed if we insist that they be solved using out-of-band metadata.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote:=0A= >> There is draft about transport independent metadata.=0A= >>=0A= >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-= =0A= >> 01=0A= >>=0A= >> The complexities you mention are discussed there: variable-encoding,=0A= >> direction, security of metadata, etc.=0A= >>=0A= >> Thanks,=0A= >>=0A= >> -RP=0A= >>=0A= >>=0A= >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote:=0A= >>=0A= >>> While there are cases where out-of-band metadata makes sense, There=0A= >>> are many cases I would not want to try to cover that way. The best=0A= >>> examples are situations where the metadata changes from packet to=0A= >>> packet (such as the data produced by a DPI engine for consumption by=0A= >>> other applications in the chain.)=0A= >>>=0A= >>> More importantly, if you are putting correlators in the packet, it is= =0A= >>> still very complex if you want to use one correlator to handle=0A= >>> metadata produced by several different entities (the initial=0A= >>> classifer, the DPI engine, ...) You quickly end up deciding that you= =0A= >>> need several correlators. At which point we are back to variable amoun= ts of metadata.=0A= >>>=0A= >>> The alternative is to require exceedingly specific and strong=0A= >>> coupling to a mandated out-of-band mechanism. That seems to me to be= =0A= >>> a very bad idea.=0A= >>>=0A= >>> Yours,=0A= >>> Joel=0A= >>>=0A= >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote:=0A= >>>> resend to avoid "too many recipients" warning=0A= >>>>=0A= >>>>=0A= >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=0A= >>>> > wrote:=0A= >>>>=0A= >>>> There are ways to signal variable length amounts of metadata wit= hout=0A= >>>> needing an additional variable-length header on each data packet= .=0A= >>>>=0A= >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of t= he=0A= >>>> possible approaches: out-of-band signaling (congruent or=0A= >>>> non-congruent) or a hybrid approach using a fix-length in-band= =0A= >>>> correlator and out-of-band additional metadata. See sections 3.= 3,=0A= >>>> 3.4 and 3.5 in the draft.=0A= >>>>=0A= >>>> The issue of fixed-length encoding versus variable length encodi= ng=0A= >>>> is discussion in the challenges chapter in section 4.3. I shoul= d=0A= >>>> probably mention the MTU and segmentation issues as well in that= =0A= >>>> section.=0A= >>>>=0A= >>>>=0A= >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern=0A= >>>> > wrote:=0A= >>>>=0A= >>>> The variable length shim header is needed even if every=0A= >>>> individual piece of metadata has a fixed length. Different= =0A= >>>> service chains will need different combinations of metadata.= So=0A= >>>> the metadata portion of the header needs to be variable leng= th.=0A= >>>>=0A= >>>> I think the approach of a fixed length initial part, and a= =0A= >>>> variable length extension part, is the right model.=0A= >>>>=0A= >>>> Yours,=0A= >>>> Joel=0A= >>>>=0A= >>>>=0A= >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote:=0A= >>>>=0A= >>>> Yes, fragmentation and variable headers are usually a re= ally=0A= >>>> bad thing for forwarding performance. Let's not forget t= hat=0A= >>>> we live in a 100G-ish kind of world nowadays.=0A= >>>>=0A= >>>> Now the question should be: WHY would we want to do that= =0A= >>>> (variable headers leading to fragmentation issues)?=0A= >>>>=0A= >>>> For example, the type of metadata that may require=0A= >>>> variable-length fields might be a better candidate for s= ome=0A= >>>> out-of-band signaling mechanism. If this is service=0A= >>>> authorization data (e.g. a service profile/policy), this= =0A= >>>> sounds likely. Not 100% sure this is true for all use ca= ses=0A= >>>> though. Only a good understanding of use cases, grounded= by=0A= >>>> reflecting on existing network architectures (notably=0A= >>>> broadband, fixed or mobile), would tell us if one approa= ch=0A= >>>> or another is the most appropriate.=0A= >>>>=0A= >>>> Anyhoo, we're jumping way deep in the detailed protocol= =0A= >>>> design here. This seems a tad premature.=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: sfc [mailto:sfc-bounces@ietf.org=0A= >>>> ] On Behalf Of Dave Dolson= =0A= >>>> Sent: Thursday, February 13, 2014 11:03 AM=0A= >>>> To: 'jmh@joelhalpern.com ';= =0A= >>>> 'Ron_Parker@affirmednetworks.__com=0A= >>>> ';=0A= >>>> 'mohamed.boucadair@orange.com=0A= >>>> '__;=0A= >>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>> '; 'paulq@cisco.com= =0A= >>>> '=0A= >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org ';=0A= >>>> 'linda.dunbar@huawei.com '=0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> it is overall more efficient to support PMTU discovery= =0A= >>>> rather than fragmenting every large packet. The is why T= CP=0A= >>>> adopted it so early on.=0A= >>>>=0A= >>>> The fragmenting also puts huge performance burden on the= =0A= >>>> service functions.=0A= >>>> Fragmenting may also affect the ability of load balancer= s to=0A= >>>> get each fragment to the correct destination.=0A= >>>>=0A= >>>> So PMTU discovery SHOULD be used, in my opinion. By this= I=0A= >>>> mean the client or server is informed that its packets a= re=0A= >>>> too big (for IPv6 or IPv4 with DF=3D1).=0A= >>>>=0A= >>>> Some operators may wish to incur the extra cost to hide = the=0A= >>>> existence of the tunneling, when the elements of the cha= in=0A= >>>> can support it, so we could consider that as an optional= =0A= >>>> mechanism.=0A= >>>>=0A= >>>> -Dave=0A= >>>>=0A= >>>>=0A= >>>> ----- Original Message -----=0A= >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com=0A= >>>> ]=0A= >>>> Sent: Thursday, February 13, 2014 10:31 AM=0A= >>>> To: Ron Parker >>> >;=0A= >>>> mohamed.boucadair@orange.com=0A= >>>> =0A= >>>> >>> >__; Dave Dolson;= =0A= >>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>> '=0A= >>>> >>> >; 'paulq@cisco.com= =0A= >>>> ' >>> >=0A= >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org=0A= >>>> ' >;=0A= >>>> 'linda.dunbar@huawei.com '=0A= >>>> >=0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> I mostly agree with you Ron. I can probably come up wit= h=0A= >>>> some other variations, but your second point is that the= =0A= >>>> transport must deal with the issue of frame size / fit.= =0A= >>>>=0A= >>>> I would note that if we assume that the carrying encaps= =0A= >>>> (IPv4/v6 outer) is being fragmented, then we are assumin= g=0A= >>>> that the exit from service chaining can and will reassem= ble.=0A= >>>>=0A= >>>> Yours,=0A= >>>> Joel=0A= >>>>=0A= >>>> On 2/13/14, 10:18 AM, Ron Parker wrote:=0A= >>>>=0A= >>>> Joel,=0A= >>>>=0A= >>>> That is an excellent point to consider when choosing= =0A= >>>> transport=0A= >>>> encapsulations. If the transport encapsulation is = IPv4=0A= >>>> or IPv6=0A= >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=0A= >>>> etc.), then=0A= >>>> fragmentation and defragmentation are naturally=0A= >>>> supported. If the=0A= >>>> transport encapsulation is VLAN, MPLS, etc., then I= =0A= >>>> believe one of the=0A= >>>> following must be true:=0A= >>>>=0A= >>>> * The end-to-end path is known to support the result= ing=0A= >>>> larger frames=0A= >>>> * A path discovery mechanism is mandated by SFC when= =0A= >>>> non-IP transports=0A= >>>> are used * An SFC-specific fragmentation header and= =0A= >>>> mechanisms must be=0A= >>>> defined (i.e.,=0A= >>>>=0A= >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-f= =0A= >>>> rame)=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: Joel M. Halpern=0A= >>>> [mailto:jmh@joelhalpern.com=0A= >>>> ] Sent: Thursday, Februa= ry=0A= >>>> 13, 2014 10:10=0A= >>>> AM To: mohamed.boucadair@orange.com=0A= >>>> ; Dave Dolson;= =0A= >>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>> '; Ron Parker;= =0A= >>>> 'paulq@cisco.com ' Cc:=0A= >>>> 'S.Majee@F5.com'; 'sfc@ietf.org ';=0A= >>>> 'linda.dunbar@huawei.com=0A= >>>> ' Subject:=0A= >>>> Re: [sfc] Framework=0A= >>>>=0A= >>>> There is a related complexity. I hope that we expect= to=0A= >>>> support IPv6.=0A= >>>> IPv6 explicitly prohibits network elements from=0A= >>>> fragmenting end user=0A= >>>> packets.=0A= >>>>=0A= >>>> Yours, Joel=0A= >>>>=0A= >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com=0A= >>>> wrote:=0A= >>>>=0A= >>>> Re-,=0A= >>>>=0A= >>>> FWIW, one of the existing architecture drafts=0A= >>>> includes the following=0A= >>>> behavior=0A= >>>>=0A= >>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec= =0A= >>>> tion-=0A= >>>> 6=0A= >>>>=0A= >>>> ):=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> "=0A= >>>>=0A= >>>> 6. Fragmentation Considerations=0A= >>>>=0A= >>>> If adding the Service Chaining Header would resu= lt=0A= >>>> in a fragmented=0A= >>>> packet, the classifier should include a Service= =0A= >>>> Chaining Header in=0A= >>>> each fragment. Doing so would prevent SF Nodes = to=0A= >>>> dedicate resource=0A= >>>> to handle fragments. "=0A= >>>>=0A= >>>> Cheers, Med=0A= >>>>=0A= >>>>=0A= >>>> -----Message d'origine----- De : sfc=0A= >>>> [mailto:sfc-bounces@ietf.org=0A= >>>> ]=0A= >>>> De la part de Dave Dolson Envoy=E9 :=0A= >>>> jeudi 13 f=E9vrier 2014 13:39 =C0 :=0A= >>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>> ';=0A= >>>> 'Ron_Parker@affirmednetworks.__com=0A= >>>> ';= =0A= >>>> 'jmh@joelhalpern.com=0A= >>>> ';=0A= >>>> 'paulq@cisco.com ' C= c :=0A= >>>> 'S.Majee@F5.com'; 'sfc@ietf.org=0A= >>>> ';=0A= >>>> 'linda.dunbar@huawei.com=0A= >>>> ' Objet : Re= :=0A= >>>> [sfc] Framework=0A= >>>>=0A= >>>> Good point to consider fragmentation.=0A= >>>>=0A= >>>> We should design the encapsulation such that= the=0A= >>>> forwarding=0A= >>>> functions do not need to reassemble. Each=0A= >>>> fragment should be=0A= >>>> independently forwardable; some SFs may choo= se=0A= >>>> to ignore these=0A= >>>> packets.=0A= >>>>=0A= >>>> Any layer 2.5 protocol like VLAN or MPLS wou= ld=0A= >>>> support this.=0A= >>>> Otherwise, a reassembly layer could be added= =0A= >>>> after the forwarding=0A= >>>> coordinates. Think of something like the IPv= 6=0A= >>>> reassembly option=0A= >>>> after a GRE header, for instance.=0A= >>>>=0A= >>>> IP | GRE | reassem | frag data=0A= >>>>=0A= >>>> We could alternatively mandate the inner IP = be=0A= >>>> fragmented and that=0A= >>>> path-MTU discovery be supported.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> ----- Original Message ----- From: Nicolas= =0A= >>>> BOUTHORS=0A= >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com=0A= >>>> ] Sent:= =0A= >>>> Thursday, February 13,=0A= >>>> 2014 04:13 AM To: Ron Parker=0A= >>>> >>> >;= =0A= >>>> Dave Dolson; Joel M. Halpern=0A= >>>> >>> >; Paul Quinn=0A= >>>> (paulq) >>> > Cc: Sumandra Majee= =0A= >>>> ;=0A= >>>> sfc@ietf.org >>> >; Linda Dunbar=0A= >>>> >>> >=0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> If we do not enforce a fix header size we ha= ve=0A= >>>> other implication.=0A= >>>>=0A= >>>> There is the question of segmentation and=0A= >>>> reassembly responsibility=0A= >>>> as well.=0A= >>>>=0A= >>>> If adding length to the service header force= s=0A= >>>> segmentation, then=0A= >>>> whose responsibility is it to reassemble the= =0A= >>>> payload before passing=0A= >>>> it to the SF.=0A= >>>>=0A= >>>> Similar question for packet re-ordering.=0A= >>>>=0A= >>>>=0A= >>>> __________________________________________ F= rom:=0A= >>>> Ron Parker=0A= >>>> [Ron_Parker@affirmednetworks.__com=0A= >>>> ] Se= nt:=0A= >>>> Wednesday, February 12,=0A= >>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpe= rn;=0A= >>>> Paul Quinn=0A= >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org=0A= >>>> ; Linda Dunbar Subject:= =0A= >>>> Re: [sfc] Framework=0A= >>>>=0A= >>>> Dave,=0A= >>>>=0A= >>>> Yes, that is a good point if we logically=0A= >>>> separate the forwarding=0A= >>>> function from the SFC-aware service function= , as=0A= >>>> we should. The=0A= >>>> forwarding function is concerned with only t= he=0A= >>>> inbound transport=0A= >>>> header, the fixed portion of the service he= ader=0A= >>>> containing the=0A= >>>> chain information, and the outbound transpor= t=0A= >>>> header. The=0A= >>>> service function may look at the entirety of= the=0A= >>>> service header and=0A= >>>> would look at the encapsulated packet.=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: Dave Dolson= =0A= >>>> [mailto:ddolson@sandvine.com=0A= >>>> ] Sent: Wednesd= ay,=0A= >>>> February 12, 2014=0A= >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Pau= l=0A= >>>> Quinn (paulq) Cc:=0A= >>>> Sumandra Majee; sfc@ietf.org=0A= >>>> ; Linda Dunbar Subject:= RE:=0A= >>>> [sfc]=0A= >>>> Framework=0A= >>>>=0A= >>>> The forwarding plane might not even need to = look=0A= >>>> at the encapsulated=0A= >>>> packet.=0A= >>>>=0A= >>>> For example, (if the SF Identifier is a VLAN= =0A= >>>> tag), an Ethernet=0A= >>>> switch can forward packets of the form: Eth= er |=0A= >>>> VLAN | BLOB.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: sfc=0A= >>>> [mailto:sfc-bounces@ietf.org=0A= >>>> ]=0A= >>>> On Behalf Of Joel M. Halpern Sent:=0A= >>>> Wednesday, February 12, 2014 4:30 PM To: Ron= =0A= >>>> Parker; Dave Dolson;=0A= >>>> Paul Quinn (paulq) Cc: Sumandra Majee;=0A= >>>> sfc@ietf.org ; Linda Du= nbar=0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> I agree as well. Yours, Joel=0A= >>>>=0A= >>>> On 2/12/14, 4:24 PM, Ron Parker wrote:=0A= >>>>=0A= >>>> Hi, Dave.=0A= >>>>=0A= >>>> I Agree with your statement. And if = the=0A= >>>> total length of the=0A= >>>> header is=0A= >>>>=0A= >>>> contained in the mandatory portion, the hard= ware=0A= >>>> implementation can=0A= >>>> easily locate the encapsulated packet.=0A= >>>>=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: Dave Do= lson=0A= >>>> [mailto:ddolson@sandvine.com=0A= >>>> ] Sent:=0A= >>>> Wednesday, February 12,=0A= >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn= =0A= >>>> (paulq) Cc: Joel M.=0A= >>>> Halpern; Sumandra Majee; sfc@ietf.org=0A= >>>> ; Linda Dunbar Subj= ect:=0A= >>>> RE: [sfc] Framework=0A= >>>>=0A= >>>> I think a good approach would be:=0A= >>>>=0A= >>>> The information required for forwarding = (the=0A= >>>> SF Identifier) should=0A= >>>> be in=0A= >>>>=0A= >>>> a mandatory fixed-size header.=0A= >>>>=0A= >>>>=0A= >>>> Optional information (if any) is NOT to = be=0A= >>>> used for forwarding, but=0A= >>>> is=0A= >>>>=0A= >>>> for consumption by one or more of the=0A= >>>> applications in the chain.=0A= >>>>=0A= >>>>=0A= >>>> Then the forwarding plane, and even the = PDP,=0A= >>>> can be agnostic about=0A= >>>> the=0A= >>>>=0A= >>>> meta-data.=0A= >>>>=0A= >>>>=0A= >>>> -Dave=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: sfc=0A= >>>> [mailto:sfc-bounces@ietf.org=0A= >>>> ]=0A= >>>> On Behalf Of Ron Parker Sent:=0A= >>>> Wednesday, February 12, 2014 4:05 PM To:= =0A= >>>> Paul Quinn (paulq) Cc:=0A= >>>> Joel M. Halpern; Sumandra Majee;=0A= >>>> sfc@ietf.org ;=0A= >>>> Linda Dunbar=0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> Paul,=0A= >>>>=0A= >>>> That is why I am proposing a hybrid wher= e=0A= >>>> extensions or options can=0A= >>>> be=0A= >>>>=0A= >>>> added but the total length is contained in t= he=0A= >>>> fixed portion. I=0A= >>>> can envision certain deployments (e.g.,=0A= >>>> Enterprise) where perhaps=0A= >>>> extensions are not needed and the SFC=0A= >>>> functionality is realized=0A= >>>> in hardware. And, I can envision certain o= ther=0A= >>>> deployments=0A= >>>> (e.g., 3gpp) where the extension headers add= =0A= >>>> sufficient value to=0A= >>>> justify software based implementations.=0A= >>>>=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From: Paul Qu= inn=0A= >>>> (paulq)=0A= >>>> [mailto:paulq@cisco.com=0A= >>>> ] Sent: Wednesda= y,=0A= >>>> February 12, 2014=0A= >>>> 3:40 PM To: Ron Parker Cc: Sumandra Maje= e;=0A= >>>> Linda Dunbar; Joel M.=0A= >>>> Halpern; sfc@ietf.org =0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> Hi,=0A= >>>>=0A= >>>> We certainly need to be very careful wit= h=0A= >>>> variable length headers=0A= >>>> when=0A= >>>>=0A= >>>> hardware platform are in play.=0A= >>>>=0A= >>>>=0A= >>>> Ron, your examples of IP options and v6 = EH=0A= >>>> have both suffered from=0A= >>>>=0A= >>>> significant implementation and deployment=0A= >>>> hurdles due to the=0A= >>>> complexity and cost associated with hardware= =0A= >>>> support for the=0A= >>>> option/EH.=0A= >>>>=0A= >>>>=0A= >>>> Paul=0A= >>>>=0A= >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker= =0A= >>>> >>>=0A= >>>> >=0A= >>>>=0A= >>>> wrote:=0A= >>>>=0A= >>>>=0A= >>>> Hi, Sumandra.=0A= >>>>=0A= >>>> Regarding service header flexibility= , I=0A= >>>> completely agree. I=0A= >>>> might=0A= >>>>=0A= >>>> suggest a compromise between hardware=0A= >>>> friendliness and software=0A= >>>> flexibility. If the header had the abilit= y to=0A= >>>> add extensions=0A= >>>> (perhaps similar to IPv6) but also had the= =0A= >>>> header length encoded in=0A= >>>> the mandatory part (like IPv4), then a hardw= are=0A= >>>> implementation would=0A= >>>> be free to skip over the extensions (in case= s=0A= >>>> where the deployment=0A= >>>> justifies ignoring the extensions).=0A= >>>>=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From:=0A= >>>> Sumandra Majee=0A= >>>> [mailto:S.Majee@F5.com=0A= >>>> ] Sent:=0A= >>>> Wednesday, February 12, 2014=0A= >>>> 3:04 PM To: Ron Parker; Linda Dunbar= ;=0A= >>>> Joel M. Halpern;=0A= >>>> sfc@ietf.org = =0A= >>>> Subject: Re: [sfc] Framework=0A= >>>>=0A= >>>> For all of those reasons, I= =0A= >>>> strongly support a=0A= >>>> canonical service=0A= >>>> header that is independent o= f=0A= >>>> the transport methodology.= =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> I agree. However the format of servi= ce=0A= >>>> header should be=0A= >>>> standardized in=0A= >>>>=0A= >>>> a way that is flexible. Some of us would lik= e to=0A= >>>> see variable length=0A= >>>> header that is also HW friendly. The service= =0A= >>>> header can be=0A= >>>> represented as a mandotory fixed length head= er=0A= >>>> (like IP=0A= >>>> header) along with an optional variable leng= th=0A= >>>> attribute field.=0A= >>>> Different services can be interested in=0A= >>>> different metadata, for=0A= >>>> example subscriber ID could be of interest i= n=0A= >>>> the mobile core=0A= >>>> service chain only.=0A= >>>>=0A= >>>>=0A= >>>> Sumandra=0A= >>>>=0A= >>>> On 2/12/14, 11:32 AM, "Ron Parker"= =0A= >>>> >>>=0A= >>>> >=0A= >>>>=0A= >>>> wrote:=0A= >>>>=0A= >>>>=0A= >>>> Linda,=0A= >>>>=0A= >>>> My interpretation of the=0A= >>>> architecture docs is that the=0A= >>>> service=0A= >>>> function chain is built in an=0A= >>>> abstract manner (i.e., SF-A then= =0A= >>>> SF-B=0A= >>>>=0A= >>>> then SF-C).=0A= >>>>=0A= >>>> Separately, a locator table prov= ides=0A= >>>> network location for=0A= >>>> each of those service functions.= =0A= >>>> In this way, you can=0A= >>>> locate the service functions=0A= >>>>=0A= >>>> in=0A= >>>>=0A= >>>> a manner appropriate to the type= of=0A= >>>> transport you are=0A= >>>> using. If you want that to be= =0A= >>>> interface+VLAN,=0A= >>>> gateway-IP+MPLS label stack, IP= =0A= >>>>=0A= >>>> address,=0A= >>>>=0A= >>>> GRE tunnel remote IP + key, etc.= ,=0A= >>>> you can do that. You=0A= >>>> can even potentially locate=0A= >>>> different service functions that= =0A= >>>> reside in the same chain with=0A= >>>> different flavors of=0A= >>>> network locators. Another=0A= >>>> justification to separate the=0A= >>>> identity of a service function f= rom=0A= >>>> its network location is=0A= >>>> load balancing. If, for exampl= e,=0A= >>>> SF-A had 3 IP addresses,=0A= >>>> that would imply load balancing = to 3=0A= >>>> instances using IP as a=0A= >>>> transport layer.=0A= >>>>=0A= >>>> For all of those reasons, I stro= ngly=0A= >>>> support a canonical service=0A= >>>> header that is independent of th= e=0A= >>>> transport=0A= >>>> methodology. At a particular= =0A= >>>> node, the decision as to=0A= >>>> where to go next should be based= =0A= >>>> solely on information carried in= =0A= >>>> the canonical service header and= not=0A= >>>> on the=0A= >>>>=0A= >>>> fields=0A= >>>>=0A= >>>> in the transport header. That = is,=0A= >>>> the SFC node discards=0A= >>>> the transport header and extract= s=0A= >>>> the chain ID from the=0A= >>>> service header. Through=0A= >>>> mechanisms we have not yet begun= =0A= >>>> to discuss, the SFC node knows h= ow=0A= >>>> to interpret the chain ID and=0A= >>>> ultimately how to progress the= =0A= >>>> packet.=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message----- From:= sfc=0A= >>>> [mailto:sfc-bounces@ietf.org=0A= >>>> ] O= n=0A= >>>> Behalf Of Linda Dunbar=0A= >>>> Sent: Wednesday, February 12, 20= 14=0A= >>>> 12:01 PM To: Joel M.=0A= >>>> Halpern; sfc@ietf.org=0A= >>>> Subject: R= e:=0A= >>>> [sfc] Framework=0A= >>>>=0A= >>>> Agree with Joel's statement.=0A= >>>>=0A= >>>> I think a simple sentence below= =0A= >>>> should be added Section 5.2 (SFC= =0A= >>>> Classifier) to emphasize this po= int.=0A= >>>>=0A= >>>> "A Service Chain Classifier node= can=0A= >>>> associate a unique Layer 2=0A= >>>> or 3 Label (e.g. VLAN, MPLS labe= l)=0A= >>>> to the packets in the flow.=0A= >>>> Those Layer 2 or 3 Label makes i= t=0A= >>>> easier for subsequent nodes=0A= >>>> along the flow path to steer the= =0A= >>>> flow to the service functions=0A= >>>> specified by the flow's service= =0A= >>>> chain."=0A= >>>>=0A= >>>>=0A= >>>> Linda -----Original Message-----= =0A= >>>> From: sfc=0A= >>>> [mailto:sfc-bounces@ietf.org=0A= >>>> ] O= n=0A= >>>> Behalf Of Joel M. Halpern=0A= >>>> Sent: Wednesday, February 12, 20= 14=0A= >>>> 10:20 AM To:=0A= >>>> sfc@ietf.org =0A= >>>> Subject: [sfc] Framework=0A= >>>>=0A= >>>> I was looking at the framework= =0A= >>>> proposal. The proposal has a ver= y=0A= >>>> specific model of the scope of t= he=0A= >>>> transport header (that it is=0A= >>>> derived from, and relates only t= o,=0A= >>>> the first service function to=0A= >>>> which the packet will be directe= d.=0A= >>>> That is clearly an operational= =0A= >>>> model we need to support.=0A= >>>>=0A= >>>> However, I would like to allow o= ther=0A= >>>> transport operational=0A= >>>> models, such as the use of a VLA= N to=0A= >>>> direct traffic along a=0A= >>>> chain. Or the use of an MPLS la= bel,=0A= >>>> or an MPLS label stack.=0A= >>>>=0A= >>>> Yours, Joel M. Halpern=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> =0A= >>>>=0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> =0A= >>>>=0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> =0A= >>>>=0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org = =0A= >>>>=0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/= sfc=0A= >>>>=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________ sfc=0A= >>>> mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc= =0A= >>>> = =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________ sfc=0A= >>>> mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc= =0A= >>>> = =0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________ sfc=0A= >>>> mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc= =0A= >>>> = =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _________________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org =0A= >>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>> =0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >>=0A= >=0A= > _______________________________________________=0A= > sfc mailing list=0A= > sfc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= >=0A= >=0A= >=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Feb 13 13:13:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A943B1A04E6 for ; Thu, 13 Feb 2014 13:12:59 -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 GuJyLF8End1D for ; Thu, 13 Feb 2014 13:12:53 -0800 (PST) Received: from p02c12o141.mxlogic.net (p02c12o141.mxlogic.net [208.65.145.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC851A04B4 for ; Thu, 13 Feb 2014 13:12:53 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p02c12o141.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 4553df25.2b2c1de22940.70382.00-513.194104.p02c12o141.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 14:12:52 -0700 (MST) X-MXL-Hash: 52fd355428f3854f-ae1121eab94d40a8484453a822ff2b686bb9337e Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p02c12o141.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id d053df25.0.69731.00-256.192311.p02c12o141.mxlogic.net (envelope-from ); Thu, 13 Feb 2014 14:11:45 -0700 (MST) X-MXL-Hash: 52fd35116ee064a6-1ebc64f7a122c4c1f8092cac00c113f63900d84c Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Thu, 13 Feb 2014 16:11:33 -0500 From: Kevin J Ma To: Sumandra Majee , "Joel M. Halpern" , Jerome Moisand , "sfc@ietf.org" Date: Thu, 13 Feb 2014 16:11:31 -0500 Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5RGY7dwqyrkEqwF+S/DRQfV5qyXfUAgAAqPQD//4LNAIAAiA2AgAAIFwCAAAcXAIAAAViAgAAECgCAAAGugIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAciAgAABywCAAAR/gP//iKTzgAAE6lA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6D54172F4D2@MAILR002.mail.lan> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DVPZ1WNpPGrtGP1POrvCbkHCncc Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:13:00 -0000 Sumandra, When you say custom headers, do you mean custom message (e.g., HTTP) headers, or packet headers? Placing message-level metadata into every packet would not seem to me to be a good use of SFC metadata? For a mult-megabyte file, a kilobyte of metadata, relative to the file size might be reasonable, however, relative to each packet sent for that file, the overhead would not make sense? Note: HTTP header insertion is still in-band metadata, it's just may not be of any concern to SFC? -- Kevin J. Ma > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 3:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not address > the majority of requirement. Also a typical http flow carries many > transactions and each can have different or additional classification. So > a metadata can not be simple connected with one flow either. Current > implementations of proxies and load balancers has addressed this in many > ways including custome header insertion. The custom header in this case > equivalent of metadata vector. > > I think we need an efficient way annotate actual data with inline > metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short > identifier, and using it to select the desired behavior that has been > pre-populated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for > out-of-band metadata. > > However, claiming that a single such correlator is all that is needed > for even 80% of SFC cases (and I very much supporting trying to focus on > the 80% cases), just does not seem to work, given the broad range of > requirements that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: > > Joel, > > > > Protocols like GTP and L2TP work exactly that, with a form of session > correlator between the data plane and the control plane. This is very > handy for subscriber and service management. Also if a correlator is > defined as an opaque and unique number, then one can avoid some of the > pitfalls you described. Long-lived metadata is clearly useful (and thanks > for sharing, Reinaldo, will read), and there is clear applicability to > various service chaining needs. > > > > Now this is just one way. The I-D Bruno referred to was just listing > this approach as one possible way among others. I totally agree with you > that other forms of metadata (like an outcome of the classification of a > packet or a sequence of a few packets) may not be suitable for out-of-ban= d > signaling. > > > > Bottomline seems to be that we have too many options to choose from, an= d > none of them solving it all... Tough. > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Thursday, February 13, 2014 2:29 PM > > To: sfc@ietf.org > > Subject: Re: [sfc] Framework > > > > As I understand it, the tsvwg (and aeon) work is about flow metadata. > > That is long-lived metadata of use across many packets. That does > indeed seem well-suited to out-of-band cases. > > > > My concern is that in SFC, there are many cases which are at best badly= - > addressed if we insist that they be solved using out-of-band metadata. > > > > Yours, > > Joel > > > > On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: > >> There is draft about transport independent metadata. > >> > >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding- > >> 01 > >> > >> The complexities you mention are discussed there: variable-encoding, > >> direction, security of metadata, etc. > >> > >> Thanks, > >> > >> -RP > >> > >> > >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: > >> > >>> While there are cases where out-of-band metadata makes sense, There > >>> are many cases I would not want to try to cover that way. The best > >>> examples are situations where the metadata changes from packet to > >>> packet (such as the data produced by a DPI engine for consumption by > >>> other applications in the chain.) > >>> > >>> More importantly, if you are putting correlators in the packet, it is > >>> still very complex if you want to use one correlator to handle > >>> metadata produced by several different entities (the initial > >>> classifer, the DPI engine, ...) You quickly end up deciding that you > >>> need several correlators. At which point we are back to variable > amounts of metadata. > >>> > >>> The alternative is to require exceedingly specific and strong > >>> coupling to a mandated out-of-band mechanism. That seems to me to be > >>> a very bad idea. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: > >>>> resend to avoid "too many recipients" warning > >>>> > >>>> > >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman > >>>> > wrote: > >>>> > >>>> There are ways to signal variable length amounts of metadata > without > >>>> needing an additional variable-length header on each data > packet. > >>>> > >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of > the > >>>> possible approaches: out-of-band signaling (congruent or > >>>> non-congruent) or a hybrid approach using a fix-length in-band > >>>> correlator and out-of-band additional metadata. See sections > 3.3, > >>>> 3.4 and 3.5 in the draft. > >>>> > >>>> The issue of fixed-length encoding versus variable length > encoding > >>>> is discussion in the challenges chapter in section 4.3. I > should > >>>> probably mention the MTU and segmentation issues as well in > that > >>>> section. > >>>> > >>>> > >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern > >>>> > wrote: > >>>> > >>>> The variable length shim header is needed even if every > >>>> individual piece of metadata has a fixed length. Differen= t > >>>> service chains will need different combinations of > metadata. So > >>>> the metadata portion of the header needs to be variable > length. > >>>> > >>>> I think the approach of a fixed length initial part, and a > >>>> variable length extension part, is the right model. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> > >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: > >>>> > >>>> Yes, fragmentation and variable headers are usually a > really > >>>> bad thing for forwarding performance. Let's not forget > that > >>>> we live in a 100G-ish kind of world nowadays. > >>>> > >>>> Now the question should be: WHY would we want to do > that > >>>> (variable headers leading to fragmentation issues)? > >>>> > >>>> For example, the type of metadata that may require > >>>> variable-length fields might be a better candidate for > some > >>>> out-of-band signaling mechanism. If this is service > >>>> authorization data (e.g. a service profile/policy), > this > >>>> sounds likely. Not 100% sure this is true for all use > cases > >>>> though. Only a good understanding of use cases, > grounded by > >>>> reflecting on existing network architectures (notably > >>>> broadband, fixed or mobile), would tell us if one > approach > >>>> or another is the most appropriate. > >>>> > >>>> Anyhoo, we're jumping way deep in the detailed protoco= l > >>>> design here. This seems a tad premature. > >>>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org > >>>> ] On Behalf Of Dave Dolso= n > >>>> Sent: Thursday, February 13, 2014 11:03 AM > >>>> To: 'jmh@joelhalpern.com '= ; > >>>> 'Ron_Parker@affirmednetworks.__com > >>>> '; > >>>> 'mohamed.boucadair@orange.com > >>>> '__; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; 'paulq@cisco.co= m > >>>> ' > >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org > '; > >>>> 'linda.dunbar@huawei.com > ' > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> it is overall more efficient to support PMTU discovery > >>>> rather than fragmenting every large packet. The is why > TCP > >>>> adopted it so early on. > >>>> > >>>> The fragmenting also puts huge performance burden on > the > >>>> service functions. > >>>> Fragmenting may also affect the ability of load > balancers to > >>>> get each fragment to the correct destination. > >>>> > >>>> So PMTU discovery SHOULD be used, in my opinion. By > this I > >>>> mean the client or server is informed that its packets > are > >>>> too big (for IPv6 or IPv4 with DF=3D1). > >>>> > >>>> Some operators may wish to incur the extra cost to hid= e > the > >>>> existence of the tunneling, when the elements of the > chain > >>>> can support it, so we could consider that as an > optional > >>>> mechanism. > >>>> > >>>> -Dave > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com > >>>> ] > >>>> Sent: Thursday, February 13, 2014 10:31 AM > >>>> To: Ron Parker >>>> >; > >>>> mohamed.boucadair@orange.com > >>>> > >>>> >>>> >__; Dave Dolson; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> ' > >>>> >>>> >; 'paulq@cisco.co= m > >>>> ' >>>> > > >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org > >>>> ' >; > >>>> 'linda.dunbar@huawei.com > ' > >>>> > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> I mostly agree with you Ron. I can probably come up > with > >>>> some other variations, but your second point is that > the > >>>> transport must deal with the issue of frame size / fit= . > >>>> > >>>> I would note that if we assume that the carrying encap= s > >>>> (IPv4/v6 outer) is being fragmented, then we are > assuming > >>>> that the exit from service chaining can and will > reassemble. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 2/13/14, 10:18 AM, Ron Parker wrote: > >>>> > >>>> Joel, > >>>> > >>>> That is an excellent point to consider when > choosing > >>>> transport > >>>> encapsulations. If the transport encapsulation i= s > IPv4 > >>>> or IPv6 > >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, > >>>> etc.), then > >>>> fragmentation and defragmentation are naturally > >>>> supported. If the > >>>> transport encapsulation is VLAN, MPLS, etc., then = I > >>>> believe one of the > >>>> following must be true: > >>>> > >>>> * The end-to-end path is known to support the > resulting > >>>> larger frames > >>>> * A path discovery mechanism is mandated by SFC > when > >>>> non-IP transports > >>>> are used * An SFC-specific fragmentation header an= d > >>>> mechanisms must be > >>>> defined (i.e., > >>>> > >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-f > >>>> rame) > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Joel M. Halpern > >>>> [mailto:jmh@joelhalpern.com > >>>> ] Sent: Thursday, > February > >>>> 13, 2014 10:10 > >>>> AM To: mohamed.boucadair@orange.com > >>>> ; Dave Dolson= ; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; Ron Parker; > >>>> 'paulq@cisco.com ' Cc: > >>>> 'S.Majee@F5.com'; 'sfc@ietf.org > '; > >>>> 'linda.dunbar@huawei.com > >>>> ' Subject: > >>>> Re: [sfc] Framework > >>>> > >>>> There is a related complexity. I hope that we > expect to > >>>> support IPv6. > >>>> IPv6 explicitly prohibits network elements from > >>>> fragmenting end user > >>>> packets. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com > >>>> wrote: > >>>> > >>>> Re-, > >>>> > >>>> FWIW, one of the existing architecture drafts > >>>> includes the following > >>>> behavior > >>>> > >>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#sec > >>>> tion- > >>>> 6 > >>>> > >>>> 6>): > >>>> > >>>> > >>>> > >>>> " > >>>> > >>>> 6. Fragmentation Considerations > >>>> > >>>> If adding the Service Chaining Header would > result > >>>> in a fragmented > >>>> packet, the classifier should include a Servic= e > >>>> Chaining Header in > >>>> each fragment. Doing so would prevent SF Node= s > to > >>>> dedicate resource > >>>> to handle fragments. " > >>>> > >>>> Cheers, Med > >>>> > >>>> > >>>> -----Message d'origine----- De : sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> De la part de Dave Dolson Envoy=E9 : > >>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; > >>>> 'Ron_Parker@affirmednetworks.__com > >>>> '; > >>>> 'jmh@joelhalpern.com > >>>> '; > >>>> 'paulq@cisco.com ' > Cc : > >>>> 'S.Majee@F5.com'; 'sfc@ietf.org > >>>> '; > >>>> 'linda.dunbar@huawei.com > >>>> ' Objet : > Re: > >>>> [sfc] Framework > >>>> > >>>> Good point to consider fragmentation. > >>>> > >>>> We should design the encapsulation such > that the > >>>> forwarding > >>>> functions do not need to reassemble. Each > >>>> fragment should be > >>>> independently forwardable; some SFs may > choose > >>>> to ignore these > >>>> packets. > >>>> > >>>> Any layer 2.5 protocol like VLAN or MPLS > would > >>>> support this. > >>>> Otherwise, a reassembly layer could be > added > >>>> after the forwarding > >>>> coordinates. Think of something like the > IPv6 > >>>> reassembly option > >>>> after a GRE header, for instance. > >>>> > >>>> IP | GRE | reassem | frag data > >>>> > >>>> We could alternatively mandate the inner I= P > be > >>>> fragmented and that > >>>> path-MTU discovery be supported. > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- From: Nicolas > >>>> BOUTHORS > >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com > >>>> ] Sent= : > >>>> Thursday, February 13, > >>>> 2014 04:13 AM To: Ron Parker > >>>> >>>> >; > >>>> Dave Dolson; Joel M. Halpern > >>>> >>>> >; Paul Quinn > >>>> (paulq) >>>> > Cc: Sumandra > Majee > >>>> ; > >>>> sfc@ietf.org > >>>> >; Linda Dunbar > >>>> >>>> > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> If we do not enforce a fix header size we > have > >>>> other implication. > >>>> > >>>> There is the question of segmentation and > >>>> reassembly responsibility > >>>> as well. > >>>> > >>>> If adding length to the service header > forces > >>>> segmentation, then > >>>> whose responsibility is it to reassemble > the > >>>> payload before passing > >>>> it to the SF. > >>>> > >>>> Similar question for packet re-ordering. > >>>> > >>>> > >>>> __________________________________________ > From: > >>>> Ron Parker > >>>> [Ron_Parker@affirmednetworks.__com > >>>> ] > Sent: > >>>> Wednesday, February 12, > >>>> 2014 11:25 PM To: Dave Dolson; Joel M. > Halpern; > >>>> Paul Quinn > >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: > >>>> Re: [sfc] Framework > >>>> > >>>> Dave, > >>>> > >>>> Yes, that is a good point if we logically > >>>> separate the forwarding > >>>> function from the SFC-aware service > function, as > >>>> we should. The > >>>> forwarding function is concerned with only > the > >>>> inbound transport > >>>> header, the fixed portion of the service > header > >>>> containing the > >>>> chain information, and the outbound > transport > >>>> header. The > >>>> service function may look at the entirety > of the > >>>> service header and > >>>> would look at the encapsulated packet. > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Dave > Dolson > >>>> [mailto:ddolson@sandvine.com > >>>> ] Sent: > Wednesday, > >>>> February 12, 2014 > >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; > Paul > >>>> Quinn (paulq) Cc: > >>>> Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: RE: > >>>> [sfc] > >>>> Framework > >>>> > >>>> The forwarding plane might not even need t= o > look > >>>> at the encapsulated > >>>> packet. > >>>> > >>>> For example, (if the SF Identifier is a > VLAN > >>>> tag), an Ethernet > >>>> switch can forward packets of the form: > Ether | > >>>> VLAN | BLOB. > >>>> > >>>> > >>>> > >>>> -----Original Message----- From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> On Behalf Of Joel M. Halpern Sent: > >>>> Wednesday, February 12, 2014 4:30 PM To: > Ron > >>>> Parker; Dave Dolson; > >>>> Paul Quinn (paulq) Cc: Sumandra Majee; > >>>> sfc@ietf.org ; Linda > Dunbar > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> I agree as well. Yours, Joel > >>>> > >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: > >>>> > >>>> Hi, Dave. > >>>> > >>>> I Agree with your statement. And i= f > the > >>>> total length of the > >>>> header is > >>>> > >>>> contained in the mandatory portion, the > hardware > >>>> implementation can > >>>> easily locate the encapsulated packet. > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Dave > Dolson > >>>> [mailto:ddolson@sandvine.com > >>>> ] Sent: > >>>> Wednesday, February 12, > >>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n > >>>> (paulq) Cc: Joel M. > >>>> Halpern; Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: > >>>> RE: [sfc] Framework > >>>> > >>>> I think a good approach would be: > >>>> > >>>> The information required for forwardin= g > (the > >>>> SF Identifier) should > >>>> be in > >>>> > >>>> a mandatory fixed-size header. > >>>> > >>>> > >>>> Optional information (if any) is NOT t= o > be > >>>> used for forwarding, but > >>>> is > >>>> > >>>> for consumption by one or more of the > >>>> applications in the chain. > >>>> > >>>> > >>>> Then the forwarding plane, and even th= e > PDP, > >>>> can be agnostic about > >>>> the > >>>> > >>>> meta-data. > >>>> > >>>> > >>>> -Dave > >>>> > >>>> > >>>> -----Original Message----- From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> On Behalf Of Ron Parker Sent: > >>>> Wednesday, February 12, 2014 4:05 PM > To: > >>>> Paul Quinn (paulq) Cc: > >>>> Joel M. Halpern; Sumandra Majee; > >>>> sfc@ietf.org ; > >>>> Linda Dunbar > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> Paul, > >>>> > >>>> That is why I am proposing a hybrid > where > >>>> extensions or options can > >>>> be > >>>> > >>>> added but the total length is contained in > the > >>>> fixed portion. I > >>>> can envision certain deployments (e.g., > >>>> Enterprise) where perhaps > >>>> extensions are not needed and the SFC > >>>> functionality is realized > >>>> in hardware. And, I can envision certain > other > >>>> deployments > >>>> (e.g., 3gpp) where the extension headers > add > >>>> sufficient value to > >>>> justify software based implementations. > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Paul > Quinn > >>>> (paulq) > >>>> [mailto:paulq@cisco.com > >>>> ] Sent: > Wednesday, > >>>> February 12, 2014 > >>>> 3:40 PM To: Ron Parker Cc: Sumandra > Majee; > >>>> Linda Dunbar; Joel M. > >>>> Halpern; sfc@ietf.org > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> Hi, > >>>> > >>>> We certainly need to be very careful > with > >>>> variable length headers > >>>> when > >>>> > >>>> hardware platform are in play. > >>>> > >>>> > >>>> Ron, your examples of IP options and v= 6 > EH > >>>> have both suffered from > >>>> > >>>> significant implementation and deployment > >>>> hurdles due to the > >>>> complexity and cost associated with > hardware > >>>> support for the > >>>> option/EH. > >>>> > >>>> > >>>> Paul > >>>> > >>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r > >>>> >>>> > >>>> > > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Hi, Sumandra. > >>>> > >>>> Regarding service header > flexibility, I > >>>> completely agree. I > >>>> might > >>>> > >>>> suggest a compromise between hardware > >>>> friendliness and software > >>>> flexibility. If the header had the > ability to > >>>> add extensions > >>>> (perhaps similar to IPv6) but also had the > >>>> header length encoded in > >>>> the mandatory part (like IPv4), then a > hardware > >>>> implementation would > >>>> be free to skip over the extensions (in > cases > >>>> where the deployment > >>>> justifies ignoring the extensions). > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: > >>>> Sumandra Majee > >>>> [mailto:S.Majee@F5.com > >>>> ] Sent: > >>>> Wednesday, February 12, 2014 > >>>> 3:04 PM To: Ron Parker; Linda > Dunbar; > >>>> Joel M. Halpern; > >>>> sfc@ietf.org > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> For all of those reasons, = I > >>>> strongly support a > >>>> canonical service > >>>> header that is independent > of > >>>> the transport methodology. > >>>> > >>>> > >>>> > >>>> I agree. However the format of > service > >>>> header should be > >>>> standardized in > >>>> > >>>> a way that is flexible. Some of us would > like to > >>>> see variable length > >>>> header that is also HW friendly. The > service > >>>> header can be > >>>> represented as a mandotory fixed length > header > >>>> (like IP > >>>> header) along with an optional variable > length > >>>> attribute field. > >>>> Different services can be interested in > >>>> different metadata, for > >>>> example subscriber ID could be of interest > in > >>>> the mobile core > >>>> service chain only. > >>>> > >>>> > >>>> Sumandra > >>>> > >>>> On 2/12/14, 11:32 AM, "Ron Parker" > >>>> >>>> > >>>> > > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Linda, > >>>> > >>>> My interpretation of the > >>>> architecture docs is that the > >>>> service > >>>> function chain is built in an > >>>> abstract manner (i.e., SF-A > then > >>>> SF-B > >>>> > >>>> then SF-C). > >>>> > >>>> Separately, a locator table > provides > >>>> network location for > >>>> each of those service > functions. > >>>> In this way, you can > >>>> locate the service functions > >>>> > >>>> in > >>>> > >>>> a manner appropriate to the > type of > >>>> transport you are > >>>> using. If you want that to b= e > >>>> interface+VLAN, > >>>> gateway-IP+MPLS label stack, I= P > >>>> > >>>> address, > >>>> > >>>> GRE tunnel remote IP + key, > etc., > >>>> you can do that. You > >>>> can even potentially locate > >>>> different service functions > that > >>>> reside in the same chain with > >>>> different flavors of > >>>> network locators. Another > >>>> justification to separate the > >>>> identity of a service function > from > >>>> its network location is > >>>> load balancing. If, for > example, > >>>> SF-A had 3 IP addresses, > >>>> that would imply load balancin= g > to 3 > >>>> instances using IP as a > >>>> transport layer. > >>>> > >>>> For all of those reasons, I > strongly > >>>> support a canonical service > >>>> header that is independent of > the > >>>> transport > >>>> methodology. At a particula= r > >>>> node, the decision as to > >>>> where to go next should be > based > >>>> solely on information carried > in > >>>> the canonical service header > and not > >>>> on the > >>>> > >>>> fields > >>>> > >>>> in the transport header. Tha= t > is, > >>>> the SFC node discards > >>>> the transport header and > extracts > >>>> the chain ID from the > >>>> service header. Through > >>>> mechanisms we have not yet > begun > >>>> to discuss, the SFC node knows > how > >>>> to interpret the chain ID and > >>>> ultimately how to progress the > >>>> packet. > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- > From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > On > >>>> Behalf Of Linda Dunbar > >>>> Sent: Wednesday, February 12, > 2014 > >>>> 12:01 PM To: Joel M. > >>>> Halpern; sfc@ietf.org > >>>> Subject: > Re: > >>>> [sfc] Framework > >>>> > >>>> Agree with Joel's statement. > >>>> > >>>> I think a simple sentence belo= w > >>>> should be added Section 5.2 > (SFC > >>>> Classifier) to emphasize this > point. > >>>> > >>>> "A Service Chain Classifier > node can > >>>> associate a unique Layer 2 > >>>> or 3 Label (e.g. VLAN, MPLS > label) > >>>> to the packets in the flow. > >>>> Those Layer 2 or 3 Label makes > it > >>>> easier for subsequent nodes > >>>> along the flow path to steer > the > >>>> flow to the service functions > >>>> specified by the flow's servic= e > >>>> chain." > >>>> > >>>> > >>>> Linda -----Original Message---= - > - > >>>> From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > On > >>>> Behalf Of Joel M. Halpern > >>>> Sent: Wednesday, February 12, > 2014 > >>>> 10:20 AM To: > >>>> sfc@ietf.org > > >>>> Subject: [sfc] Framework > >>>> > >>>> I was looking at the framework > >>>> proposal. The proposal has a > very > >>>> specific model of the scope of > the > >>>> transport header (that it is > >>>> derived from, and relates only > to, > >>>> the first service function to > >>>> which the packet will be > directed. > >>>> That is clearly an operational > >>>> model we need to support. > >>>> > >>>> However, I would like to allow > other > >>>> transport operational > >>>> models, such as the use of a > VLAN to > >>>> direct traffic along a > >>>> chain. Or the use of an MPLS > label, > >>>> or an MPLS label stack. > >>>> > >>>> Yours, Joel M. Halpern > >>>> > >>>> > >>>> _________________________________________________ > >>>> 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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> 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/sf= c > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ sfc > >>>> mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/sf= c > >>>> > >>>> > >>>> > >>>> _________________________________________________ sfc > >>>> mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/sf= c > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> 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 > > > > > > > > > > _______________________________________________ > 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 Feb 13 13:18:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB67C1A04B8 for ; Thu, 13 Feb 2014 13:17:50 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i9UuVp4OxAp for ; Thu, 13 Feb 2014 13:17:43 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4331A04E6 for ; Thu, 13 Feb 2014 13:17:43 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 13:17:42 -0800 From: Ron Parker To: Kevin J Ma , Sumandra Majee , "Joel M. Halpern" , Jerome Moisand , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAcmAgAABywCAAAR+gIAAEKYAgAAFrYCAAIVcsA== Date: Thu, 13 Feb 2014 21:17:40 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <291CC3F9E50E7641901A54E85D0977C6D54172F4D2@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D54172F4D2@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6RYBk0rzI6DbMR0jxizvgO6QecA Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:17:51 -0000 Just a thought, here, but what about an inband scheme for long lived metada= ta that is optimized for bidirectional chains? A node that inserts metad= ata in the forward direction would continue inserting until it saw its meta= data echoed back in the reverse direction (i.e., an implicit ack). Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Thursday, February 13, 2014 4:12 PM To: Sumandra Majee; Joel M. Halpern; Jerome Moisand; sfc@ietf.org Subject: Re: [sfc] Framework Sumandra, When you say custom headers, do you mean custom message (e.g., HTTP) headers, or packet headers? Placing message-level metadata into every packet would not seem to me to be a good use of SFC metadata? For a mult-megabyte file, a kilobyte of metadata, relative to the file size might be reasonable, however, relative to each packet sent for that file, the overhead would not make sense? Note: HTTP header insertion is still in-band metadata, it's just may not be of any concern to SFC? -- Kevin J. Ma > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 3:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not=20 > address the majority of requirement. Also a typical http flow carries=20 > many transactions and each can have different or additional=20 > classification. So a metadata can not be simple connected with one=20 > flow either. Current implementations of proxies and load balancers has=20 > addressed this in many ways including custome header insertion. The=20 > custom header in this case equivalent of metadata vector. > > I think we need an efficient way annotate actual data with inline=20 > metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 > [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short=20 > identifier, and using it to select the desired behavior that has been=20 > pre-populated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for=20 > out-of-band metadata. > > However, claiming that a single such correlator is all that is needed=20 > for even 80% of SFC cases (and I very much supporting trying to focus=20 > on the 80% cases), just does not seem to work, given the broad range=20 > of requirements that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: > > Joel, > > > > Protocols like GTP and L2TP work exactly that, with a form of=20 > > session > correlator between the data plane and the control plane. This is very=20 > handy for subscriber and service management. Also if a correlator is=20 > defined as an opaque and unique number, then one can avoid some of the=20 > pitfalls you described. Long-lived metadata is clearly useful (and=20 > thanks for sharing, Reinaldo, will read), and there is clear=20 > applicability to various service chaining needs. > > > > Now this is just one way. The I-D Bruno referred to was just listing > this approach as one possible way among others. I totally agree with=20 > you that other forms of metadata (like an outcome of the=20 > classification of a packet or a sequence of a few packets) may not be=20 > suitable for out-of-band signaling. > > > > Bottomline seems to be that we have too many options to choose from,=20 > > and > none of them solving it all... Tough. > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: Thursday, February 13, 2014 2:29 PM > > To: sfc@ietf.org > > Subject: Re: [sfc] Framework > > > > As I understand it, the tsvwg (and aeon) work is about flow metadata. > > That is long-lived metadata of use across many packets. That does > indeed seem well-suited to out-of-band cases. > > > > My concern is that in SFC, there are many cases which are at best=20 > > badly- > addressed if we insist that they be solved using out-of-band metadata. > > > > Yours, > > Joel > > > > On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: > >> There is draft about transport independent metadata. > >> > >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi > >> ng- > >> 01 > >> > >> The complexities you mention are discussed there:=20 > >> variable-encoding, direction, security of metadata, etc. > >> > >> Thanks, > >> > >> -RP > >> > >> > >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: > >> > >>> While there are cases where out-of-band metadata makes sense,=20 > >>> There are many cases I would not want to try to cover that way. =20 > >>> The best examples are situations where the metadata changes from=20 > >>> packet to packet (such as the data produced by a DPI engine for=20 > >>> consumption by other applications in the chain.) > >>> > >>> More importantly, if you are putting correlators in the packet, it=20 > >>> is still very complex if you want to use one correlator to handle=20 > >>> metadata produced by several different entities (the initial=20 > >>> classifer, the DPI engine, ...) You quickly end up deciding that=20 > >>> you need several correlators. At which point we are back to=20 > >>> variable > amounts of metadata. > >>> > >>> The alternative is to require exceedingly specific and strong=20 > >>> coupling to a mandated out-of-band mechanism. That seems to me to=20 > >>> be a very bad idea. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: > >>>> resend to avoid "too many recipients" warning > >>>> > >>>> > >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 > >>>> > wrote: > >>>> > >>>> There are ways to signal variable length amounts of=20 > >>>> metadata > without > >>>> needing an additional variable-length header on each data > packet. > >>>> > >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some=20 > >>>> of > the > >>>> possible approaches: out-of-band signaling (congruent or > >>>> non-congruent) or a hybrid approach using a fix-length in-band > >>>> correlator and out-of-band additional metadata. See=20 > >>>> sections > 3.3, > >>>> 3.4 and 3.5 in the draft. > >>>> > >>>> The issue of fixed-length encoding versus variable length > encoding > >>>> is discussion in the challenges chapter in section 4.3. I > should > >>>> probably mention the MTU and segmentation issues as well in > that > >>>> section. > >>>> > >>>> > >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern > >>>> > wrote: > >>>> > >>>> The variable length shim header is needed even if every > >>>> individual piece of metadata has a fixed length. Differen= t > >>>> service chains will need different combinations of > metadata. So > >>>> the metadata portion of the header needs to be variable > length. > >>>> > >>>> I think the approach of a fixed length initial part, and a > >>>> variable length extension part, is the right model. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> > >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: > >>>> > >>>> Yes, fragmentation and variable headers are usually=20 > >>>> a > really > >>>> bad thing for forwarding performance. Let's not=20 > >>>> forget > that > >>>> we live in a 100G-ish kind of world nowadays. > >>>> > >>>> Now the question should be: WHY would we want to do > that > >>>> (variable headers leading to fragmentation issues)? > >>>> > >>>> For example, the type of metadata that may require > >>>> variable-length fields might be a better candidate=20 > >>>> for > some > >>>> out-of-band signaling mechanism. If this is service > >>>> authorization data (e.g. a service profile/policy), > this > >>>> sounds likely. Not 100% sure this is true for all=20 > >>>> use > cases > >>>> though. Only a good understanding of use cases, > grounded by > >>>> reflecting on existing network architectures (notably > >>>> broadband, fixed or mobile), would tell us if one > approach > >>>> or another is the most appropriate. > >>>> > >>>> Anyhoo, we're jumping way deep in the detailed protoco= l > >>>> design here. This seems a tad premature. > >>>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org > >>>> ] On Behalf Of Dave Dolso= n > >>>> Sent: Thursday, February 13, 2014 11:03 AM > >>>> To: 'jmh@joelhalpern.com '= ; > >>>> 'Ron_Parker@affirmednetworks.__com > >>>> '; > >>>> 'mohamed.boucadair@orange.com > >>>> '__; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; 'paulq@cisco.co= m > >>>> ' > >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org > '; > >>>> 'linda.dunbar@huawei.com > ' > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> it is overall more efficient to support PMTU discovery > >>>> rather than fragmenting every large packet. The is=20 > >>>> why > TCP > >>>> adopted it so early on. > >>>> > >>>> The fragmenting also puts huge performance burden=20 > >>>> on > the > >>>> service functions. > >>>> Fragmenting may also affect the ability of load > balancers to > >>>> get each fragment to the correct destination. > >>>> > >>>> So PMTU discovery SHOULD be used, in my opinion. By > this I > >>>> mean the client or server is informed that its=20 > >>>> packets > are > >>>> too big (for IPv6 or IPv4 with DF=3D1). > >>>> > >>>> Some operators may wish to incur the extra cost to=20 > >>>> hide > the > >>>> existence of the tunneling, when the elements of=20 > >>>> the > chain > >>>> can support it, so we could consider that as an > optional > >>>> mechanism. > >>>> > >>>> -Dave > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com > >>>> ] > >>>> Sent: Thursday, February 13, 2014 10:31 AM > >>>> To: Ron Parker >>>> >; > >>>> mohamed.boucadair@orange.com > >>>> > >>>> >>>> >__; Dave Dolson; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> ' > >>>> >>>> >; 'paulq@cisco.co= m > >>>> ' >>>> > > >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org > >>>> ' >; > >>>> 'linda.dunbar@huawei.com > ' > >>>> > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> I mostly agree with you Ron. I can probably come=20 > >>>> up > with > >>>> some other variations, but your second point is=20 > >>>> that > the > >>>> transport must deal with the issue of frame size / fit= . > >>>> > >>>> I would note that if we assume that the carrying encap= s > >>>> (IPv4/v6 outer) is being fragmented, then we are > assuming > >>>> that the exit from service chaining can and will > reassemble. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 2/13/14, 10:18 AM, Ron Parker wrote: > >>>> > >>>> Joel, > >>>> > >>>> That is an excellent point to consider when > choosing > >>>> transport > >>>> encapsulations. If the transport encapsulation i= s > IPv4 > >>>> or IPv6 > >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 > >>>> etc.), then > >>>> fragmentation and defragmentation are naturally > >>>> supported. If the > >>>> transport encapsulation is VLAN, MPLS, etc., then = I > >>>> believe one of the > >>>> following must be true: > >>>> > >>>> * The end-to-end path is known to support the > resulting > >>>> larger frames > >>>> * A path discovery mechanism is mandated by SFC > when > >>>> non-IP transports > >>>> are used * An SFC-specific fragmentation header an= d > >>>> mechanisms must be > >>>> defined (i.e., > >>>> > >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o > >>>> r-f > >>>> rame) > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Joel M. Halpern > >>>> [mailto:jmh@joelhalpern.com > >>>> ] Sent: Thursday, > February > >>>> 13, 2014 10:10 > >>>> AM To: mohamed.boucadair@orange.com > >>>> ; Dave Dolson= ; > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; Ron Parker; > >>>> 'paulq@cisco.com ' Cc: > >>>> 'S.Majee@F5.com'; 'sfc@ietf.org > '; > >>>> 'linda.dunbar@huawei.com > >>>> ' Subject: > >>>> Re: [sfc] Framework > >>>> > >>>> There is a related complexity. I hope that we > expect to > >>>> support IPv6. > >>>> IPv6 explicitly prohibits network elements from > >>>> fragmenting end user > >>>> packets. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com > >>>> wrote: > >>>> > >>>> Re-, > >>>> > >>>> FWIW, one of the existing architecture drafts > >>>> includes the following > >>>> behavior > >>>> > >>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02# > >>>> sec > >>>> tion- > >>>> 6 > >>>> > >>>> >>>> ion- > 6>): > >>>> > >>>> > >>>> > >>>> " > >>>> > >>>> 6. Fragmentation Considerations > >>>> > >>>> If adding the Service Chaining Header would > result > >>>> in a fragmented > >>>> packet, the classifier should include a Servic= e > >>>> Chaining Header in > >>>> each fragment. Doing so would prevent SF=20 > >>>> Nodes > to > >>>> dedicate resource > >>>> to handle fragments. " > >>>> > >>>> Cheers, Med > >>>> > >>>> > >>>> -----Message d'origine----- De : sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> De la part de Dave Dolson Envoy=E9 : > >>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : > >>>> 'Nicolas.BOUTHORS@qosmos.com > >>>> '; > >>>> 'Ron_Parker@affirmednetworks.__com > >>>> '; > >>>> 'jmh@joelhalpern.com=20 > >>>> '; > >>>> 'paulq@cisco.com ' > Cc : > >>>> 'S.Majee@F5.com'; 'sfc@ietf.org > >>>> '; > >>>> 'linda.dunbar@huawei.com > >>>> ' Objet : > Re: > >>>> [sfc] Framework > >>>> > >>>> Good point to consider fragmentation. > >>>> > >>>> We should design the encapsulation such > that the > >>>> forwarding > >>>> functions do not need to reassemble. Each > >>>> fragment should be > >>>> independently forwardable; some SFs may > choose > >>>> to ignore these > >>>> packets. > >>>> > >>>> Any layer 2.5 protocol like VLAN or=20 > >>>> MPLS > would > >>>> support this. > >>>> Otherwise, a reassembly layer could be > added > >>>> after the forwarding > >>>> coordinates. Think of something like=20 > >>>> the > IPv6 > >>>> reassembly option > >>>> after a GRE header, for instance. > >>>> > >>>> IP | GRE | reassem | frag data > >>>> > >>>> We could alternatively mandate the=20 > >>>> inner IP > be > >>>> fragmented and that > >>>> path-MTU discovery be supported. > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- From:=20 > >>>> Nicolas BOUTHORS > >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com > >>>> ] Sent= : > >>>> Thursday, February 13, > >>>> 2014 04:13 AM To: Ron Parker > >>>> >>>> >; > >>>> Dave Dolson; Joel M. Halpern > >>>> >>>> >; Paul Quinn > >>>> (paulq) >>>> > Cc: Sumandra > Majee > >>>> ; > >>>> sfc@ietf.org > >>>> >; Linda Dunbar > >>>> >>>> > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> If we do not enforce a fix header size=20 > >>>> we > have > >>>> other implication. > >>>> > >>>> There is the question of segmentation and > >>>> reassembly responsibility > >>>> as well. > >>>> > >>>> If adding length to the service header > forces > >>>> segmentation, then > >>>> whose responsibility is it to=20 > >>>> reassemble > the > >>>> payload before passing > >>>> it to the SF. > >>>> > >>>> Similar question for packet re-ordering. > >>>> > >>>> > >>>> =20 > >>>> __________________________________________ > From: > >>>> Ron Parker > >>>> [Ron_Parker@affirmednetworks.__com > >>>> =20 > >>>> ] > Sent: > >>>> Wednesday, February 12, > >>>> 2014 11:25 PM To: Dave Dolson; Joel M. > Halpern; > >>>> Paul Quinn > >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: > >>>> Re: [sfc] Framework > >>>> > >>>> Dave, > >>>> > >>>> Yes, that is a good point if we logically > >>>> separate the forwarding > >>>> function from the SFC-aware service > function, as > >>>> we should. The > >>>> forwarding function is concerned with=20 > >>>> only > the > >>>> inbound transport > >>>> header, the fixed portion of the=20 > >>>> service > header > >>>> containing the > >>>> chain information, and the outbound > transport > >>>> header. The > >>>> service function may look at the=20 > >>>> entirety > of the > >>>> service header and > >>>> would look at the encapsulated packet. > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: Dave > Dolson > >>>> [mailto:ddolson@sandvine.com > >>>> ] Sent: > Wednesday, > >>>> February 12, 2014 > >>>> 5:18 PM To: Joel M. Halpern; Ron=20 > >>>> Parker; > Paul > >>>> Quinn (paulq) Cc: > >>>> Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: RE: > >>>> [sfc] > >>>> Framework > >>>> > >>>> The forwarding plane might not even=20 > >>>> need to > look > >>>> at the encapsulated > >>>> packet. > >>>> > >>>> For example, (if the SF Identifier is a > VLAN > >>>> tag), an Ethernet > >>>> switch can forward packets of the form: > Ether | > >>>> VLAN | BLOB. > >>>> > >>>> > >>>> > >>>> -----Original Message----- From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> On Behalf Of Joel M. Halpern Sent: > >>>> Wednesday, February 12, 2014 4:30 PM To: > Ron > >>>> Parker; Dave Dolson; > >>>> Paul Quinn (paulq) Cc: Sumandra Majee; > >>>> sfc@ietf.org ;=20 > >>>> Linda > Dunbar > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> I agree as well. Yours, Joel > >>>> > >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: > >>>> > >>>> Hi, Dave. > >>>> > >>>> I Agree with your statement. And i= f > the > >>>> total length of the > >>>> header is > >>>> > >>>> contained in the mandatory portion, the > hardware > >>>> implementation can > >>>> easily locate the encapsulated packet. > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From:=20 > >>>> Dave > Dolson > >>>> [mailto:ddolson@sandvine.com > >>>> ] Sent: > >>>> Wednesday, February 12, > >>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n > >>>> (paulq) Cc: Joel M. > >>>> Halpern; Sumandra Majee; sfc@ietf.org > >>>> ; Linda Dunbar > Subject: > >>>> RE: [sfc] Framework > >>>> > >>>> I think a good approach would be: > >>>> > >>>> The information required for=20 > >>>> forwarding > (the > >>>> SF Identifier) should > >>>> be in > >>>> > >>>> a mandatory fixed-size header. > >>>> > >>>> > >>>> Optional information (if any) is=20 > >>>> NOT to > be > >>>> used for forwarding, but > >>>> is > >>>> > >>>> for consumption by one or more of the > >>>> applications in the chain. > >>>> > >>>> > >>>> Then the forwarding plane, and even=20 > >>>> the > PDP, > >>>> can be agnostic about > >>>> the > >>>> > >>>> meta-data. > >>>> > >>>> > >>>> -Dave > >>>> > >>>> > >>>> -----Original Message----- From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> ] > >>>> On Behalf Of Ron Parker Sent: > >>>> Wednesday, February 12, 2014 4:05=20 > >>>> PM > To: > >>>> Paul Quinn (paulq) Cc: > >>>> Joel M. Halpern; Sumandra Majee; > >>>> sfc@ietf.org ;=20 > >>>> Linda Dunbar > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> Paul, > >>>> > >>>> That is why I am proposing a hybrid > where > >>>> extensions or options can > >>>> be > >>>> > >>>> added but the total length is contained=20 > >>>> in > the > >>>> fixed portion. I > >>>> can envision certain deployments (e.g., > >>>> Enterprise) where perhaps > >>>> extensions are not needed and the SFC > >>>> functionality is realized > >>>> in hardware. And, I can envision certain > other > >>>> deployments > >>>> (e.g., 3gpp) where the extension=20 > >>>> headers > add > >>>> sufficient value to > >>>> justify software based implementations. > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From:=20 > >>>> Paul > Quinn > >>>> (paulq) > >>>> [mailto:paulq@cisco.com > >>>> ] Sent: > Wednesday, > >>>> February 12, 2014 > >>>> 3:40 PM To: Ron Parker Cc: Sumandra > Majee; > >>>> Linda Dunbar; Joel M. > >>>> Halpern; sfc@ietf.org > > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> Hi, > >>>> > >>>> We certainly need to be very=20 > >>>> careful > with > >>>> variable length headers > >>>> when > >>>> > >>>> hardware platform are in play. > >>>> > >>>> > >>>> Ron, your examples of IP options=20 > >>>> and v6 > EH > >>>> have both suffered from > >>>> > >>>> significant implementation and deployment > >>>> hurdles due to the > >>>> complexity and cost associated with > hardware > >>>> support for the > >>>> option/EH. > >>>> > >>>> > >>>> Paul > >>>> > >>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r > >>>> >>>> > >>>> > > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Hi, Sumandra. > >>>> > >>>> Regarding service header > flexibility, I > >>>> completely agree. I > >>>> might > >>>> > >>>> suggest a compromise between hardware > >>>> friendliness and software > >>>> flexibility. If the header had the > ability to > >>>> add extensions > >>>> (perhaps similar to IPv6) but also had the > >>>> header length encoded in > >>>> the mandatory part (like IPv4), then a > hardware > >>>> implementation would > >>>> be free to skip over the extensions (in > cases > >>>> where the deployment > >>>> justifies ignoring the extensions). > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- From: > >>>> Sumandra Majee > >>>> [mailto:S.Majee@F5.com > >>>> ] Sent: > >>>> Wednesday, February 12, 2014 > >>>> 3:04 PM To: Ron Parker; Linda > Dunbar; > >>>> Joel M. Halpern; > >>>> sfc@ietf.org > >>>> Subject: Re: [sfc] Framework > >>>> > >>>> For all of those reasons, = I > >>>> strongly support a=20 > >>>> canonical service > >>>> header that is=20 > >>>> independent > of > >>>> the transport methodology. > >>>> > >>>> > >>>> > >>>> I agree. However the format of > service > >>>> header should be > >>>> standardized in > >>>> > >>>> a way that is flexible. Some of us=20 > >>>> would > like to > >>>> see variable length > >>>> header that is also HW friendly. The > service > >>>> header can be > >>>> represented as a mandotory fixed length > header > >>>> (like IP > >>>> header) along with an optional variable > length > >>>> attribute field. > >>>> Different services can be interested in > >>>> different metadata, for > >>>> example subscriber ID could be of=20 > >>>> interest > in > >>>> the mobile core > >>>> service chain only. > >>>> > >>>> > >>>> Sumandra > >>>> > >>>> On 2/12/14, 11:32 AM, "Ron Parker" > >>>> =20 > >>>> >>>> > >>>> > > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Linda, > >>>> > >>>> My interpretation of the > >>>> architecture docs is that=20 > >>>> the service > >>>> function chain is built in an > >>>> abstract manner (i.e., SF-A > then > >>>> SF-B > >>>> > >>>> then SF-C). > >>>> > >>>> Separately, a locator table > provides > >>>> network location for > >>>> each of those service > functions. > >>>> In this way, you can > >>>> locate the service=20 > >>>> functions > >>>> > >>>> in > >>>> > >>>> a manner appropriate to the > type of > >>>> transport you are > >>>> using. If you want that to b= e > >>>> interface+VLAN, > >>>> gateway-IP+MPLS label=20 > >>>> stack, IP > >>>> > >>>> address, > >>>> > >>>> GRE tunnel remote IP + key, > etc., > >>>> you can do that. You > >>>> can even potentially locate > >>>> different service functions > that > >>>> reside in the same chain with > >>>> different flavors of > >>>> network locators. Another > >>>> justification to separate the > >>>> identity of a service=20 > >>>> function > from > >>>> its network location is > >>>> load balancing. If, for > example, > >>>> SF-A had 3 IP addresses, > >>>> that would imply load=20 > >>>> balancing > to 3 > >>>> instances using IP as a > >>>> transport layer. > >>>> > >>>> For all of those reasons, I > strongly > >>>> support a canonical service > >>>> header that is independent=20 > >>>> of > the > >>>> transport > >>>> methodology. At a particula= r > >>>> node, the decision as to > >>>> where to go next should be > based > >>>> solely on information=20 > >>>> carried > in > >>>> the canonical service=20 > >>>> header > and not > >>>> on the > >>>> > >>>> fields > >>>> > >>>> in the transport header. Tha= t > is, > >>>> the SFC node discards > >>>> the transport header and > extracts > >>>> the chain ID from the > >>>> service header. Through > >>>> mechanisms we have not yet > begun > >>>> to discuss, the SFC node=20 > >>>> knows > how > >>>> to interpret the chain ID and > >>>> ultimately how to progress=20 > >>>> the packet. > >>>> > >>>> Ron > >>>> > >>>> > >>>> -----Original Message----- > From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> =20 > >>>> ] > On > >>>> Behalf Of Linda Dunbar > >>>> Sent: Wednesday, February=20 > >>>> 12, > 2014 > >>>> 12:01 PM To: Joel M. > >>>> Halpern; sfc@ietf.org > >>>> Subject: > Re: > >>>> [sfc] Framework > >>>> > >>>> Agree with Joel's statement. > >>>> > >>>> I think a simple sentence belo= w > >>>> should be added Section 5.2 > (SFC > >>>> Classifier) to emphasize=20 > >>>> this > point. > >>>> > >>>> "A Service Chain Classifier > node can > >>>> associate a unique Layer 2 > >>>> or 3 Label (e.g. VLAN, MPLS > label) > >>>> to the packets in the flow. > >>>> Those Layer 2 or 3 Label=20 > >>>> makes > it > >>>> easier for subsequent nodes > >>>> along the flow path to=20 > >>>> steer > the > >>>> flow to the service functions > >>>> specified by the flow's=20 > >>>> service chain." > >>>> > >>>> > >>>> Linda -----Original=20 > >>>> Message---- > - > >>>> From: sfc > >>>> [mailto:sfc-bounces@ietf.org > >>>> =20 > >>>> ] > On > >>>> Behalf Of Joel M. Halpern > >>>> Sent: Wednesday, February=20 > >>>> 12, > 2014 > >>>> 10:20 AM To: > >>>> sfc@ietf.org > > >>>> Subject: [sfc] Framework > >>>> > >>>> I was looking at the framework > >>>> proposal. The proposal has=20 > >>>> a > very > >>>> specific model of the scope=20 > >>>> of > the > >>>> transport header (that it is > >>>> derived from, and relates=20 > >>>> only > to, > >>>> the first service function to > >>>> which the packet will be > directed. > >>>> That is clearly an operational > >>>> model we need to support. > >>>> > >>>> However, I would like to=20 > >>>> allow > other > >>>> transport operational > >>>> models, such as the use of=20 > >>>> a > VLAN to > >>>> direct traffic along a > >>>> chain. Or the use of an=20 > >>>> MPLS > label, > >>>> or an MPLS label stack. > >>>> > >>>> Yours, Joel M. Halpern > >>>> > >>>> > >>>> _________________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org=20 > >>>> > >>>> > >>>> https://www.ietf.org/mailman/__listinfo/sfc > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org=20 > >>>> > >>>> > >>>> https://www.ietf.org/mailman/__listinfo/sfc > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org=20 > >>>> > >>>> > >>>> https://www.ietf.org/mailman/__listinfo/sfc > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org=20 > >>>> > >>>> > >>>> 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/sf= c > >>>> =20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ sfc > >>>> mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/sf= c > >>>> =20 > >>>> > >>>> > >>>> > >>>> _________________________________________________ sfc > >>>> mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/sf= c > >>>> =20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> 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 > > > > > > > > > > _______________________________________________ > 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 Feb 13 15:17:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E951A0504 for ; Thu, 13 Feb 2014 15:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 h0kDug_Iu0y2 for ; Thu, 13 Feb 2014 15:16:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5011A0019 for ; Thu, 13 Feb 2014 15:16:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDO46024; Thu, 13 Feb 2014 23:16:48 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 23:16:29 +0000 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 23:16:47 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml706-chm.china.huawei.com ([169.254.8.193]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 15:16:36 -0800 From: Linda Dunbar To: Jerome Moisand , Alla Goldner , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPHQDf7LrqU5IwJEm2rsSmjT9Ll5qmCQKAgAH2hQCAAmPrAIADhxoAgAROqDCAARl1AIAAmWyAgAANm4CAAAP8gP//6Xrw Date: Thu, 13 Feb 2014 23:16:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6WBw-qM95VJt8wBPOH7Czp3l1MQ Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:17:02 -0000 Alla, Jerome,=20 Since 3GPP has defined many components and are still involving, can we use = a simplified box to represent an entity associated with P-GW that classifie= s the traffic based on PCRF rules, TDF, and/or PCEF? Such as: | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF/| | |Network| =20 |rules| < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 V | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| & or | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> |TDF/PCEF | | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network As for the description of metadata used by Gi-LAN service function, we don'= t have to specifically say which elements defined by 3GPP encoded them in.= =20 Linda -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Thursday, February 13, 2014 10:30 AM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt I don't know if the whole PCC architecture is truly optional in 3GPP theory= (I've never seen it expressed that way, but I'll take your word for it), b= ut one would be hard-pressed to find a 3G/LTE mobile broadband network with= out it. So in practice my 100% statement remains true (I'll give you 99.9% = if you wish!).=20 So I have a bit of an issue putting PGW and TDF at the same level. This sim= ply doesn't reflect any reality, nor the spirit of the 3GPP specs. And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory (= I took a very active role in several of those specs, e.g. TR-101). While a = DPI function is truly optional (and not that many subscribers in absolute %= go through it in practice) and not standardized. Anyway, I agree with you that mobile use cases with or without TDF should b= e considered. A case without PGW would seem much more dubious to me. We may= be saying more or the same thing, overall. -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, February 13, 2014 11:15 AM To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interface= is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optional in= exactly the same way. The whole 3GPP PCC architecture is optional. Therefo= re, the claim about 100% of mobile data subscribers may not be fully correc= t. And with regards to the features required for service classification and= service enforcement that you describe below - they are present at both GG= SN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier OF = COURSE should be considered, same as use cases where TDF is considered as a= classifier. And, once describing those use cases, the existing 3GPP archit= ecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Alla & folks, Well... I don't know... Getting deep in network architectures and the role = of the various network elements is indeed crucial. Both 3GPP and BBF (Broad= band Forum) did a lot of work in the past decade to define architecture & n= odal requirements, which shaped in turn the deployment of all major Service= Providers worldwide. So quite clearly, service chaining have to build on t= hat and find a good way to insert itself into such architectures while exte= nding them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for s= ervice classification/enforcement, as it... already does it for its own pur= pose! This is BY NATURE a highly scalable subscriber & service management s= ystem, classifying and enforcing policies (usually L3, occasionally higher)= , and fully integrated with the HSS/PCRF chain which holds the subscriber/s= ervice authentication & authorization data. As such, service classification= *and* service enforcement (and service accounting) is already there. For 1= 00% of the mobile (data) subscribers. Sure enough, a TDF system may also do= its own form of service classification (and processing too), but let's not= forget this is an OPTIONAL system on the data path on the recently defined= 3GPP architectures you referred to. For many use cases, there is just no p= oint going through a DPI function. While for other use cases, there is clea= rly such a point, but only when it brings clear value for a given service c= onstruct, only applicable to corresponding subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary su= bscriber management system on the data path, fully integrated with a AAA sy= stem, and already doing service classification *and* service processing at = scale for 100% of the subscribers. Any classification/enforcement system be= hind it is optional and only applicable to a subset of services & subscribe= rs. Bottomline: sure, use cases with TDF should be described, but PGW-centric u= se cases remain the rule, not the exception. And double-clicking on existin= g standardized network architectures (e.g. 3GPP and BBF) and related deploy= ments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE;= Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tool= s.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Function= ) for providing ADC (Application Detection and Control) Rules for applicati= on detection, enforcement and also charging starting from R12. Please see a= rchitecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with th= e GGSN (via Diameter), not the service functions, do you mean "for the GGSN= (or the flow classifier) to carry the data passed down from PCRF to packet= s' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service treatm= ent, i.e. desired sequence of service functions, to specific flows based on= the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions." is not correct as well as PGW/PC= EF is not the only element which enforces different support per different f= lows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architectur= e and make assumptions and conclusions about potential 3GPP elements functi= onality which are not in scope of IETF. If we want to define use cases for = 3GPP networks, then we should show correct picture of 3GPP architecture wi= thout redesigning it and leave 3GPP Network Elements functionality potentia= l extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; = Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sf= c@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID?=20 I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good.=20 Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions.=20 =20 | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF | | |Network| =20 | | < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 | | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph=20 >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not=20 >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### From nobody Thu Feb 13 16:16:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF61A03ED for ; Thu, 13 Feb 2014 16:15:58 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pNYQ5ztv3a4 for ; Thu, 13 Feb 2014 16:15:57 -0800 (PST) Received: from smtp97.ord1c.emailsrvr.com (smtp97.ord1c.emailsrvr.com [108.166.43.97]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA31A054E for ; Thu, 13 Feb 2014 16:15:57 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DCB6B1B0292; Thu, 13 Feb 2014 19:15:55 -0500 (EST) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 9B7E01B029A; Thu, 13 Feb 2014 19:15:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Barry Greene In-Reply-To: <1191180552.37515.1392312065690.JavaMail.tomcat@mgs-aam01.mail.aol.com> Date: Fri, 14 Feb 2014 07:15:43 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51DD8C2A-73F8-42EE-BCC7-CA5D1128F911@senki.org> References: <1191180552.37515.1392312065690.JavaMail.tomcat@mgs-aam01.mail.aol.com> To: mikebianc@aol.com X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/snbzrEdSgS3vFDoYCmhgE2IqZus Cc: sfc@ietf.org, Ron_Parker@affirmednetworks.com Subject: Re: [sfc] MTU X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:15:59 -0000 On Feb 14, 2014, at 12:21 AM, mikebianc@aol.com wrote: > The draft text on this could be as simple as requiring that any SFC = implementation send back an appropriate MTU for the sender to use based = on the header that would have been applied, leaving the 'how' up to = implementation Agreed. You need this to troubleshoot the corner cases.=20= From nobody Thu Feb 13 16:19:10 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0361A0008 for ; Thu, 13 Feb 2014 16:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 q1UbUJKUFW8K for ; Thu, 13 Feb 2014 16:19:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C98DC1A0007 for ; Thu, 13 Feb 2014 16:19:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBC26213; Fri, 14 Feb 2014 00:18:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 00:18:39 +0000 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 00:18:57 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml704-chm.china.huawei.com ([169.254.6.202]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 16:18:48 -0800 From: Linda Dunbar To: Sumandra Majee , "Joel M. Halpern" , Jerome Moisand , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5erGoSE8UFskudetbNVt6AL5qx1MWAgACzbQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAciAgAABywCAAAR/gIAAEKUA//+tGDA= Date: Fri, 14 Feb 2014 00:18:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iyZYSTTCPooUczUdFhqmVUM63xU Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:19:09 -0000 I see two types of "metadata" being discussed here: 1. The "flow metadata", like the transactions carried by http flows. They = are inserted by applications, or inserted by a service function to pass som= e "cookies" to the next one. (many proxy based service functions have those= capability) 2. The "Service Chain metadata", that are inserted by "Chain Classifier" o= r control plane to carry extra information (in additional to Chain ID) for = the purpose of controlling the sequence of functions on a chain.=20 Correct?=20 IMHO, the first bullet above are specific to applications or service functi= ons internal processing. Many of today's proxy based service functions make= changes to data packets, some of them make those changes for other service= functions. Those changes won't be in the Service Chain Header field.=20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Thursday, February 13, 2014 2:51 PM To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org Subject: Re: [sfc] Framework I believe most of us agree that an out of bad signalling will not address t= he majority of requirement. Also a typical http flow carries many transacti= ons and each can have different or additional classification. So a metadata= can not be simple connected with one flow either. Current implementations = of proxies and load balancers has addressed this in many ways including cus= tome header insertion. The custom header in this case equivalent of metadat= a vector.=20 I think we need an efficient way annotate actual data with inline metadata.= I also strongly believe in solving the 80% of the use case Regards Sumandra ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalp= ern.com] Sent: Thursday, February 13, 2014 11:51 AM To: Jerome Moisand; sfc@ietf.org Subject: Re: [sfc] Framework I know very well what GTP does in terms of correlators, and why. If all you need is an identifier for the subscriber, carrying a short ident= ifier, and using it to select the desired behavior that has been pre-popula= ted when the subscribers session starts works really well. That is part of why I am not objecting to having provision for out-of-band = metadata. However, claiming that a single such correlator is all that is needed for e= ven 80% of SFC cases (and I very much supporting trying to focus on the 80%= cases), just does not seem to work, given the broad range of requirements = that we have seen. Yours, Joel On 2/13/14, 2:35 PM, Jerome Moisand wrote: > Joel, > > Protocols like GTP and L2TP work exactly that, with a form of session cor= relator between the data plane and the control plane. This is very handy fo= r subscriber and service management. Also if a correlator is defined as an = opaque and unique number, then one can avoid some of the pitfalls you descr= ibed. Long-lived metadata is clearly useful (and thanks for sharing, Reinal= do, will read), and there is clear applicability to various service chainin= g needs. > > Now this is just one way. The I-D Bruno referred to was just listing this= approach as one possible way among others. I totally agree with you that o= ther forms of metadata (like an outcome of the classification of a packet o= r a sequence of a few packets) may not be suitable for out-of-band signalin= g. > > Bottomline seems to be that we have too many options to choose from, and = none of them solving it all... Tough. > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, February 13, 2014 2:29 PM > To: sfc@ietf.org > Subject: Re: [sfc] Framework > > As I understand it, the tsvwg (and aeon) work is about flow metadata. > That is long-lived metadata of use across many packets. That does indeed= seem well-suited to out-of-band cases. > > My concern is that in SFC, there are many cases which are at best badly-a= ddressed if we insist that they be solved using out-of-band metadata. > > Yours, > Joel > > On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >> There is draft about transport independent metadata. >> >> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding >> - >> 01 >> >> The complexities you mention are discussed there: variable-encoding,=20 >> direction, security of metadata, etc. >> >> Thanks, >> >> -RP >> >> >> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >> >>> While there are cases where out-of-band metadata makes sense, There=20 >>> are many cases I would not want to try to cover that way. The best=20 >>> examples are situations where the metadata changes from packet to=20 >>> packet (such as the data produced by a DPI engine for consumption by=20 >>> other applications in the chain.) >>> >>> More importantly, if you are putting correlators in the packet, it=20 >>> is still very complex if you want to use one correlator to handle=20 >>> metadata produced by several different entities (the initial=20 >>> classifer, the DPI engine, ...) You quickly end up deciding that=20 >>> you need several correlators. At which point we are back to variable a= mounts of metadata. >>> >>> The alternative is to require exceedingly specific and strong=20 >>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>> be a very bad idea. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>> resend to avoid "too many recipients" warning >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>> > wrote: >>>> >>>> There are ways to signal variable length amounts of metadata wit= hout >>>> needing an additional variable-length header on each data packet= . >>>> >>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of t= he >>>> possible approaches: out-of-band signaling (congruent or >>>> non-congruent) or a hybrid approach using a fix-length in-band >>>> correlator and out-of-band additional metadata. See sections 3.= 3, >>>> 3.4 and 3.5 in the draft. >>>> >>>> The issue of fixed-length encoding versus variable length encodi= ng >>>> is discussion in the challenges chapter in section 4.3. I shoul= d >>>> probably mention the MTU and segmentation issues as well in that >>>> section. >>>> >>>> >>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>> > wrote: >>>> >>>> The variable length shim header is needed even if every >>>> individual piece of metadata has a fixed length. Different >>>> service chains will need different combinations of metadata.= So >>>> the metadata portion of the header needs to be variable leng= th. >>>> >>>> I think the approach of a fixed length initial part, and a >>>> variable length extension part, is the right model. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>> >>>> Yes, fragmentation and variable headers are usually a re= ally >>>> bad thing for forwarding performance. Let's not forget t= hat >>>> we live in a 100G-ish kind of world nowadays. >>>> >>>> Now the question should be: WHY would we want to do that >>>> (variable headers leading to fragmentation issues)? >>>> >>>> For example, the type of metadata that may require >>>> variable-length fields might be a better candidate for s= ome >>>> out-of-band signaling mechanism. If this is service >>>> authorization data (e.g. a service profile/policy), this >>>> sounds likely. Not 100% sure this is true for all use ca= ses >>>> though. Only a good understanding of use cases, grounded= by >>>> reflecting on existing network architectures (notably >>>> broadband, fixed or mobile), would tell us if one approa= ch >>>> or another is the most appropriate. >>>> >>>> Anyhoo, we're jumping way deep in the detailed protocol >>>> design here. This seems a tad premature. >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org >>>> ] On Behalf Of Dave Dolson >>>> Sent: Thursday, February 13, 2014 11:03 AM >>>> To: 'jmh@joelhalpern.com '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'mohamed.boucadair@orange.com >>>> '__; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; 'paulq@cisco.com >>>> ' >>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>> 'linda.dunbar@huawei.com ' >>>> Subject: Re: [sfc] Framework >>>> >>>> it is overall more efficient to support PMTU discovery >>>> rather than fragmenting every large packet. The is why T= CP >>>> adopted it so early on. >>>> >>>> The fragmenting also puts huge performance burden on the >>>> service functions. >>>> Fragmenting may also affect the ability of load balancer= s to >>>> get each fragment to the correct destination. >>>> >>>> So PMTU discovery SHOULD be used, in my opinion. By this= I >>>> mean the client or server is informed that its packets a= re >>>> too big (for IPv6 or IPv4 with DF=3D1). >>>> >>>> Some operators may wish to incur the extra cost to hide = the >>>> existence of the tunneling, when the elements of the cha= in >>>> can support it, so we could consider that as an optional >>>> mechanism. >>>> >>>> -Dave >>>> >>>> >>>> ----- Original Message ----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>> ] >>>> Sent: Thursday, February 13, 2014 10:31 AM >>>> To: Ron Parker >>> >; >>>> mohamed.boucadair@orange.com >>>> >>>> >>> >__; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> ' >>>> >>> >; 'paulq@cisco.com >>>> ' >>> > >>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>> ' >; >>>> 'linda.dunbar@huawei.com ' >>>> > >>>> Subject: Re: [sfc] Framework >>>> >>>> I mostly agree with you Ron. I can probably come up wit= h >>>> some other variations, but your second point is that the >>>> transport must deal with the issue of frame size / fit. >>>> >>>> I would note that if we assume that the carrying encaps >>>> (IPv4/v6 outer) is being fragmented, then we are assumin= g >>>> that the exit from service chaining can and will reassem= ble. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>> >>>> Joel, >>>> >>>> That is an excellent point to consider when choosing >>>> transport >>>> encapsulations. If the transport encapsulation is = IPv4 >>>> or IPv6 >>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>>> etc.), then >>>> fragmentation and defragmentation are naturally >>>> supported. If the >>>> transport encapsulation is VLAN, MPLS, etc., then I >>>> believe one of the >>>> following must be true: >>>> >>>> * The end-to-end path is known to support the result= ing >>>> larger frames >>>> * A path discovery mechanism is mandated by SFC when >>>> non-IP transports >>>> are used * An SFC-specific fragmentation header and >>>> mechanisms must be >>>> defined (i.e., >>>> >>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or- >>>> f >>>> rame) >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com >>>> ] Sent: Thursday, Februa= ry >>>> 13, 2014 10:10 >>>> AM To: mohamed.boucadair@orange.com >>>> ; Dave Dolson; >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; Ron Parker; >>>> 'paulq@cisco.com ' Cc: >>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>> 'linda.dunbar@huawei.com >>>> ' Subject: >>>> Re: [sfc] Framework >>>> >>>> There is a related complexity. I hope that we expect= to >>>> support IPv6. >>>> IPv6 explicitly prohibits network elements from >>>> fragmenting end user >>>> packets. >>>> >>>> Yours, Joel >>>> >>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>> wrote: >>>> >>>> Re-, >>>> >>>> FWIW, one of the existing architecture drafts >>>> includes the following >>>> behavior >>>> >>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#se >>>> c >>>> tion- >>>> 6 >>>> >>>> ): >>>> >>>> >>>> >>>> " >>>> >>>> 6. Fragmentation Considerations >>>> >>>> If adding the Service Chaining Header would resu= lt >>>> in a fragmented >>>> packet, the classifier should include a Service >>>> Chaining Header in >>>> each fragment. Doing so would prevent SF Nodes = to >>>> dedicate resource >>>> to handle fragments. " >>>> >>>> Cheers, Med >>>> >>>> >>>> -----Message d'origine----- De : sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> De la part de Dave Dolson Envoy=E9 : >>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>> 'Nicolas.BOUTHORS@qosmos.com >>>> '; >>>> 'Ron_Parker@affirmednetworks.__com >>>> '; >>>> 'jmh@joelhalpern.com=20 >>>> '; >>>> 'paulq@cisco.com ' C= c : >>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>> '; >>>> 'linda.dunbar@huawei.com >>>> ' Objet : Re= : >>>> [sfc] Framework >>>> >>>> Good point to consider fragmentation. >>>> >>>> We should design the encapsulation such that= the >>>> forwarding >>>> functions do not need to reassemble. Each >>>> fragment should be >>>> independently forwardable; some SFs may choo= se >>>> to ignore these >>>> packets. >>>> >>>> Any layer 2.5 protocol like VLAN or MPLS wou= ld >>>> support this. >>>> Otherwise, a reassembly layer could be added >>>> after the forwarding >>>> coordinates. Think of something like the IPv= 6 >>>> reassembly option >>>> after a GRE header, for instance. >>>> >>>> IP | GRE | reassem | frag data >>>> >>>> We could alternatively mandate the inner IP = be >>>> fragmented and that >>>> path-MTU discovery be supported. >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- From:=20 >>>> Nicolas BOUTHORS >>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>> ] Sent: >>>> Thursday, February 13, >>>> 2014 04:13 AM To: Ron Parker >>>> >>> >; >>>> Dave Dolson; Joel M. Halpern >>>> >>> >; Paul Quinn >>>> (paulq) >>> > Cc: Sumandra Majee >>>> ; >>>> sfc@ietf.org >>> >; Linda Dunbar >>>> >>> > >>>> Subject: Re: [sfc] Framework >>>> >>>> If we do not enforce a fix header size we ha= ve >>>> other implication. >>>> >>>> There is the question of segmentation and >>>> reassembly responsibility >>>> as well. >>>> >>>> If adding length to the service header force= s >>>> segmentation, then >>>> whose responsibility is it to reassemble the >>>> payload before passing >>>> it to the SF. >>>> >>>> Similar question for packet re-ordering. >>>> >>>> >>>> __________________________________________ F= rom: >>>> Ron Parker >>>> [Ron_Parker@affirmednetworks.__com >>>> ] Se= nt: >>>> Wednesday, February 12, >>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpe= rn; >>>> Paul Quinn >>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject: >>>> Re: [sfc] Framework >>>> >>>> Dave, >>>> >>>> Yes, that is a good point if we logically >>>> separate the forwarding >>>> function from the SFC-aware service function= , as >>>> we should. The >>>> forwarding function is concerned with only t= he >>>> inbound transport >>>> header, the fixed portion of the service he= ader >>>> containing the >>>> chain information, and the outbound transpor= t >>>> header. The >>>> service function may look at the entirety of= the >>>> service header and >>>> would look at the encapsulated packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Dolson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: Wednesd= ay, >>>> February 12, 2014 >>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Pau= l >>>> Quinn (paulq) Cc: >>>> Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subject:= RE: >>>> [sfc] >>>> Framework >>>> >>>> The forwarding plane might not even need to = look >>>> at the encapsulated >>>> packet. >>>> >>>> For example, (if the SF Identifier is a VLAN >>>> tag), an Ethernet >>>> switch can forward packets of the form: Eth= er | >>>> VLAN | BLOB. >>>> >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Joel M. Halpern Sent: >>>> Wednesday, February 12, 2014 4:30 PM To: Ron >>>> Parker; Dave Dolson; >>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>> sfc@ietf.org ; Linda Du= nbar >>>> Subject: Re: [sfc] Framework >>>> >>>> I agree as well. Yours, Joel >>>> >>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>> >>>> Hi, Dave. >>>> >>>> I Agree with your statement. And if = the >>>> total length of the >>>> header is >>>> >>>> contained in the mandatory portion, the hard= ware >>>> implementation can >>>> easily locate the encapsulated packet. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Dave Do= lson >>>> [mailto:ddolson@sandvine.com >>>> ] Sent: >>>> Wednesday, February 12, >>>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>>> (paulq) Cc: Joel M. >>>> Halpern; Sumandra Majee; sfc@ietf.org >>>> ; Linda Dunbar Subj= ect: >>>> RE: [sfc] Framework >>>> >>>> I think a good approach would be: >>>> >>>> The information required for forwarding = (the >>>> SF Identifier) should >>>> be in >>>> >>>> a mandatory fixed-size header. >>>> >>>> >>>> Optional information (if any) is NOT to = be >>>> used for forwarding, but >>>> is >>>> >>>> for consumption by one or more of the >>>> applications in the chain. >>>> >>>> >>>> Then the forwarding plane, and even the = PDP, >>>> can be agnostic about >>>> the >>>> >>>> meta-data. >>>> >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] >>>> On Behalf Of Ron Parker Sent: >>>> Wednesday, February 12, 2014 4:05 PM To: >>>> Paul Quinn (paulq) Cc: >>>> Joel M. Halpern; Sumandra Majee; >>>> sfc@ietf.org ;=20 >>>> Linda Dunbar >>>> Subject: Re: [sfc] Framework >>>> >>>> Paul, >>>> >>>> That is why I am proposing a hybrid wher= e >>>> extensions or options can >>>> be >>>> >>>> added but the total length is contained in t= he >>>> fixed portion. I >>>> can envision certain deployments (e.g., >>>> Enterprise) where perhaps >>>> extensions are not needed and the SFC >>>> functionality is realized >>>> in hardware. And, I can envision certain o= ther >>>> deployments >>>> (e.g., 3gpp) where the extension headers add >>>> sufficient value to >>>> justify software based implementations. >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Paul Qu= inn >>>> (paulq) >>>> [mailto:paulq@cisco.com >>>> ] Sent: Wednesda= y, >>>> February 12, 2014 >>>> 3:40 PM To: Ron Parker Cc: Sumandra Maje= e; >>>> Linda Dunbar; Joel M. >>>> Halpern; sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> Hi, >>>> >>>> We certainly need to be very careful wit= h >>>> variable length headers >>>> when >>>> >>>> hardware platform are in play. >>>> >>>> >>>> Ron, your examples of IP options and v6 = EH >>>> have both suffered from >>>> >>>> significant implementation and deployment >>>> hurdles due to the >>>> complexity and cost associated with hardware >>>> support for the >>>> option/EH. >>>> >>>> >>>> Paul >>>> >>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>> >>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> Hi, Sumandra. >>>> >>>> Regarding service header flexibility= , I >>>> completely agree. I >>>> might >>>> >>>> suggest a compromise between hardware >>>> friendliness and software >>>> flexibility. If the header had the abilit= y to >>>> add extensions >>>> (perhaps similar to IPv6) but also had the >>>> header length encoded in >>>> the mandatory part (like IPv4), then a hardw= are >>>> implementation would >>>> be free to skip over the extensions (in case= s >>>> where the deployment >>>> justifies ignoring the extensions). >>>> >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: >>>> Sumandra Majee >>>> [mailto:S.Majee@F5.com >>>> ] Sent: >>>> Wednesday, February 12, 2014 >>>> 3:04 PM To: Ron Parker; Linda Dunbar= ; >>>> Joel M. Halpern; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>> >>>> For all of those reasons, I >>>> strongly support a=20 >>>> canonical service >>>> header that is independent o= f >>>> the transport methodology. >>>> >>>> >>>> >>>> I agree. However the format of servi= ce >>>> header should be >>>> standardized in >>>> >>>> a way that is flexible. Some of us would lik= e to >>>> see variable length >>>> header that is also HW friendly. The service >>>> header can be >>>> represented as a mandotory fixed length head= er >>>> (like IP >>>> header) along with an optional variable leng= th >>>> attribute field. >>>> Different services can be interested in >>>> different metadata, for >>>> example subscriber ID could be of interest i= n >>>> the mobile core >>>> service chain only. >>>> >>>> >>>> Sumandra >>>> >>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>> =20 >>>> >>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> Linda, >>>> >>>> My interpretation of the >>>> architecture docs is that the=20 >>>> service >>>> function chain is built in an >>>> abstract manner (i.e., SF-A then >>>> SF-B >>>> >>>> then SF-C). >>>> >>>> Separately, a locator table prov= ides >>>> network location for >>>> each of those service functions. >>>> In this way, you can >>>> locate the service functions >>>> >>>> in >>>> >>>> a manner appropriate to the type= of >>>> transport you are >>>> using. If you want that to be >>>> interface+VLAN, >>>> gateway-IP+MPLS label stack,=20 >>>> IP >>>> >>>> address, >>>> >>>> GRE tunnel remote IP + key, etc.= , >>>> you can do that. You >>>> can even potentially locate >>>> different service functions that >>>> reside in the same chain with >>>> different flavors of >>>> network locators. Another >>>> justification to separate the >>>> identity of a service function f= rom >>>> its network location is >>>> load balancing. If, for exampl= e, >>>> SF-A had 3 IP addresses, >>>> that would imply load balancing = to 3 >>>> instances using IP as a >>>> transport layer. >>>> >>>> For all of those reasons, I stro= ngly >>>> support a canonical service >>>> header that is independent of th= e >>>> transport >>>> methodology. At a particular >>>> node, the decision as to >>>> where to go next should be based >>>> solely on information carried in >>>> the canonical service header and= not >>>> on the >>>> >>>> fields >>>> >>>> in the transport header. That = is, >>>> the SFC node discards >>>> the transport header and extract= s >>>> the chain ID from the >>>> service header. Through >>>> mechanisms we have not yet begun >>>> to discuss, the SFC node knows h= ow >>>> to interpret the chain ID and >>>> ultimately how to progress=20 >>>> the packet. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From:= sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] O= n >>>> Behalf Of Linda Dunbar >>>> Sent: Wednesday, February 12, 20= 14 >>>> 12:01 PM To: Joel M. >>>> Halpern; sfc@ietf.org >>>> Subject: R= e: >>>> [sfc] Framework >>>> >>>> Agree with Joel's statement. >>>> >>>> I think a simple sentence below >>>> should be added Section 5.2 (SFC >>>> Classifier) to emphasize this po= int. >>>> >>>> "A Service Chain Classifier node= can >>>> associate a unique Layer 2 >>>> or 3 Label (e.g. VLAN, MPLS labe= l) >>>> to the packets in the flow. >>>> Those Layer 2 or 3 Label makes i= t >>>> easier for subsequent nodes >>>> along the flow path to steer the >>>> flow to the service functions >>>> specified by the flow's=20 >>>> service chain." >>>> >>>> >>>> Linda -----Original Message----- >>>> From: sfc >>>> [mailto:sfc-bounces@ietf.org >>>> ] O= n >>>> Behalf Of Joel M. Halpern >>>> Sent: Wednesday, February 12, 20= 14 >>>> 10:20 AM To: >>>> sfc@ietf.org >>>> Subject: [sfc] Framework >>>> >>>> I was looking at the framework >>>> proposal. The proposal has a ver= y >>>> specific model of the scope of t= he >>>> transport header (that it is >>>> derived from, and relates only t= o, >>>> the first service function to >>>> which the packet will be directe= d. >>>> That is clearly an operational >>>> model we need to support. >>>> >>>> However, I would like to allow o= ther >>>> transport operational >>>> models, such as the use of a VLA= N to >>>> direct traffic along a >>>> chain. Or the use of an MPLS la= bel, >>>> or an MPLS label stack. >>>> >>>> Yours, Joel M. Halpern >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org=20 >>>> >>>> >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> =20 >>>> https://www.ietf.org/mailman/__listinfo/sfc >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ 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 >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> 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 > > > > _______________________________________________ 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 Feb 13 16:25:10 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7984C1A0007 for ; Thu, 13 Feb 2014 16:25:08 -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 yZhF2IWTmyxv for ; Thu, 13 Feb 2014 16:25:03 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2D10E1A0006 for ; Thu, 13 Feb 2014 16:25:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2794B461F46; Thu, 13 Feb 2014 16:25:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-222.clppva.east.verizon.net [70.106.135.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E8846461F3E; Thu, 13 Feb 2014 16:24:55 -0800 (PST) Message-ID: <52FD6262.1040605@joelhalpern.com> Date: Thu, 13 Feb 2014 19:25:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Linda Dunbar , "sfc@ietf.org" References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bVCIs0aN6hp1u8u0LQj4FZbUxwg Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:25:08 -0000 I only consider the first of those to be metadata. The chain identification in the service chaining header or the transport header are not metadata. Treating fields which are needed for steering as metadata induces massive confusion. can we please keep those two concepts separate?! Yours, Joel On 2/13/14, 7:18 PM, Linda Dunbar wrote: > > I see two types of "metadata" being discussed here: > > 1. The "flow metadata", like the transactions carried by http flows. They are inserted by applications, or inserted by a service function to pass some "cookies" to the next one. (many proxy based service functions have those capability) > > 2. The "Service Chain metadata", that are inserted by "Chain Classifier" or control plane to carry extra information (in additional to Chain ID) for the purpose of controlling the sequence of functions on a chain. > > Correct? > > IMHO, the first bullet above are specific to applications or service functions internal processing. Many of today's proxy based service functions make changes to data packets, some of them make those changes for other service functions. Those changes won't be in the Service Chain Header field. > > Linda > > > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 2:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not address the majority of requirement. Also a typical http flow carries many transactions and each can have different or additional classification. So a metadata can not be simple connected with one flow either. Current implementations of proxies and load balancers has addressed this in many ways including custome header insertion. The custom header in this case equivalent of metadata vector. > > I think we need an efficient way annotate actual data with inline metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short identifier, and using it to select the desired behavior that has been pre-populated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for out-of-band metadata. > > However, claiming that a single such correlator is all that is needed for even 80% of SFC cases (and I very much supporting trying to focus on the 80% cases), just does not seem to work, given the broad range of requirements that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: >> Joel, >> >> Protocols like GTP and L2TP work exactly that, with a form of session correlator between the data plane and the control plane. This is very handy for subscriber and service management. Also if a correlator is defined as an opaque and unique number, then one can avoid some of the pitfalls you described. Long-lived metadata is clearly useful (and thanks for sharing, Reinaldo, will read), and there is clear applicability to various service chaining needs. >> >> Now this is just one way. The I-D Bruno referred to was just listing this approach as one possible way among others. I totally agree with you that other forms of metadata (like an outcome of the classification of a packet or a sequence of a few packets) may not be suitable for out-of-band signaling. >> >> Bottomline seems to be that we have too many options to choose from, and none of them solving it all... Tough. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 13, 2014 2:29 PM >> To: sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> As I understand it, the tsvwg (and aeon) work is about flow metadata. >> That is long-lived metadata of use across many packets. That does indeed seem well-suited to out-of-band cases. >> >> My concern is that in SFC, there are many cases which are at best badly-addressed if we insist that they be solved using out-of-band metadata. >> >> Yours, >> Joel >> >> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>> There is draft about transport independent metadata. >>> >>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding >>> - >>> 01 >>> >>> The complexities you mention are discussed there: variable-encoding, >>> direction, security of metadata, etc. >>> >>> Thanks, >>> >>> -RP >>> >>> >>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>> >>>> While there are cases where out-of-band metadata makes sense, There >>>> are many cases I would not want to try to cover that way. The best >>>> examples are situations where the metadata changes from packet to >>>> packet (such as the data produced by a DPI engine for consumption by >>>> other applications in the chain.) >>>> >>>> More importantly, if you are putting correlators in the packet, it >>>> is still very complex if you want to use one correlator to handle >>>> metadata produced by several different entities (the initial >>>> classifer, the DPI engine, ...) You quickly end up deciding that >>>> you need several correlators. At which point we are back to variable amounts of metadata. >>>> >>>> The alternative is to require exceedingly specific and strong >>>> coupling to a mandated out-of-band mechanism. That seems to me to >>>> be a very bad idea. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>> resend to avoid "too many recipients" warning >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >>>>> > wrote: >>>>> >>>>> There are ways to signal variable length amounts of metadata without >>>>> needing an additional variable-length header on each data packet. >>>>> >>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of the >>>>> possible approaches: out-of-band signaling (congruent or >>>>> non-congruent) or a hybrid approach using a fix-length in-band >>>>> correlator and out-of-band additional metadata. See sections 3.3, >>>>> 3.4 and 3.5 in the draft. >>>>> >>>>> The issue of fixed-length encoding versus variable length encoding >>>>> is discussion in the challenges chapter in section 4.3. I should >>>>> probably mention the MTU and segmentation issues as well in that >>>>> section. >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> The variable length shim header is needed even if every >>>>> individual piece of metadata has a fixed length. Different >>>>> service chains will need different combinations of metadata. So >>>>> the metadata portion of the header needs to be variable length. >>>>> >>>>> I think the approach of a fixed length initial part, and a >>>>> variable length extension part, is the right model. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>> >>>>> Yes, fragmentation and variable headers are usually a really >>>>> bad thing for forwarding performance. Let's not forget that >>>>> we live in a 100G-ish kind of world nowadays. >>>>> >>>>> Now the question should be: WHY would we want to do that >>>>> (variable headers leading to fragmentation issues)? >>>>> >>>>> For example, the type of metadata that may require >>>>> variable-length fields might be a better candidate for some >>>>> out-of-band signaling mechanism. If this is service >>>>> authorization data (e.g. a service profile/policy), this >>>>> sounds likely. Not 100% sure this is true for all use cases >>>>> though. Only a good understanding of use cases, grounded by >>>>> reflecting on existing network architectures (notably >>>>> broadband, fixed or mobile), would tell us if one approach >>>>> or another is the most appropriate. >>>>> >>>>> Anyhoo, we're jumping way deep in the detailed protocol >>>>> design here. This seems a tad premature. >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>> ] On Behalf Of Dave Dolson >>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>> To: 'jmh@joelhalpern.com '; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'mohamed.boucadair@orange.com >>>>> '__; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; 'paulq@cisco.com >>>>> ' >>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com ' >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> it is overall more efficient to support PMTU discovery >>>>> rather than fragmenting every large packet. The is why TCP >>>>> adopted it so early on. >>>>> >>>>> The fragmenting also puts huge performance burden on the >>>>> service functions. >>>>> Fragmenting may also affect the ability of load balancers to >>>>> get each fragment to the correct destination. >>>>> >>>>> So PMTU discovery SHOULD be used, in my opinion. By this I >>>>> mean the client or server is informed that its packets are >>>>> too big (for IPv6 or IPv4 with DF=1). >>>>> >>>>> Some operators may wish to incur the extra cost to hide the >>>>> existence of the tunneling, when the elements of the chain >>>>> can support it, so we could consider that as an optional >>>>> mechanism. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>> ] >>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>> To: Ron Parker >>>> >; >>>>> mohamed.boucadair@orange.com >>>>> >>>>> >>>> >__; Dave Dolson; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> ' >>>>> >>>> >; 'paulq@cisco.com >>>>> ' >>>> > >>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>> ' >; >>>>> 'linda.dunbar@huawei.com ' >>>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I mostly agree with you Ron. I can probably come up with >>>>> some other variations, but your second point is that the >>>>> transport must deal with the issue of frame size / fit. >>>>> >>>>> I would note that if we assume that the carrying encaps >>>>> (IPv4/v6 outer) is being fragmented, then we are assuming >>>>> that the exit from service chaining can and will reassemble. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>> >>>>> Joel, >>>>> >>>>> That is an excellent point to consider when choosing >>>>> transport >>>>> encapsulations. If the transport encapsulation is IPv4 >>>>> or IPv6 >>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, >>>>> etc.), then >>>>> fragmentation and defragmentation are naturally >>>>> supported. If the >>>>> transport encapsulation is VLAN, MPLS, etc., then I >>>>> believe one of the >>>>> following must be true: >>>>> >>>>> * The end-to-end path is known to support the resulting >>>>> larger frames >>>>> * A path discovery mechanism is mandated by SFC when >>>>> non-IP transports >>>>> are used * An SFC-specific fragmentation header and >>>>> mechanisms must be >>>>> defined (i.e., >>>>> >>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or- >>>>> f >>>>> rame) >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Joel M. Halpern >>>>> [mailto:jmh@joelhalpern.com >>>>> ] Sent: Thursday, February >>>>> 13, 2014 10:10 >>>>> AM To: mohamed.boucadair@orange.com >>>>> ; Dave Dolson; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; Ron Parker; >>>>> 'paulq@cisco.com ' Cc: >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> There is a related complexity. I hope that we expect to >>>>> support IPv6. >>>>> IPv6 explicitly prohibits network elements from >>>>> fragmenting end user >>>>> packets. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>> wrote: >>>>> >>>>> Re-, >>>>> >>>>> FWIW, one of the existing architecture drafts >>>>> includes the following >>>>> behavior >>>>> >>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#se >>>>> c >>>>> tion- >>>>> 6 >>>>> >>>>> ): >>>>> >>>>> >>>>> >>>>> " >>>>> >>>>> 6. Fragmentation Considerations >>>>> >>>>> If adding the Service Chaining Header would result >>>>> in a fragmented >>>>> packet, the classifier should include a Service >>>>> Chaining Header in >>>>> each fragment. Doing so would prevent SF Nodes to >>>>> dedicate resource >>>>> to handle fragments. " >>>>> >>>>> Cheers, Med >>>>> >>>>> >>>>> -----Message d'origine----- De : sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> De la part de Dave Dolson Envoyé : >>>>> jeudi 13 février 2014 13:39 À : >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'jmh@joelhalpern.com >>>>> '; >>>>> 'paulq@cisco.com ' Cc : >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>> '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Objet : Re: >>>>> [sfc] Framework >>>>> >>>>> Good point to consider fragmentation. >>>>> >>>>> We should design the encapsulation such that the >>>>> forwarding >>>>> functions do not need to reassemble. Each >>>>> fragment should be >>>>> independently forwardable; some SFs may choose >>>>> to ignore these >>>>> packets. >>>>> >>>>> Any layer 2.5 protocol like VLAN or MPLS would >>>>> support this. >>>>> Otherwise, a reassembly layer could be added >>>>> after the forwarding >>>>> coordinates. Think of something like the IPv6 >>>>> reassembly option >>>>> after a GRE header, for instance. >>>>> >>>>> IP | GRE | reassem | frag data >>>>> >>>>> We could alternatively mandate the inner IP be >>>>> fragmented and that >>>>> path-MTU discovery be supported. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: >>>>> Nicolas BOUTHORS >>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>> ] Sent: >>>>> Thursday, February 13, >>>>> 2014 04:13 AM To: Ron Parker >>>>> >>>> >; >>>>> Dave Dolson; Joel M. Halpern >>>>> >>>> >; Paul Quinn >>>>> (paulq) >>>> > Cc: Sumandra Majee >>>>> ; >>>>> sfc@ietf.org >>>> >; Linda Dunbar >>>>> >>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> If we do not enforce a fix header size we have >>>>> other implication. >>>>> >>>>> There is the question of segmentation and >>>>> reassembly responsibility >>>>> as well. >>>>> >>>>> If adding length to the service header forces >>>>> segmentation, then >>>>> whose responsibility is it to reassemble the >>>>> payload before passing >>>>> it to the SF. >>>>> >>>>> Similar question for packet re-ordering. >>>>> >>>>> >>>>> __________________________________________ From: >>>>> Ron Parker >>>>> [Ron_Parker@affirmednetworks.__com >>>>> ] Sent: >>>>> Wednesday, February 12, >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; >>>>> Paul Quinn >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> Dave, >>>>> >>>>> Yes, that is a good point if we logically >>>>> separate the forwarding >>>>> function from the SFC-aware service function, as >>>>> we should. The >>>>> forwarding function is concerned with only the >>>>> inbound transport >>>>> header, the fixed portion of the service header >>>>> containing the >>>>> chain information, and the outbound transport >>>>> header. The >>>>> service function may look at the entirety of the >>>>> service header and >>>>> would look at the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dolson >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: Wednesday, >>>>> February 12, 2014 >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul >>>>> Quinn (paulq) Cc: >>>>> Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subject: RE: >>>>> [sfc] >>>>> Framework >>>>> >>>>> The forwarding plane might not even need to look >>>>> at the encapsulated >>>>> packet. >>>>> >>>>> For example, (if the SF Identifier is a VLAN >>>>> tag), an Ethernet >>>>> switch can forward packets of the form: Ether | >>>>> VLAN | BLOB. >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Joel M. Halpern Sent: >>>>> Wednesday, February 12, 2014 4:30 PM To: Ron >>>>> Parker; Dave Dolson; >>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>> sfc@ietf.org ; Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I agree as well. Yours, Joel >>>>> >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> >>>>> Hi, Dave. >>>>> >>>>> I Agree with your statement. And if the >>>>> total length of the >>>>> header is >>>>> >>>>> contained in the mandatory portion, the hardware >>>>> implementation can >>>>> easily locate the encapsulated packet. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dolson >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: >>>>> Wednesday, February 12, >>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn >>>>> (paulq) Cc: Joel M. >>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subject: >>>>> RE: [sfc] Framework >>>>> >>>>> I think a good approach would be: >>>>> >>>>> The information required for forwarding (the >>>>> SF Identifier) should >>>>> be in >>>>> >>>>> a mandatory fixed-size header. >>>>> >>>>> >>>>> Optional information (if any) is NOT to be >>>>> used for forwarding, but >>>>> is >>>>> >>>>> for consumption by one or more of the >>>>> applications in the chain. >>>>> >>>>> >>>>> Then the forwarding plane, and even the PDP, >>>>> can be agnostic about >>>>> the >>>>> >>>>> meta-data. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Ron Parker Sent: >>>>> Wednesday, February 12, 2014 4:05 PM To: >>>>> Paul Quinn (paulq) Cc: >>>>> Joel M. Halpern; Sumandra Majee; >>>>> sfc@ietf.org ; >>>>> Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Paul, >>>>> >>>>> That is why I am proposing a hybrid where >>>>> extensions or options can >>>>> be >>>>> >>>>> added but the total length is contained in the >>>>> fixed portion. I >>>>> can envision certain deployments (e.g., >>>>> Enterprise) where perhaps >>>>> extensions are not needed and the SFC >>>>> functionality is realized >>>>> in hardware. And, I can envision certain other >>>>> deployments >>>>> (e.g., 3gpp) where the extension headers add >>>>> sufficient value to >>>>> justify software based implementations. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Paul Quinn >>>>> (paulq) >>>>> [mailto:paulq@cisco.com >>>>> ] Sent: Wednesday, >>>>> February 12, 2014 >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; >>>>> Linda Dunbar; Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Hi, >>>>> >>>>> We certainly need to be very careful with >>>>> variable length headers >>>>> when >>>>> >>>>> hardware platform are in play. >>>>> >>>>> >>>>> Ron, your examples of IP options and v6 EH >>>>> have both suffered from >>>>> >>>>> significant implementation and deployment >>>>> hurdles due to the >>>>> complexity and cost associated with hardware >>>>> support for the >>>>> option/EH. >>>>> >>>>> >>>>> Paul >>>>> >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibility, I >>>>> completely agree. I >>>>> might >>>>> >>>>> suggest a compromise between hardware >>>>> friendliness and software >>>>> flexibility. If the header had the ability to >>>>> add extensions >>>>> (perhaps similar to IPv6) but also had the >>>>> header length encoded in >>>>> the mandatory part (like IPv4), then a hardware >>>>> implementation would >>>>> be free to skip over the extensions (in cases >>>>> where the deployment >>>>> justifies ignoring the extensions). >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: >>>>> Sumandra Majee >>>>> [mailto:S.Majee@F5.com >>>>> ] Sent: >>>>> Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunbar; >>>>> Joel M. Halpern; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> For all of those reasons, I >>>>> strongly support a >>>>> canonical service >>>>> header that is independent of >>>>> the transport methodology. >>>>> >>>>> >>>>> >>>>> I agree. However the format of service >>>>> header should be >>>>> standardized in >>>>> >>>>> a way that is flexible. Some of us would like to >>>>> see variable length >>>>> header that is also HW friendly. The service >>>>> header can be >>>>> represented as a mandotory fixed length header >>>>> (like IP >>>>> header) along with an optional variable length >>>>> attribute field. >>>>> Different services can be interested in >>>>> different metadata, for >>>>> example subscriber ID could be of interest in >>>>> the mobile core >>>>> service chain only. >>>>> >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Linda, >>>>> >>>>> My interpretation of the >>>>> architecture docs is that the >>>>> service >>>>> function chain is built in an >>>>> abstract manner (i.e., SF-A then >>>>> SF-B >>>>> >>>>> then SF-C). >>>>> >>>>> Separately, a locator table provides >>>>> network location for >>>>> each of those service functions. >>>>> In this way, you can >>>>> locate the service functions >>>>> >>>>> in >>>>> >>>>> a manner appropriate to the type of >>>>> transport you are >>>>> using. If you want that to be >>>>> interface+VLAN, >>>>> gateway-IP+MPLS label stack, >>>>> IP >>>>> >>>>> address, >>>>> >>>>> GRE tunnel remote IP + key, etc., >>>>> you can do that. You >>>>> can even potentially locate >>>>> different service functions that >>>>> reside in the same chain with >>>>> different flavors of >>>>> network locators. Another >>>>> justification to separate the >>>>> identity of a service function from >>>>> its network location is >>>>> load balancing. If, for example, >>>>> SF-A had 3 IP addresses, >>>>> that would imply load balancing to 3 >>>>> instances using IP as a >>>>> transport layer. >>>>> >>>>> For all of those reasons, I strongly >>>>> support a canonical service >>>>> header that is independent of the >>>>> transport >>>>> methodology. At a particular >>>>> node, the decision as to >>>>> where to go next should be based >>>>> solely on information carried in >>>>> the canonical service header and not >>>>> on the >>>>> >>>>> fields >>>>> >>>>> in the transport header. That is, >>>>> the SFC node discards >>>>> the transport header and extracts >>>>> the chain ID from the >>>>> service header. Through >>>>> mechanisms we have not yet begun >>>>> to discuss, the SFC node knows how >>>>> to interpret the chain ID and >>>>> ultimately how to progress >>>>> the packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] On >>>>> Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, 2014 >>>>> 12:01 PM To: Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject: Re: >>>>> [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence below >>>>> should be added Section 5.2 (SFC >>>>> Classifier) to emphasize this point. >>>>> >>>>> "A Service Chain Classifier node can >>>>> associate a unique Layer 2 >>>>> or 3 Label (e.g. VLAN, MPLS label) >>>>> to the packets in the flow. >>>>> Those Layer 2 or 3 Label makes it >>>>> easier for subsequent nodes >>>>> along the flow path to steer the >>>>> flow to the service functions >>>>> specified by the flow's >>>>> service chain." >>>>> >>>>> >>>>> Linda -----Original Message----- >>>>> From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] On >>>>> Behalf Of Joel M. Halpern >>>>> Sent: Wednesday, February 12, 2014 >>>>> 10:20 AM To: >>>>> sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework >>>>> proposal. The proposal has a very >>>>> specific model of the scope of the >>>>> transport header (that it is >>>>> derived from, and relates only to, >>>>> the first service function to >>>>> which the packet will be directed. >>>>> That is clearly an operational >>>>> model we need to support. >>>>> >>>>> However, I would like to allow other >>>>> transport operational >>>>> models, such as the use of a VLAN to >>>>> direct traffic along a >>>>> chain. Or the use of an MPLS label, >>>>> or an MPLS label stack. >>>>> >>>>> Yours, Joel M. Halpern >>>>> >>>>> >>>>> _________________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> 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 >> >> >> >> > > _______________________________________________ > 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 Feb 13 16:33:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391B71A0007 for ; Thu, 13 Feb 2014 16:33:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gur2RSng0WVB for ; Thu, 13 Feb 2014 16:33:07 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id C06DC1A0006 for ; Thu, 13 Feb 2014 16:33:07 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 16:33:06 -0800 From: Ron Parker To: "Joel M. Halpern" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAcmAgAABywCAAAR+gIAAEKYAgAA6AACAAAHDAIAAhU8g Date: Fri, 14 Feb 2014 00:33:05 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> In-Reply-To: <52FD6262.1040605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dHNkT9BN0y_gabyAKhVORGHnbbA Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:33:13 -0000 Linda, Also, let's please separate "applications" and "service functions". I vie= w "applications" as things that are explicitly addressed, like an Apache Se= rver that realizes some web service -- no SFC steering was necessary to cau= se packets to reach it. "Service functions", on the other hand and purel= y from an SFC perspective, are transparent mid-boxes that would not have no= rmally been part of the data path unless special steering mechanisms were a= pplied or certain forced topologies were present in the network. Metadat= a, for SFC, is information above and beyond that required for proper steeri= ng that is passed amongst and between the SFC classifier(s) and the SFC ser= vice functions. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 7:25 PM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework I only consider the first of those to be metadata. The chain identificatio= n in the service chaining header or the transport header are not metadata. = Treating fields which are needed for steering as metadata induces massive = confusion. can we please keep those two concepts separate?! Yours, Joel On 2/13/14, 7:18 PM, Linda Dunbar wrote: > > I see two types of "metadata" being discussed here: > > 1. The "flow metadata", like the transactions carried by http flows.=20 > They are inserted by applications, or inserted by a service function=20 > to pass some "cookies" to the next one. (many proxy based service=20 > functions have those capability) > > 2. The "Service Chain metadata", that are inserted by "Chain Classifier= " or control plane to carry extra information (in additional to Chain ID) f= or the purpose of controlling the sequence of functions on a chain. > > Correct? > > IMHO, the first bullet above are specific to applications or service func= tions internal processing. Many of today's proxy based service functions ma= ke changes to data packets, some of them make those changes for other servi= ce functions. Those changes won't be in the Service Chain Header field. > > Linda > > > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 2:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not address= the majority of requirement. Also a typical http flow carries many transac= tions and each can have different or additional classification. So a metada= ta can not be simple connected with one flow either. Current implementation= s of proxies and load balancers has addressed this in many ways including c= ustome header insertion. The custom header in this case equivalent of metad= ata vector. > > I think we need an efficient way annotate actual data with inline=20 > metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 > [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short ide= ntifier, and using it to select the desired behavior that has been pre-popu= lated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for out-of-ban= d metadata. > > However, claiming that a single such correlator is all that is needed for= even 80% of SFC cases (and I very much supporting trying to focus on the 8= 0% cases), just does not seem to work, given the broad range of requirement= s that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: >> Joel, >> >> Protocols like GTP and L2TP work exactly that, with a form of session co= rrelator between the data plane and the control plane. This is very handy f= or subscriber and service management. Also if a correlator is defined as an= opaque and unique number, then one can avoid some of the pitfalls you desc= ribed. Long-lived metadata is clearly useful (and thanks for sharing, Reina= ldo, will read), and there is clear applicability to various service chaini= ng needs. >> >> Now this is just one way. The I-D Bruno referred to was just listing thi= s approach as one possible way among others. I totally agree with you that = other forms of metadata (like an outcome of the classification of a packet = or a sequence of a few packets) may not be suitable for out-of-band signali= ng. >> >> Bottomline seems to be that we have too many options to choose from, and= none of them solving it all... Tough. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 13, 2014 2:29 PM >> To: sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> As I understand it, the tsvwg (and aeon) work is about flow metadata. >> That is long-lived metadata of use across many packets. That does indee= d seem well-suited to out-of-band cases. >> >> My concern is that in SFC, there are many cases which are at best badly-= addressed if we insist that they be solved using out-of-band metadata. >> >> Yours, >> Joel >> >> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>> There is draft about transport independent metadata. >>> >>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodin >>> g >>> - >>> 01 >>> >>> The complexities you mention are discussed there: variable-encoding,=20 >>> direction, security of metadata, etc. >>> >>> Thanks, >>> >>> -RP >>> >>> >>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>> >>>> While there are cases where out-of-band metadata makes sense, There=20 >>>> are many cases I would not want to try to cover that way. The best=20 >>>> examples are situations where the metadata changes from packet to=20 >>>> packet (such as the data produced by a DPI engine for consumption=20 >>>> by other applications in the chain.) >>>> >>>> More importantly, if you are putting correlators in the packet, it=20 >>>> is still very complex if you want to use one correlator to handle=20 >>>> metadata produced by several different entities (the initial=20 >>>> classifer, the DPI engine, ...) You quickly end up deciding that=20 >>>> you need several correlators. At which point we are back to variable = amounts of metadata. >>>> >>>> The alternative is to require exceedingly specific and strong=20 >>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>> be a very bad idea. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>> resend to avoid "too many recipients" warning >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>> > wrote: >>>>> >>>>> There are ways to signal variable length amounts of metadata w= ithout >>>>> needing an additional variable-length header on each data pack= et. >>>>> >>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of= the >>>>> possible approaches: out-of-band signaling (congruent or >>>>> non-congruent) or a hybrid approach using a fix-length in-band >>>>> correlator and out-of-band additional metadata. See sections = 3.3, >>>>> 3.4 and 3.5 in the draft. >>>>> >>>>> The issue of fixed-length encoding versus variable length enco= ding >>>>> is discussion in the challenges chapter in section 4.3. I sho= uld >>>>> probably mention the MTU and segmentation issues as well in th= at >>>>> section. >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> The variable length shim header is needed even if every >>>>> individual piece of metadata has a fixed length. Differen= t >>>>> service chains will need different combinations of metadat= a. So >>>>> the metadata portion of the header needs to be variable le= ngth. >>>>> >>>>> I think the approach of a fixed length initial part, and a >>>>> variable length extension part, is the right model. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>> >>>>> Yes, fragmentation and variable headers are usually a = really >>>>> bad thing for forwarding performance. Let's not forget= that >>>>> we live in a 100G-ish kind of world nowadays. >>>>> >>>>> Now the question should be: WHY would we want to do th= at >>>>> (variable headers leading to fragmentation issues)? >>>>> >>>>> For example, the type of metadata that may require >>>>> variable-length fields might be a better candidate for= some >>>>> out-of-band signaling mechanism. If this is service >>>>> authorization data (e.g. a service profile/policy), th= is >>>>> sounds likely. Not 100% sure this is true for all use = cases >>>>> though. Only a good understanding of use cases, ground= ed by >>>>> reflecting on existing network architectures (notably >>>>> broadband, fixed or mobile), would tell us if one appr= oach >>>>> or another is the most appropriate. >>>>> >>>>> Anyhoo, we're jumping way deep in the detailed protoco= l >>>>> design here. This seems a tad premature. >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>> ] On Behalf Of Dave Dolso= n >>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>> To: 'jmh@joelhalpern.com '= ; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'mohamed.boucadair@orange.com >>>>> '__; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; 'paulq@cisco.co= m >>>>> ' >>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com ' >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> it is overall more efficient to support PMTU discovery >>>>> rather than fragmenting every large packet. The is why= TCP >>>>> adopted it so early on. >>>>> >>>>> The fragmenting also puts huge performance burden on t= he >>>>> service functions. >>>>> Fragmenting may also affect the ability of load balanc= ers to >>>>> get each fragment to the correct destination. >>>>> >>>>> So PMTU discovery SHOULD be used, in my opinion. By th= is I >>>>> mean the client or server is informed that its packets= are >>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>> >>>>> Some operators may wish to incur the extra cost to hid= e the >>>>> existence of the tunneling, when the elements of the c= hain >>>>> can support it, so we could consider that as an option= al >>>>> mechanism. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>> ] >>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>> To: Ron Parker >>>> >; >>>>> mohamed.boucadair@orange.com >>>>> >>>>> >>>> >__; Dave Dolson; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> ' >>>>> >>>> >; 'paulq@cisco.co= m >>>>> ' >>>> > >>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>> ' >; >>>>> 'linda.dunbar@huawei.com ' >>>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I mostly agree with you Ron. I can probably come up w= ith >>>>> some other variations, but your second point is that t= he >>>>> transport must deal with the issue of frame size / fit= . >>>>> >>>>> I would note that if we assume that the carrying encap= s >>>>> (IPv4/v6 outer) is being fragmented, then we are assum= ing >>>>> that the exit from service chaining can and will reass= emble. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>> >>>>> Joel, >>>>> >>>>> That is an excellent point to consider when choosi= ng >>>>> transport >>>>> encapsulations. If the transport encapsulation i= s IPv4 >>>>> or IPv6 >>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>>>> etc.), then >>>>> fragmentation and defragmentation are naturally >>>>> supported. If the >>>>> transport encapsulation is VLAN, MPLS, etc., then = I >>>>> believe one of the >>>>> following must be true: >>>>> >>>>> * The end-to-end path is known to support the resu= lting >>>>> larger frames >>>>> * A path discovery mechanism is mandated by SFC wh= en >>>>> non-IP transports >>>>> are used * An SFC-specific fragmentation header an= d >>>>> mechanisms must be >>>>> defined (i.e., >>>>> >>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or >>>>> - >>>>> f >>>>> rame) >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Joel M. Halpern >>>>> [mailto:jmh@joelhalpern.com >>>>> ] Sent: Thursday, Febr= uary >>>>> 13, 2014 10:10 >>>>> AM To: mohamed.boucadair@orange.com >>>>> ; Dave Dolson= ; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; Ron Parker; >>>>> 'paulq@cisco.com ' Cc: >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> There is a related complexity. I hope that we expe= ct to >>>>> support IPv6. >>>>> IPv6 explicitly prohibits network elements from >>>>> fragmenting end user >>>>> packets. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>> wrote: >>>>> >>>>> Re-, >>>>> >>>>> FWIW, one of the existing architecture drafts >>>>> includes the following >>>>> behavior >>>>> >>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#s >>>>> e >>>>> c >>>>> tion- >>>>> 6 >>>>> >>>>> ): >>>>> >>>>> >>>>> >>>>> " >>>>> >>>>> 6. Fragmentation Considerations >>>>> >>>>> If adding the Service Chaining Header would re= sult >>>>> in a fragmented >>>>> packet, the classifier should include a Servic= e >>>>> Chaining Header in >>>>> each fragment. Doing so would prevent SF Node= s to >>>>> dedicate resource >>>>> to handle fragments. " >>>>> >>>>> Cheers, Med >>>>> >>>>> >>>>> -----Message d'origine----- De : sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> De la part de Dave Dolson Envoy=E9 : >>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'jmh@joelhalpern.com=20 >>>>> '; >>>>> 'paulq@cisco.com '= Cc : >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>> '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Objet : = Re: >>>>> [sfc] Framework >>>>> >>>>> Good point to consider fragmentation. >>>>> >>>>> We should design the encapsulation such th= at the >>>>> forwarding >>>>> functions do not need to reassemble. Each >>>>> fragment should be >>>>> independently forwardable; some SFs may ch= oose >>>>> to ignore these >>>>> packets. >>>>> >>>>> Any layer 2.5 protocol like VLAN or MPLS w= ould >>>>> support this. >>>>> Otherwise, a reassembly layer could be add= ed >>>>> after the forwarding >>>>> coordinates. Think of something like the I= Pv6 >>>>> reassembly option >>>>> after a GRE header, for instance. >>>>> >>>>> IP | GRE | reassem | frag data >>>>> >>>>> We could alternatively mandate the inner I= P be >>>>> fragmented and that >>>>> path-MTU discovery be supported. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: >>>>> Nicolas BOUTHORS >>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>> ] Sent= : >>>>> Thursday, February 13, >>>>> 2014 04:13 AM To: Ron Parker >>>>> >>>> >; >>>>> Dave Dolson; Joel M. Halpern >>>>> >>>> >; Paul Quinn >>>>> (paulq) >>>> > Cc: Sumandra Maj= ee >>>>> ; >>>>> sfc@ietf.org >>>> >; Linda Dunbar >>>>> >>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> If we do not enforce a fix header size we = have >>>>> other implication. >>>>> >>>>> There is the question of segmentation and >>>>> reassembly responsibility >>>>> as well. >>>>> >>>>> If adding length to the service header for= ces >>>>> segmentation, then >>>>> whose responsibility is it to reassemble t= he >>>>> payload before passing >>>>> it to the SF. >>>>> >>>>> Similar question for packet re-ordering. >>>>> >>>>> >>>>> __________________________________________= From: >>>>> Ron Parker >>>>> [Ron_Parker@affirmednetworks.__com >>>>> ] = Sent: >>>>> Wednesday, February 12, >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Hal= pern; >>>>> Paul Quinn >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: >>>>> Re: [sfc] Framework >>>>> >>>>> Dave, >>>>> >>>>> Yes, that is a good point if we logically >>>>> separate the forwarding >>>>> function from the SFC-aware service functi= on, as >>>>> we should. The >>>>> forwarding function is concerned with only= the >>>>> inbound transport >>>>> header, the fixed portion of the service = header >>>>> containing the >>>>> chain information, and the outbound transp= ort >>>>> header. The >>>>> service function may look at the entirety = of the >>>>> service header and >>>>> would look at the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dols= on >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: Wedne= sday, >>>>> February 12, 2014 >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; P= aul >>>>> Quinn (paulq) Cc: >>>>> Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: RE: >>>>> [sfc] >>>>> Framework >>>>> >>>>> The forwarding plane might not even need t= o look >>>>> at the encapsulated >>>>> packet. >>>>> >>>>> For example, (if the SF Identifier is a VL= AN >>>>> tag), an Ethernet >>>>> switch can forward packets of the form: E= ther | >>>>> VLAN | BLOB. >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Joel M. Halpern Sent: >>>>> Wednesday, February 12, 2014 4:30 PM To: R= on >>>>> Parker; Dave Dolson; >>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>> sfc@ietf.org ; Linda = Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I agree as well. Yours, Joel >>>>> >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> >>>>> Hi, Dave. >>>>> >>>>> I Agree with your statement. And i= f the >>>>> total length of the >>>>> header is >>>>> >>>>> contained in the mandatory portion, the ha= rdware >>>>> implementation can >>>>> easily locate the encapsulated packet. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave = Dolson >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: >>>>> Wednesday, February 12, >>>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n >>>>> (paulq) Cc: Joel M. >>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Su= bject: >>>>> RE: [sfc] Framework >>>>> >>>>> I think a good approach would be: >>>>> >>>>> The information required for forwardin= g (the >>>>> SF Identifier) should >>>>> be in >>>>> >>>>> a mandatory fixed-size header. >>>>> >>>>> >>>>> Optional information (if any) is NOT t= o be >>>>> used for forwarding, but >>>>> is >>>>> >>>>> for consumption by one or more of the >>>>> applications in the chain. >>>>> >>>>> >>>>> Then the forwarding plane, and even th= e PDP, >>>>> can be agnostic about >>>>> the >>>>> >>>>> meta-data. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Ron Parker Sent: >>>>> Wednesday, February 12, 2014 4:05 PM T= o: >>>>> Paul Quinn (paulq) Cc: >>>>> Joel M. Halpern; Sumandra Majee; >>>>> sfc@ietf.org ;=20 >>>>> Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Paul, >>>>> >>>>> That is why I am proposing a hybrid wh= ere >>>>> extensions or options can >>>>> be >>>>> >>>>> added but the total length is contained in= the >>>>> fixed portion. I >>>>> can envision certain deployments (e.g., >>>>> Enterprise) where perhaps >>>>> extensions are not needed and the SFC >>>>> functionality is realized >>>>> in hardware. And, I can envision certain= other >>>>> deployments >>>>> (e.g., 3gpp) where the extension headers a= dd >>>>> sufficient value to >>>>> justify software based implementations. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Paul = Quinn >>>>> (paulq) >>>>> [mailto:paulq@cisco.com >>>>> ] Sent: Wednes= day, >>>>> February 12, 2014 >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Ma= jee; >>>>> Linda Dunbar; Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Hi, >>>>> >>>>> We certainly need to be very careful w= ith >>>>> variable length headers >>>>> when >>>>> >>>>> hardware platform are in play. >>>>> >>>>> >>>>> Ron, your examples of IP options and v= 6 EH >>>>> have both suffered from >>>>> >>>>> significant implementation and deployment >>>>> hurdles due to the >>>>> complexity and cost associated with hardwa= re >>>>> support for the >>>>> option/EH. >>>>> >>>>> >>>>> Paul >>>>> >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibili= ty, I >>>>> completely agree. I >>>>> might >>>>> >>>>> suggest a compromise between hardware >>>>> friendliness and software >>>>> flexibility. If the header had the abil= ity to >>>>> add extensions >>>>> (perhaps similar to IPv6) but also had the >>>>> header length encoded in >>>>> the mandatory part (like IPv4), then a har= dware >>>>> implementation would >>>>> be free to skip over the extensions (in ca= ses >>>>> where the deployment >>>>> justifies ignoring the extensions). >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: >>>>> Sumandra Majee >>>>> [mailto:S.Majee@F5.com >>>>> ] Sent: >>>>> Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunb= ar; >>>>> Joel M. Halpern; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> For all of those reasons, = I >>>>> strongly support a=20 >>>>> canonical service >>>>> header that is independent= of >>>>> the transport methodology. >>>>> >>>>> >>>>> >>>>> I agree. However the format of ser= vice >>>>> header should be >>>>> standardized in >>>>> >>>>> a way that is flexible. Some of us would l= ike to >>>>> see variable length >>>>> header that is also HW friendly. The servi= ce >>>>> header can be >>>>> represented as a mandotory fixed length he= ader >>>>> (like IP >>>>> header) along with an optional variable le= ngth >>>>> attribute field. >>>>> Different services can be interested in >>>>> different metadata, for >>>>> example subscriber ID could be of interest= in >>>>> the mobile core >>>>> service chain only. >>>>> >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Linda, >>>>> >>>>> My interpretation of the >>>>> architecture docs is that=20 >>>>> the service >>>>> function chain is built in an >>>>> abstract manner (i.e., SF-A th= en >>>>> SF-B >>>>> >>>>> then SF-C). >>>>> >>>>> Separately, a locator table pr= ovides >>>>> network location for >>>>> each of those service function= s. >>>>> In this way, you can >>>>> locate the service=20 >>>>> functions >>>>> >>>>> in >>>>> >>>>> a manner appropriate to the ty= pe of >>>>> transport you are >>>>> using. If you want that to b= e >>>>> interface+VLAN, >>>>> gateway-IP+MPLS label=20 >>>>> stack, IP >>>>> >>>>> address, >>>>> >>>>> GRE tunnel remote IP + key, et= c., >>>>> you can do that. You >>>>> can even potentially locate >>>>> different service functions th= at >>>>> reside in the same chain with >>>>> different flavors of >>>>> network locators. Another >>>>> justification to separate the >>>>> identity of a service function= from >>>>> its network location is >>>>> load balancing. If, for exam= ple, >>>>> SF-A had 3 IP addresses, >>>>> that would imply load balancin= g to 3 >>>>> instances using IP as a >>>>> transport layer. >>>>> >>>>> For all of those reasons, I st= rongly >>>>> support a canonical service >>>>> header that is independent of = the >>>>> transport >>>>> methodology. At a particula= r >>>>> node, the decision as to >>>>> where to go next should be bas= ed >>>>> solely on information carried = in >>>>> the canonical service header a= nd not >>>>> on the >>>>> >>>>> fields >>>>> >>>>> in the transport header. Tha= t is, >>>>> the SFC node discards >>>>> the transport header and extra= cts >>>>> the chain ID from the >>>>> service header. Through >>>>> mechanisms we have not yet beg= un >>>>> to discuss, the SFC node knows= how >>>>> to interpret the chain ID and >>>>> ultimately how to progress=20 >>>>> the packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- Fro= m: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 12:01 PM To: Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject:= Re: >>>>> [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence belo= w >>>>> should be added Section 5.2 (S= FC >>>>> Classifier) to emphasize this = point. >>>>> >>>>> "A Service Chain Classifier no= de can >>>>> associate a unique Layer 2 >>>>> or 3 Label (e.g. VLAN, MPLS la= bel) >>>>> to the packets in the flow. >>>>> Those Layer 2 or 3 Label makes= it >>>>> easier for subsequent nodes >>>>> along the flow path to steer t= he >>>>> flow to the service functions >>>>> specified by the flow's=20 >>>>> service chain." >>>>> >>>>> >>>>> Linda -----Original Message---= -- >>>>> From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Joel M. Halpern >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 10:20 AM To: >>>>> sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework >>>>> proposal. The proposal has a v= ery >>>>> specific model of the scope of= the >>>>> transport header (that it is >>>>> derived from, and relates only= to, >>>>> the first service function to >>>>> which the packet will be direc= ted. >>>>> That is clearly an operational >>>>> model we need to support. >>>>> >>>>> However, I would like to allow= other >>>>> transport operational >>>>> models, such as the use of a V= LAN to >>>>> direct traffic along a >>>>> chain. Or the use of an MPLS = label, >>>>> or an MPLS label stack. >>>>> >>>>> Yours, Joel M. Halpern >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> 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 >>>>> =20 >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ sfc >>>>> mailing list >>>>> sfc@ietf.org >>>>> =20 >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ sfc >>>>> mailing list >>>>> sfc@ietf.org >>>>> =20 >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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 Feb 13 16:41:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C67B1A0040 for ; Thu, 13 Feb 2014 16:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrWGY2XgmMHL for ; Thu, 13 Feb 2014 16:41:38 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 181791A0046 for ; Thu, 13 Feb 2014 16:41:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,841,1384261200"; d="scan'208";a="194894406" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 14 Feb 2014 11:41:34 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7348"; a="192352725" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 14 Feb 2014 11:40:33 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 14 Feb 2014 11:40:29 +1100 From: "Pham, Chuong D" To: Alla Goldner , Jerome Moisand , Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Date: Fri, 14 Feb 2014 11:40:28 +1100 Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: Ac8o2N3lmqIpG3d8S9qIOMfIquPQwQAQzGTA Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983D73325@WSMSG3154V.srv.dir.telstra.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TmNN2DoPpi0IaGPFhEBVS3winvU Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:41:42 -0000 Hi all, I am not sure but I feel this draft is discussing more on potential solutio= ns rather than use cases specific to Mobile? I think we should include more= use cases and less potential solutions. For example, many use cases in the= draft provide details on today's some specific implementations which may n= ot applicable to the majority of Operators. When the draft touches upon candidate for a classifier, I think we should n= ot exclude anything: PGw, DPI, TDF, LB, Switches etc. as potential classifi= er but leave this open for another specification draft. Note that the class= ifier may reside in a data centre, common to and away from multiple access = technologies run by the same Operator so it may as well be an independent f= unction. It may also be a function of a MVNO which does not own the physica= l 3GPP infrastructure i.e. PGw, TDF, PCRF. Regards, Chuong -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com] Sent: Friday, 14 February 2014 3:15 AM To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interface= is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optional in= exactly the same way. The whole 3GPP PCC architecture is optional. Therefo= re, the claim about 100% of mobile data subscribers may not be fully correc= t. And with regards to the features required for service classification and= service enforcement that you describe below - they are present at both GG= SN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier OF = COURSE should be considered, same as use cases where TDF is considered as a= classifier. And, once describing those use cases, the existing 3GPP archit= ecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Alla & folks, Well... I don't know... Getting deep in network architectures and the role = of the various network elements is indeed crucial. Both 3GPP and BBF (Broad= band Forum) did a lot of work in the past decade to define architecture & n= odal requirements, which shaped in turn the deployment of all major Service= Providers worldwide. So quite clearly, service chaining have to build on t= hat and find a good way to insert itself into such architectures while exte= nding them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for s= ervice classification/enforcement, as it... already does it for its own pur= pose! This is BY NATURE a highly scalable subscriber & service management s= ystem, classifying and enforcing policies (usually L3, occasionally higher)= , and fully integrated with the HSS/PCRF chain which holds the subscriber/s= ervice authentication & authorization data. As such, service classification= *and* service enforcement (and service accounting) is already there. For 1= 00% of the mobile (data) subscribers. Sure enough, a TDF system may also do= its own form of service classification (and processing too), but let's not= forget this is an OPTIONAL system on the data path on the recently defined= 3GPP architectures you referred to. For many use cases, there is just no p= oint going through a DPI function. While for other use cases, there is clea= rly such a point, but only when it brings clear value for a given service c= onstruct, only applicable to corresponding subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary su= bscriber management system on the data path, fully integrated with a AAA sy= stem, and already doing service classification *and* service processing at = scale for 100% of the subscribers. Any classification/enforcement system be= hind it is optional and only applicable to a subset of services & subscribe= rs. Bottomline: sure, use cases with TDF should be described, but PGW-centric u= se cases remain the rule, not the exception. And double-clicking on existin= g standardized network architectures (e.g. 3GPP and BBF) and related deploy= ments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE;= Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tool= s.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Deal Linda, The 3GPP architecture picture described below is not accurate. Starting from R11, PCRF interacts also with TDF (Traffic Detection Function= ) for providing ADC (Application Detection and Control) Rules for applicati= on detection, enforcement and also charging starting from R12. Please see a= rchitecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with th= e GGSN (via Diameter), not the service functions, do you mean "for the GGSN= (or the flow classifier) to carry the data passed down from PCRF to packet= s' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service treatm= ent, i.e. desired sequence of service functions, to specific flows based on= the policies from PCRF. The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions." is not correct as well as PGW/PC= EF is not the only element which enforces different support per different f= lows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architectur= e and make assumptions and conclusions about potential 3GPP elements functi= onality which are not in scope of IETF. If we want to define use cases for = 3GPP networks, then we should show correct picture of 3GPP architecture wi= thout redesigning it and leave 3GPP Network Elements functionality potentia= l extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; = Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sf= c@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Jeffrey and Walter, Here are some suggestions to your draft: Section 2.2: - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification? Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID? I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification. P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good. Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF. The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions. | Mobile backhaul Network +-----+ | +---+---+ |PCRF | | |Network| | | < ---- > |Ctrller| +-----+ | +----+--+ | | | | +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | | | | | +---------+ +----+ --->| | | +--------+ +-----+ -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | | +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN, >but I don't think it is necessary to have all of them in the SFC use >case draft. > >For example, on your Section 2.3 ("The Most common classification >scheme"), it is very confusing to have the Table 1 & Table 2 listing >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter, >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph >in -01. Possibly we will consider 2 sections: most simple case (with >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one >arrangement of mobility architecture, it neglects to show the role of >the Traffic Detection Function (TDF), also described in the cited 3GPP >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network >architecture. > >In all of the network diagrams and examples, it should be understood >that the P-GW is not the only location from which a policy-based >service chain could be initiated; the standard TDF function can also >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it >receives Application Detection and Control (ADC) rules, similar to the >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of >the draft, ADC rules can cause decisions based on application type (not >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >_______________________________________________ >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 ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message. Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message. Thank you. ###########################################################################= ################### From nobody Thu Feb 13 19:16:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0D1A003A; Thu, 13 Feb 2014 19:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwL9wsnw1V9s; Thu, 13 Feb 2014 19:16:00 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id F38531A00A9; Thu, 13 Feb 2014 19:15:59 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 4CBC2125BFB6; Fri, 14 Feb 2014 11:15:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s1E3Fk5l004050; Fri, 14 Feb 2014 11:15:46 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: jguichar@cisco.com, narten@us.ibm.com MIME-Version: 1.0 X-KeepSent: 12F46C07:7837BB0C-48257C7F:000EB19F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Fri, 14 Feb 2014 11:15:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-14 11:15:39, Serialize complete at 2014-02-14 11:15:39 Content-Type: multipart/alternative; boundary="=_alternative 0012197048257C7F_=" X-MAIL: mse02.zte.com.cn s1E3Fk5l004050 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Vb7x2n6p17SbGtjFKJPfKeRUY7s Cc: Bhumip.Khasnabish@ztetx.com, wang.cui1@zte.com.cn, sfc , "sfc@ietf.org" Subject: Re: [sfc] SFC WG Agenda: London X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 03:16:03 -0000 This is a multipart message in MIME format. --=_alternative 0012197048257C7F_= Content-Type: text/plain; charset="US-ASCII" Hello Jim & Thomas, Yesterday, We posted a draft about use cases of broadband network. I'd like a 10 minutes to show the use cases of broadband network in the context of CGN/FW/AAA etc. Requested details: 1) https://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/?include_text=1 2) Provide use cases under several scenarios , DS-Lite/NAT44/NAT64&DNS64/lw4o6/MAP/AAA... 3) Propose some considerations about a) "NAT Pool configuration" & "routing advertising" considerations for outbound & inbound routing path b) Deploying mode consideration in broadband network. Standalone or directly connecting c) NAT traversal d) Example of "service function chains" etc. 4) We also refer to studies and concepts of sfc architecture/service function path from other drafts such as draft-quinn-sfc-arch/draft-parker-sfc-chain-to-path. Thanks, Wei & Cui & Bhumip "sfc" 2014-02-02 01:23:38: > Greetings, > > It's time to start putting together an agenda for the SFC meeting in > London. We've requested one 2.5 hour slot . Because face-to-face > time is precious, we intend to focus on: > > - WG chartered items for which we have WG-adopted IDs, or IDs that > appear headed for WG adoption. > > - Specific topics where feedback is needed, and mailing list > discussions have not converged. > > We also do not intend to give agenda time to everyone who has a > draft - the WG sessions do not have time for that, nor is it > necessarily an effective use of time. We also do not intend to give > agenda time for drafts for which little or no mailing list interest > has been generated. > > For the upcoming session, we expect to focus on: > > 1) Problem satement (hopefully not much time needed -- are there any > actual open issues?). > > 2) Use cases. > > 3) Architecture. > > If you have a draft (or plan to submit one) and would like to > present (or more specifically, would like the working group to do > something with your draft), please: > > 1) Let us know now (even if the draft is not published yet), so we > can start planning; > > 2) Indicate which WG deliverable the draft relates to; and > > 3) Indicate what you want the WG to do with your draft. E.g., do you > want this to become "THE" WG document for a particular deliverable? > Or, is there content in the document you believe should be added to > another document? etc. Please do not just respond "I want it to > become a WG document". It would be better to explain in what > context, and how your draft relates to other drafts that have been submitted. > > Thanks! > > Thomas & Jim_______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --=_alternative 0012197048257C7F_= Content-Type: text/html; charset="US-ASCII"
Hello Jim & Thomas,

Yesterday, We posted a draft about use cases of broadband network.  I'd like a 10 minutes to show the
use cases of broadband network in the context of CGN/FW/AAA etc.

Requested details:

1) https://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/?include_text=1

2) Provide use cases under several scenarios , DS-Lite/NAT44/NAT64&DNS64/lw4o6/MAP/AAA...

3) Propose some considerations about
     a) "NAT Pool configuration"  & "routing advertising" considerations for outbound & inbound routing path
     b) Deploying mode consideration in broadband network.    Standalone or directly connecting
     c) NAT traversal
     d)  Example of "service function chains"
     etc.

4) We also refer to studies and concepts of sfc architecture/service function path from other drafts such as
draft-quinn-sfc-arch/draft-parker-sfc-chain-to-path.

Thanks,
Wei & Cui & Bhumip




"sfc" <sfc-bounces@ietf.org>  2014-02-02 01:23:38:

> Greetings,
>
> It's time to start putting together an agenda for the SFC meeting in
> London. We've requested one 2.5 hour slot . Because face-to-face
> time is precious, we intend to focus on:
>
> - WG chartered items for which we have WG-adopted IDs, or IDs that
> appear headed for WG adoption.
>
> - Specific topics where feedback is needed, and mailing list
> discussions have not converged.
>
> We also do not intend to give agenda time to everyone who has a
> draft - the WG sessions do not have time for that, nor is it
> necessarily an effective use of time. We also do not intend to give
> agenda time for drafts for which little or no mailing list interest
> has been generated.
>
> For the upcoming session, we expect to focus on:
>
> 1) Problem satement (hopefully not much time needed -- are there any
> actual open issues?).
>
> 2) Use cases.
>
> 3) Architecture.
>
> If you have a draft (or plan to submit one) and would like to
> present (or more specifically, would like the working group to do
> something with your draft), please:
>
> 1) Let us know now (even if the draft is not published yet), so we
> can start planning;
>
> 2) Indicate which WG deliverable the draft relates to; and
>
> 3) Indicate what you want the WG to do with your draft. E.g., do you
> want this to become "THE" WG document for a particular deliverable?
> Or, is there content in the document you believe should be added to
> another document? etc. Please do not just respond "I want it to
> become a WG document". It would be better to explain in what
> context, and how your draft relates to other drafts that have been submitted.
>
> Thanks!
>
> Thomas & Jim_______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
 --=_alternative 0012197048257C7F_=-- From nobody Thu Feb 13 19:23:50 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B10B1A00B1 for ; Thu, 13 Feb 2014 19:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEszT93WY77k for ; Thu, 13 Feb 2014 19:23:43 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 218A51A003B for ; Thu, 13 Feb 2014 19:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18015; q=dns/txt; s=iport; t=1392348222; x=1393557822; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=aSo3LSdiarYpU3WZn6QIOLzSYeb68gz/uAVvAuVYogY=; b=QTxHOfMerKZCS1P/hM469xmR9wOsepXcXfHo4ltmXY0dMedLLLyeQ0X3 gttX2lq1zyNr+bYmcypaGb7gXxq2LhWizOPfd0/jHX04ut8YQsJdf0MjU up62BUTtIjr5S5Si5bwe3qfiFUP/6Hh0eEG/44JYhRm3MxrckKz0kE/bG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAHOL/VKtJXHA/2dsb2JhbABPCoJCRDhXv1mBGRZ0giUBAgQtQR0BCBEBAgECKCgRFAMGCAIEARIbh1YDEQ3AAQ2IPBMEjF+BPgRHDQuEOASWQIFsjF6FRYMtgWhC X-IronPort-AV: E=Sophos; i="4.95,842,1384300800"; d="scan'208,217"; a="20361300" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 14 Feb 2014 03:23:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1E3Nfkc008288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 03:23:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.180]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 21:23:41 -0600 From: "Ken Gray (kegray)" To: Bruno Rijsman , "sfc@ietf.org" Thread-Topic: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations Thread-Index: AQHPKMjTaFyveOch/06TYHfC6yD8/5q0J4CA Date: Fri, 14 Feb 2014 03:23:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.110] Content-Type: multipart/alternative; boundary="_000_CF22EBE6521Dkegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TivIs9FWbhnaexgqxMmQmPsy-TE Subject: Re: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 03:23:47 -0000 --_000_CF22EBE6521Dkegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey, Bruno. My personal answers to your questions would be: Use cases - no, though the last use-case seemed to suggest actually using m= etadata to carry a policy (more a configuration function) than as a trigger= of that policy/action at the function ..which I don't think is a likely sc= enario (and, while interesting, would make the metadata problem huge, IMO). Methodologies =96 no, any others I can think of would be derivative of what= you describe. Challenges =96 I can't think of more and really only see a couple as needin= g redress in this forum IF we assume that imbedded metadata would be the pr= eferred way forward. Those would be (IMO): o Support for metadata-unaware service function o Preserving metadata through metadata-unaware service functions o Metadata encoding o Multiple sources of metadata o Extensibility =85and I think the first and second will devolve into the same issue (event= ually). If you have a moment for a more general commentary (to my point about the a= ssumption that imbedded metadata would be the preferred way forward) =85 In spite of your intent and unless someone comes up with a more compelling = case for doing so, I can't see why we would forestall the pursuit of the pr= oposed metadata encapsulation in the header. None of the described alternatives are clear winners over imbedding metadat= a in the header (and I would argue incongruent signaling is compatible and = optional even if we decide to imbed in the header). In fact many have clea= rly stated limitations that make them non-starters. I agree that IP options are a non-starter because of the well known perform= ance ramifications you hit in one, clear sentence in 3.1. Both IPv4 option= s and the use of other well-known header fields, including the use of tags = of any sort will also suffer a limitation (IMO) in expressiveness unless th= ey seriously overlap their intended functionality. Their IPv6 brethren (ex= tended headers) are not that functionally different than imbedding the meta= data in the SFC header and limited solely to the IPv6 solution. Not to go = too far down this path, but a solution per-address family or forwarding mec= hanism also doesn't appear to be the short road to standardization (an imme= diate n-way fork in the road). Rewriting all the applications (3.2) to imbed metadata spreads the burden o= ver a huge field (all application programmers) and I have to see that as a = potentially bigger obstacle to standardization and deployment. It seems to= substitute one-time standard solution at the network level with an x-many = number of application level standard solutions. Any congruent or non-congruent signaling protocol creates a potential state= monster and implies at least the same level of integration in the service = function as the imbedded approach with the additional burden of having to m= aintain a separate communication channel in the application/function. Thes= e solutions invite other problems: response loop problems (which can be shi= fted to a distributed database problem, admittedly) and subscriber manageme= nt problem (particularly if a subscriber comm channel fails in a non-obviou= s manner =85the avoidance of which =85heartbeats, liveliness detection at t= he comm level =85are an even FURTHER complication) that would then require = a bunch of behavior definitions and additional standardization. The architecture authors HAVE discussed a non-congruent approach using an o= ut of band server (e.g. IFMAP server) and that alternative is still a deplo= yment alternative if you desire. The existing header proposal provides a b= eneficial, standardized key for lookups (your chain ID). You can opt to no= t use the metadata fields (zero them out at your classifier) in deployment. While your description of the challenge to a proxy is appropriately gnarly.= I'd argue that a proxy can/should have the option to (at least) recal the= original metadata used at original classification (by invoking said metada= ta from the same source as the original classifier). While this does touch= on some of the problems with the incongruent approach, it wouldn't be (aga= in, IMO) as large an overall impact to scalability and performance as a tot= ally incongruent approach. The biggest challenge to all the methodologies may be in computed metadata,= certainly for the proxy in the imbedded metadata scheme. Unlike the incon= gruent/congruent methodologies, however, you can add the metadata without o= ut of band signaling so a server. So, in a future world where the sfs aren= 't using proxies (a potentially far horizon, admittedly) this may become an= even greater advantage and in the interim might be addressed as a deployme= nt problem (chain construction problem if you have to use proxies and your = chain contains elements that may need to use computed metadata of a predece= ssor) - I'd be interested in opinions as to whether this is as big a corner= case as I think it may be. Thanks for your time and thanks for throwing the metadata ball out onto the= field=85. From: Bruno Rijsman > Date: Thursday, February 13, 2014 6:14 AM To: "sfc@ietf.org" > Subject: [sfc] New draft posted: draft-rijsman-sfc-metadata-considerations Yesterday I posted a new draft "Metadata Considerations" (draft-rijsman-sfc= -metadata-considerations-00): https://datatracker.ietf.org/doc/draft-rijsman-sfc-metadata-considerations/ This draft discusses the topic of metadata in the context of Service Functi= on Chaining. It aims to: * identify use cases for metadata, * to define the problem space for metadata signaling, * identify candidate approaches, * describe the key challenges, * and guide the exploration and comparison of possible solutions. The goal of this draft is not to propose a specific protocol but rather to = identify the requirements and solution space before we deep-dive into any p= articular approach. With that in mind, my questions for the mailing list are: * Are there any additional use cases for metadata beyond the three iden= tified in chapter 2 of the draft? * Are there any additional signaling approaches beyond the five identif= ied in chapter 3 of the draft? * Are there any additional challenges with respect to metadata signalin= g beyond the 13 identified in chapter 4 of the draft? -- Bruno --_000_CF22EBE6521Dkegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8013AD225563AA4EA5927FC5A74CC09A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hey, Bruno. 

My personal answers to your questions would be:

Use cases - no, though the last use-case seemed to suggest actually using m= etadata to carry a policy (more a configuration function) than as a trigger= of that policy/action at the function ..which I don't think is a likely sc= enario (and, while interesting, would make the metadata problem huge, IMO).  

Methodologies =96 no, any others I can think of would be derivative of what= you describe.

Challenges =96 I can't think of more and really only see a couple as needin= g redress in this forum IF we assume that imbedded metadata would be the pr= eferred way forward.  Those would be (IMO):

   o  Support for metadata-unaware service function

   o  Preserving metadata through metadata-unaware serv= ice functions

   o  Metadata encoding

   o  Multiple sources of metadata

   o  Extensibility

=85and I think the first and second will devolve into the same issue (event= ually).

If you have a moment for a more general commentary (to my point about the a= ssumption that imbedded metadata would be the preferred way forward) =85

In spite of your intent and unless someone comes up with a more compelling = case for doing so, I can't see why we would forestall the pursuit of the pr= oposed metadata encapsulation in the header.

None of = the described alternatives are clear winners over imbedding metadata in the= header (and I would argue incongruent signaling is compatib= le and optional even if we decide to imbed in the header).  In fact many have clearly stated limitations that make them non-star= ters.  

I agree that IP options are a non-start= er because of the well known performance ramifications you hit in one, clea= r sentence in 3.1.  Both IPv4 options and the use of other well-known = header fields, including the use of tags of any sort will also suffer a limitation (IMO) in expressiveness unless t= hey seriously overlap their intended functionality.  Their IPv6 brethr= en (extended headers) are not that functionally different than imbedding th= e metadata in the SFC header and limited solely to the IPv6 solution.  Not to go too far down this path, but a= solution per-address family or forwarding mechanism also doesn't appear to= be the short road to standardization (an immediate n-way fork in the road)= .

Rewriting all the applications (3.2) to= imbed metadata spreads the burden over a huge field (all application progr= ammers) and I have to see that as a potentially bigger obstacle to standard= ization and deployment.  It seems to substitute one-time standard solution at the network level with an x-ma= ny number of application level standard solutions.

Any congruent or non-congruent signaling protocol creates a potential = state monster and implies at least the same level of integration in the ser= vice function as the imbedded approach with the additional burden of having= to maintain a separate communication channel in the application/function.  These solutions invite other pr= oblems: response loop problems (which can be shifted to a distributed datab= ase problem, admittedly) and subscriber management problem (particularly if= a subscriber comm channel fails in a non-obvious manner =85the avoidance of which =85heartbeats, liveliness det= ection at the comm level =85are an even FURTHER complication) that would th= en require a bunch of behavior definitions and additional standardization.<= /div>

The architecture authors HAVE discussed a non-congruent approach using= an out of band server (e.g. IFMAP server) and that alternative is still a = deployment alternative if you desire.  The existing header proposal pr= ovides a beneficial, standardized key for lookups (your chain ID).  You can opt to not use the metadata fie= lds (zero them out at your classifier) in deployment.

While your description of the challenge to a proxy is appropriately gn= arly.  I'd argue that a proxy can/should have the option to (at least)= recal the original metadata used at original classification (by invoking s= aid metadata from the same source as the original classifier).  While this does touch on some of the probl= ems with the incongruent approach, it wouldn't be (again, IMO) as large an = overall impact to scalability and performance as a totally incongruent appr= oach. 

The biggest challenge to all the methodologies may be in computed meta= data, certainly for the proxy in the imbedded metadata scheme.  Unlike= the incongruent/congruent methodologies, however, you can add the metadata= without out of band signaling so a server.  So, in a future world where the sfs aren't using proxies (a potentia= lly far horizon, admittedly) this may become an even greater advantage and = in the interim might be addressed as a deployment problem (chain constructi= on problem if you have to use proxies and your chain contains elements that may need to use computed metadata of= a predecessor) - I'd be interested in opinions as to whether this is as bi= g a corner case as I think it may be. 

Thanks for your time and thanks for throwing the metadata ball out ont= o the field=85.


From: Bruno Rijsman <brunorijsman@gmail.com>
Date: Thursday, February 13, 2014 6= :14 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] New draft posted: dr= aft-rijsman-sfc-metadata-considerations

Yesterday I posted a new draft "Metadata Considerations" (dr= aft-rijsman-sfc-metadata-considerations-00):  


This draft discusses the topic of metadata in the context of Service F= unction Chaining.  It aims to:
  • identify use cases for metadata, 
  • to define the problem sp= ace for metadata signaling, 
  • identify candidate approach= es, 
  • describe the key challenges, 
  • and guide= the exploration and comparison of possible solutions.
The goal of this draft is not to propose a specific protoc= ol but rather to identify the requirements and solution space before we dee= p-dive into any particular approach.

With that in mind, my questions for the mailing list are:
  • Are there any additional use cases for metadata beyond the three identi= fied in chapter 2 of the draft?

  • Are there any additional signaling approaches beyond the five iden= tified in chapter 3 of the draft?

  • Are there any additional challenges with respect to metadata signa= ling beyond the 13 identified in chapter 4 of the draft?
-- Bruno
 --_000_CF22EBE6521Dkegrayciscocom_-- From nobody Thu Feb 13 21:34:41 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FBC1A00B9 for ; Thu, 13 Feb 2014 21:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RruF0RtXSXJl for ; Thu, 13 Feb 2014 21:34:37 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id A67361A00E4 for ; Thu, 13 Feb 2014 21:34:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,843,1384261200"; d="scan'208";a="183302440" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 14 Feb 2014 16:34:34 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7348"; a="251301331" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 14 Feb 2014 16:34:33 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 14 Feb 2014 16:34:33 +1100 From: "Pham, Chuong D" To: "mohamed.boucadair@orange.com" , Alla Goldner , "Liushucheng (Will)" , "sfc@ietf.org" Date: Fri, 14 Feb 2014 16:34:32 +1100 Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8ozSirZF8xjnYbSj+erc/EuLq/gAAeGWdw Message-ID: <5602569641FB314FB4D9AD5659D41B9C2983D73A44@WSMSG3154V.srv.dir.telstra.com> References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KIRxRyXnJs7oZf2DYPbUaphWJwg Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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, 14 Feb 2014 05:34:40 -0000 I support Med's opinion that we should not exclude all existing methods of = classifying flows which include the TDF, DPI, LB, Openflow switch, Grid com= puter, PGw etc. Due to constraint obviously we cannot include all of these candidate method= s in the draft but there is no reason to explicitly remove any of them in t= he draft which have been chosen to be included as examples of typical curre= nt deployments. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Friday, 14 February 2014 1:51 AM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Re-, I hear your argument, but the point is we cannot ignore existing deployment= s that are not relying on such functional element. We should reflect both s= ituations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier=20 >2014 15:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for=20 >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present=20 >standardized Mobile Network (defined by a different SDO i.e. 3GPP and=20 >not within a scope of IETF) it is very important to reference the=20 >existing well-defined Network Elements. DPI functionality in mobile=20 >network is fulfilled by the TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel=20 >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >agoldner@allot.com www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f= =E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interface= . >The TDF text is just after a paragraph starting with "Gi Interface ...". W= e >can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks that >are not compliant with 3GPP specifications. Instead of updating existing >figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available at: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will); >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized element >>>residing on Gi/SGi which implements DPI (detection) functionality along >>>with enforcement and charging of the corresponding detected >>>applications. This is missing from your use case description. I think >>>such a comment was already provided in a different email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng (Will) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases- >>>01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the section >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism is >>> called Service Function Chaining (SFC). The set of involved Service >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>########################################################################= # ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or >>>distribute this message. >>>If you have mistakenly received this message, please notify the sender b= y >>a >>>reply e-mail and delete this message. >>>Thank you. >>>########################################################################= # ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>#########################################################################= # ># >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender by >a >>reply e-mail and delete this message. >>Thank you. >>#########################################################################= # ># >>################### >##########################################################################= # >################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by = a >reply e-mail and delete this message. >Thank you. >##########################################################################= # >################### From nobody Thu Feb 13 22:43:17 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4341A00DD for ; Thu, 13 Feb 2014 22:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 2Kt3jLntNOii for ; Thu, 13 Feb 2014 22:43:10 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id A7F641A00C5 for ; Thu, 13 Feb 2014 22:43:08 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Fri, 14 Feb 2014 08:43:05 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 08:42:34 +0200 From: Alla Goldner To: Linda Dunbar , Jerome Moisand , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPKRGluu1DAkyS5E+LnBTbNHnL4Jq0TNqg Date: Fri, 14 Feb 2014 06:42:34 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.142.232.97] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YwVqtymWpjGatqRO_3ShaLsd9cc Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:43:15 -0000 Dear Linda, all, I think this presentation is more correct, thank you. One thing though may need to be corrected: PCEF is an integral part of PG= W as defined by 3GPP standards. Therefore, we may, as an option, mention= =20"PCEF/TDF" without "PGW", and then put a note that PCEF resides in PGW= . Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, February 14, 2014 1:17 AM To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner, Wa= lter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-us= e-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Alla, Jerome,=20 Since 3GPP has defined many components and are still involving, can we us= e a simplified box to represent an entity associated with P-GW that class= ifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as: =20 | Mobile backhaul Network =20 =20 +-----+ | +---+---+ =20 =20 |PCRF/| | |Network| =20 =20 |rules| < ---- > |Ctrller| =20 =20 +-----+ | +----+--+=20 =20 | | =20 =20 V | =20 =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> =20 | | | | | | | | Proxy | --->| & or | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> =20 |TDF/PCEF | | |Optimizer| | |=20 =20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> =20 | | | | | | |=20 =20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network As for the description of metadata used by Gi-LAN service function, we do= n't have to specifically say which elements defined by 3GPP encoded them = in.=20 Linda -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 10:30 AM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-= case-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt I don't know if the whole PCC architecture is truly optional in 3GPP theo= ry (I've never seen it expressed that way, but I'll take your word for it= ), but one would be hard-pressed to find a 3G/LTE mobile broadband networ= k without it. So in practice my 100% statement remains true (I'll give yo= u 99.9% if you wish!).=20 So I have a bit of an issue putting PGW and TDF at the same level. This s= imply doesn't reflect any reality, nor the spirit of the 3GPP specs. And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory= =20(I took a very active role in several of those specs, e.g. TR-101). Wh= ile a DPI function is truly optional (and not that many subscribers in ab= solute % go through it in practice) and not standardized. Anyway, I agree with you that mobile use cases with or without TDF should= =20be considered. A case without PGW would seem much more dubious to me. = We may be saying more or the same thing, overall. -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, February 13, 2014 11:15 AM To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Wa= lter, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-us= e-case-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interfa= ce is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optiona= l in exactly the same way. The whole 3GPP PCC architecture is optional. T= herefore, the claim about 100% of mobile data subscribers may not be full= y correct. And with regards to the features required for service classifi= cation and service enforcement that you describe below - they are presen= t at both GGSN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier O= F COURSE should be considered, same as use cases where TDF is considered = as a classifier. And, once describing those use cases, the existing 3GPP = architecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +9= 72 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com w= ww.allot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-= case-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Alla & folks, Well... I don't know... Getting deep in network architectures and the rol= e of the various network elements is indeed crucial. Both 3GPP and BBF (B= roadband Forum) did a lot of work in the past decade to define architectu= re & nodal requirements, which shaped in turn the deployment of all major= =20Service Providers worldwide. So quite clearly, service chaining have t= o build on that and find a good way to insert itself into such architectu= res while extending them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for= =20service classification/enforcement, as it... already does it for its o= wn purpose! This is BY NATURE a highly scalable subscriber & service mana= gement system, classifying and enforcing policies (usually L3, occasional= ly higher), and fully integrated with the HSS/PCRF chain which holds the = subscriber/service authentication & authorization data. As such, service = classification *and* service enforcement (and service accounting) is alre= ady there. For 100% of the mobile (data) subscribers. Sure enough, a TDF = system may also do its own form of service classification (and processing= =20too), but let's not forget this is an OPTIONAL system on the data path= =20on the recently defined 3GPP architectures you referred to. For many u= se cases, there is just no point going through a DPI function. While for = other use cases, there is clearly such a point, but only when it brings c= lear value for a given service construct, only applicable to correspondin= g subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary = subscriber management system on the data path, fully integrated with a AA= A system, and already doing service classification *and* service processi= ng at scale for 100% of the subscribers. Any classification/enforcement s= ystem behind it is optional and only applicable to a subset of services &= =20subscribers. Bottomline: sure, use cases with TDF should be described, but PGW-centric= =20use cases remain the rule, not the exception. And double-clicking on e= xisting standardized network architectures (e.g. 3GPP and BBF) and relate= d deployments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone D= E; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@= tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Functi= on) for providing ADC (Application Detection and Control) Rules for appli= cation detection, enforcement and also charging starting from R12. Please= =20see architecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with = the GGSN (via Diameter), not the service functions, do you mean "for the = GGSN (or the flow classifier) to carry the data passed down from PCRF to = packets' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service trea= tment, i.e. desired sequence of service functions, to specific flows base= d on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions." is not correct as we= ll as PGW/PCEF is not the only element which enforces different support p= er different flows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architect= ure and make assumptions and conclusions about potential 3GPP elements fu= nctionality which are not in scope of IETF. If we want to define use case= s for 3GPP networks, then we should show correct picture of 3GPP archite= cture without redesigning it and leave 3GPP Network Elements functionalit= y potential extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +9= 72 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com w= ww.allot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson= ; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org= ; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and = service related metadata delivered from mobile control plane function lik= e PCRF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the = service functions, do you mean "for the GGSN (or the flow classifier) to = carry the data passed down from PCRF to packets' metadata field to servic= e functions on the chain"? Since the policies passed down by PCRF usually can't be understood by ser= vice functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related i= nformation, that are either embedded in packets as metadata or passed dow= n from control plane, to process the flows according to service related = policies" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" = used in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN ha= s a VLAN-ID?=20 I understand that some common classification scheme could be encoding a c= ertain QoS to a specific flow, applying some security functions to some f= lows, etc. The classification node can use simple VLAN-ID to mark differe= nt classification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC = BOF is very good.=20 Walter's wireless example is described in the Section 3.2 of https://data= tracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the sugge= sted text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treat= ment, i.e. desired sequence of service functions, to specific flows based= =20on the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-G= W separates the traffic into different categories (or flows) based on the= =20policies from PCRF. The traffic in each category (or flow) is mapped t= o a unique interface (a physical or virtual port) or a tunnel that is con= nected to the needed sequence of service functions.=20 =20 =20 | Mobile backhaul Network =20 =20 +-----+ | +---+---+ =20 =20 |PCRF | | |Network| =20 =20 | | < ---- > |Ctrller| =20 =20 +-----+ | +----+--+=20 =20 | | =20 =20 | | =20 =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> =20 | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> =20 | [PCEF]| | |Optimizer| | |=20 =20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> =20 | | | | | | |=20 =20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stie= merling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.or= g Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Hi Linda, First, thanks for the feedback. While it may look like a lot of component= s, we still have simplified 3GPP quite a lot. For example, in the first d= raft we left out the TDF that appears in recent standards. We=B9ll be add= ing that in response to other comments. I believe the overview section is= =20still quite short, but we will try to shorten it a bit further if it i= s too long. If you feel anything in particular is missing or extraneous, = please let us know. Yes, it is probably overkill to have two example APNs. The User & Pass ar= e important for example in cases of hot-lining where the user must first = be authenticated (for various reasons) before data services are provided/= continued. It is just another example of the important relationship betwe= en Classification (in an SFC sense) and Policy and Charging (in a 3GPP se= nse). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave = Dolson , Martin Stiemerling , "= draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph = >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not = >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile= >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statement= s > of the working group. > > Service function chains typically reside in a LAN segment which link= s > the mobile access network to the actual application platforms locate= d > in the carrier's datacenters or somewhere else in the Internet. > Service function chains ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy o= r > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Thu Feb 13 23:48:29 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE41A0121 for ; Thu, 13 Feb 2014 23:48:25 -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 wdcX4-iFeRX6 for ; Thu, 13 Feb 2014 23:48:23 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E41A0110 for ; Thu, 13 Feb 2014 23:48:23 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id e89so1707409qgf.5 for ; Thu, 13 Feb 2014 23:48:21 -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 :content-type; bh=qc2dGxOvHQURgFrjrXA63ZVHpOhH0n6/bZ1BPyQB7ss=; b=mUkKDFCkVXxwGtTBi3qEon3z/opsqOvPIL3CCBdVGOkym4KOOYM7CW8VKTbBb8PTLb w8RLQZYoHx2Gzg3SHwlJI7fnHEtz+L55+7msv0PnmZlv50/Q+E6kcLq3PMv32Upm6sFK u/h9qUbxeKRH1UxL7sOhbeOMPhKyWrl9nalKO3iH5Fo5CvqPUGu7JDKZLWfxkjyfDBxv xQ8hkTK+dR0QkW+T1lcSnqKNjyyEPvt4xh52nzITZag7YkzQSljn6jaVj1FNOfMI6AUs APB7zkjjraXO/fCXss3i0wMMcCZhVDhLHjLmUcq58GexxO7FIKc42YSy+K6XvzgBYJyS l9bg== MIME-Version: 1.0 X-Received: by 10.140.91.12 with SMTP id y12mr9776975qgd.26.1392364101751; Thu, 13 Feb 2014 23:48:21 -0800 (PST) Received: by 10.96.58.106 with HTTP; Thu, 13 Feb 2014 23:48:21 -0800 (PST) In-Reply-To: <20140214074016.19011.79557.idtracker@ietfa.amsl.com> References: <20140214074016.19011.79557.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:48:21 +0800 Message-ID: From: "Cao,Zhen" To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/O8vh0Jj9ozCeHdyxLr-RRY0GPNA Subject: [sfc] Fwd: I-D Action: draft-cao-sfc-control-orchestration-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:48:26 -0000 Hi All, Could you help review and comments the following draft? Thanks, Zhen&Hui. ---------- Forwarded message ---------- From: Date: Fri, Feb 14, 2014 at 3:40 PM Subject: I-D Action: draft-cao-sfc-control-orchestration-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Function Controller/Orchestration Requirements and Templates Authors : Zhen Cao Hui Deng Filename : draft-cao-sfc-control-orchestration-00.txt Pages : 9 Date : 2014-02-13 Abstract: Service Function Chain architecture further enables the modularity of network functions; network service functions can be split and chained together to compose complicated services. Network automation relies on a specific orchestrator to automatically deploy an end2end service or application. If this end2end service or application has a specific requirement to chaining several service functions, there is a need of an interface from the application to inform the orchestrator. This document investigates the problem. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cao-sfc-control-orchestration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Feb 14 00:28:01 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192F1A013F for ; Fri, 14 Feb 2014 00:27:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbj33BftZtS0 for ; Fri, 14 Feb 2014 00:27:53 -0800 (PST) Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE851A011E for ; Fri, 14 Feb 2014 00:27:52 -0800 (PST) Received: from smtp-ex1.fr.colt.net (smtp-ex1.fr.colt.net [213.41.78.194]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1E8RoV4031355 for ; Fri, 14 Feb 2014 09:27:50 +0100 Received: from smtp.qosmos.fr ([195.68.92.43] helo=mx3.qosmos.com) by smtp-ex1.fr.colt.net with esmtp (Exim) (envelope-from ) id 1WEE7e-0004wm-2S for ; Fri, 14 Feb 2014 09:27:50 +0100 X-IronPort-AV: E=Sophos;i="4.95,843,1384297200"; d="scan'208";a="852545" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 14 Feb 2014 09:27:43 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.110]) with mapi id 14.01.0438.000; Fri, 14 Feb 2014 09:27:47 +0100 From: Nicolas BOUTHORS To: Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKRxgXiHhbmNdIkmkarO0TCcKBJq0ZxkF Date: Fri, 14 Feb 2014 08:27:41 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D3E5408@LILAS.jungle.qosmos.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-ACL-Warn: 1/1 recipients OK. Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MxPNgY1oxH8SzwOD5zcxPJPJvl0 Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:27:59 -0000 Hello Ron,=0A= =0A= I agree on your statement that Metadata is beyond that required for proper = steering, given we have=0A= addressable applications or transparent mid-boxes.=0A= =0A= What about Transparent proxies, used for header insertion? They are not exp= licitly addresses and are not transparent middle boxes as they terminate a = tcp connection on one side, and create one on the other.=0A= =0A= They are quite common and they should be address via ad'hoc mechanisms as y= ou pointed out in a =0A= previous message, similarly to the issue of revealing Host Id discussed in = RFC 6967. =0A= =0A= I am just concerned to keep them in scope of what sfc should cover.=0A= =0A= Nicolas=0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Friday, February 14, 2014 1:33 AM=0A= To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org=0A= Subject: Re: [sfc] Framework=0A= =0A= Linda,=0A= =0A= Also, let's please separate "applications" and "service functions". I vie= w "applications" as things that are explicitly addressed, like an Apache Se= rver that realizes some web service -- no SFC steering was necessary to cau= se packets to reach it. "Service functions", on the other hand and purel= y from an SFC perspective, are transparent mid-boxes that would not have no= rmally been part of the data path unless special steering mechanisms were a= pplied or certain forced topologies were present in the network. Metadat= a, for SFC, is information above and beyond that required for proper steeri= ng that is passed amongst and between the SFC classifier(s) and the SFC ser= vice functions.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= Sent: Thursday, February 13, 2014 7:25 PM=0A= To: Linda Dunbar; sfc@ietf.org=0A= Subject: Re: [sfc] Framework=0A= =0A= I only consider the first of those to be metadata. The chain identificatio= n in the service chaining header or the transport header are not metadata. = Treating fields which are needed for steering as metadata induces massive = confusion. can we please keep those two concepts separate?!=0A= =0A= Yours,=0A= Joel=0A= =0A= On 2/13/14, 7:18 PM, Linda Dunbar wrote:=0A= >=0A= > I see two types of "metadata" being discussed here:=0A= >=0A= > 1. The "flow metadata", like the transactions carried by http flows.=0A= > They are inserted by applications, or inserted by a service function=0A= > to pass some "cookies" to the next one. (many proxy based service=0A= > functions have those capability)=0A= >=0A= > 2. The "Service Chain metadata", that are inserted by "Chain Classifier= " or control plane to carry extra information (in additional to Chain ID) f= or the purpose of controlling the sequence of functions on a chain.=0A= >=0A= > Correct?=0A= >=0A= > IMHO, the first bullet above are specific to applications or service func= tions internal processing. Many of today's proxy based service functions ma= ke changes to data packets, some of them make those changes for other servi= ce functions. Those changes won't be in the Service Chain Header field.=0A= >=0A= > Linda=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee=0A= > Sent: Thursday, February 13, 2014 2:51 PM=0A= > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org=0A= > Subject: Re: [sfc] Framework=0A= >=0A= > I believe most of us agree that an out of bad signalling will not address= the majority of requirement. Also a typical http flow carries many transac= tions and each can have different or additional classification. So a metada= ta can not be simple connected with one flow either. Current implementation= s of proxies and load balancers has addressed this in many ways including c= ustome header insertion. The custom header in this case equivalent of metad= ata vector.=0A= >=0A= > I think we need an efficient way annotate actual data with inline=0A= > metadata. I also strongly believe in solving the 80% of the use case=0A= >=0A= > Regards=0A= > Sumandra=0A= > ________________________________________=0A= > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > [jmh@joelhalpern.com]=0A= > Sent: Thursday, February 13, 2014 11:51 AM=0A= > To: Jerome Moisand; sfc@ietf.org=0A= > Subject: Re: [sfc] Framework=0A= >=0A= > I know very well what GTP does in terms of correlators, and why.=0A= > If all you need is an identifier for the subscriber, carrying a short ide= ntifier, and using it to select the desired behavior that has been pre-popu= lated when the subscribers session starts works really well.=0A= > That is part of why I am not objecting to having provision for out-of-ban= d metadata.=0A= >=0A= > However, claiming that a single such correlator is all that is needed for= even 80% of SFC cases (and I very much supporting trying to focus on the 8= 0% cases), just does not seem to work, given the broad range of requirement= s that we have seen.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > On 2/13/14, 2:35 PM, Jerome Moisand wrote:=0A= >> Joel,=0A= >>=0A= >> Protocols like GTP and L2TP work exactly that, with a form of session co= rrelator between the data plane and the control plane. This is very handy f= or subscriber and service management. Also if a correlator is defined as an= opaque and unique number, then one can avoid some of the pitfalls you desc= ribed. Long-lived metadata is clearly useful (and thanks for sharing, Reina= ldo, will read), and there is clear applicability to various service chaini= ng needs.=0A= >>=0A= >> Now this is just one way. The I-D Bruno referred to was just listing thi= s approach as one possible way among others. I totally agree with you that = other forms of metadata (like an outcome of the classification of a packet = or a sequence of a few packets) may not be suitable for out-of-band signali= ng.=0A= >>=0A= >> Bottomline seems to be that we have too many options to choose from, and= none of them solving it all... Tough.=0A= >>=0A= >> -----Original Message-----=0A= >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= >> Sent: Thursday, February 13, 2014 2:29 PM=0A= >> To: sfc@ietf.org=0A= >> Subject: Re: [sfc] Framework=0A= >>=0A= >> As I understand it, the tsvwg (and aeon) work is about flow metadata.=0A= >> That is long-lived metadata of use across many packets. That does indee= d seem well-suited to out-of-band cases.=0A= >>=0A= >> My concern is that in SFC, there are many cases which are at best badly-= addressed if we insist that they be solved using out-of-band metadata.=0A= >>=0A= >> Yours,=0A= >> Joel=0A= >>=0A= >> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote:=0A= >>> There is draft about transport independent metadata.=0A= >>>=0A= >>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodin=0A= >>> g=0A= >>> -=0A= >>> 01=0A= >>>=0A= >>> The complexities you mention are discussed there: variable-encoding,=0A= >>> direction, security of metadata, etc.=0A= >>>=0A= >>> Thanks,=0A= >>>=0A= >>> -RP=0A= >>>=0A= >>>=0A= >>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote:=0A= >>>=0A= >>>> While there are cases where out-of-band metadata makes sense, There=0A= >>>> are many cases I would not want to try to cover that way. The best=0A= >>>> examples are situations where the metadata changes from packet to=0A= >>>> packet (such as the data produced by a DPI engine for consumption=0A= >>>> by other applications in the chain.)=0A= >>>>=0A= >>>> More importantly, if you are putting correlators in the packet, it=0A= >>>> is still very complex if you want to use one correlator to handle=0A= >>>> metadata produced by several different entities (the initial=0A= >>>> classifer, the DPI engine, ...) You quickly end up deciding that=0A= >>>> you need several correlators. At which point we are back to variable = amounts of metadata.=0A= >>>>=0A= >>>> The alternative is to require exceedingly specific and strong=0A= >>>> coupling to a mandated out-of-band mechanism. That seems to me to=0A= >>>> be a very bad idea.=0A= >>>>=0A= >>>> Yours,=0A= >>>> Joel=0A= >>>>=0A= >>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote:=0A= >>>>> resend to avoid "too many recipients" warning=0A= >>>>>=0A= >>>>>=0A= >>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=0A= >>>>> > wrote:=0A= >>>>>=0A= >>>>> There are ways to signal variable length amounts of metadata w= ithout=0A= >>>>> needing an additional variable-length header on each data pack= et.=0A= >>>>>=0A= >>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of= the=0A= >>>>> possible approaches: out-of-band signaling (congruent or=0A= >>>>> non-congruent) or a hybrid approach using a fix-length in-band= =0A= >>>>> correlator and out-of-band additional metadata. See sections = 3.3,=0A= >>>>> 3.4 and 3.5 in the draft.=0A= >>>>>=0A= >>>>> The issue of fixed-length encoding versus variable length enco= ding=0A= >>>>> is discussion in the challenges chapter in section 4.3. I sho= uld=0A= >>>>> probably mention the MTU and segmentation issues as well in th= at=0A= >>>>> section.=0A= >>>>>=0A= >>>>>=0A= >>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern=0A= >>>>> > wrote:=0A= >>>>>=0A= >>>>> The variable length shim header is needed even if every=0A= >>>>> individual piece of metadata has a fixed length. Differen= t=0A= >>>>> service chains will need different combinations of metadat= a. So=0A= >>>>> the metadata portion of the header needs to be variable le= ngth.=0A= >>>>>=0A= >>>>> I think the approach of a fixed length initial part, and a= =0A= >>>>> variable length extension part, is the right model.=0A= >>>>>=0A= >>>>> Yours,=0A= >>>>> Joel=0A= >>>>>=0A= >>>>>=0A= >>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote:=0A= >>>>>=0A= >>>>> Yes, fragmentation and variable headers are usually a = really=0A= >>>>> bad thing for forwarding performance. Let's not forget= that=0A= >>>>> we live in a 100G-ish kind of world nowadays.=0A= >>>>>=0A= >>>>> Now the question should be: WHY would we want to do th= at=0A= >>>>> (variable headers leading to fragmentation issues)?=0A= >>>>>=0A= >>>>> For example, the type of metadata that may require=0A= >>>>> variable-length fields might be a better candidate for= some=0A= >>>>> out-of-band signaling mechanism. If this is service=0A= >>>>> authorization data (e.g. a service profile/policy), th= is=0A= >>>>> sounds likely. Not 100% sure this is true for all use = cases=0A= >>>>> though. Only a good understanding of use cases, ground= ed by=0A= >>>>> reflecting on existing network architectures (notably= =0A= >>>>> broadband, fixed or mobile), would tell us if one appr= oach=0A= >>>>> or another is the most appropriate.=0A= >>>>>=0A= >>>>> Anyhoo, we're jumping way deep in the detailed protoco= l=0A= >>>>> design here. This seems a tad premature.=0A= >>>>>=0A= >>>>> -----Original Message-----=0A= >>>>> From: sfc [mailto:sfc-bounces@ietf.org=0A= >>>>> ] On Behalf Of Dave Dolso= n=0A= >>>>> Sent: Thursday, February 13, 2014 11:03 AM=0A= >>>>> To: 'jmh@joelhalpern.com '= ;=0A= >>>>> 'Ron_Parker@affirmednetworks.__com=0A= >>>>> ';=0A= >>>>> 'mohamed.boucadair@orange.com=0A= >>>>> '__;=0A= >>>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>>> '; 'paulq@cisco.co= m=0A= >>>>> '=0A= >>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org ';=0A= >>>>> 'linda.dunbar@huawei.com '=0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> it is overall more efficient to support PMTU discovery= =0A= >>>>> rather than fragmenting every large packet. The is why= TCP=0A= >>>>> adopted it so early on.=0A= >>>>>=0A= >>>>> The fragmenting also puts huge performance burden on t= he=0A= >>>>> service functions.=0A= >>>>> Fragmenting may also affect the ability of load balanc= ers to=0A= >>>>> get each fragment to the correct destination.=0A= >>>>>=0A= >>>>> So PMTU discovery SHOULD be used, in my opinion. By th= is I=0A= >>>>> mean the client or server is informed that its packets= are=0A= >>>>> too big (for IPv6 or IPv4 with DF=3D1).=0A= >>>>>=0A= >>>>> Some operators may wish to incur the extra cost to hid= e the=0A= >>>>> existence of the tunneling, when the elements of the c= hain=0A= >>>>> can support it, so we could consider that as an option= al=0A= >>>>> mechanism.=0A= >>>>>=0A= >>>>> -Dave=0A= >>>>>=0A= >>>>>=0A= >>>>> ----- Original Message -----=0A= >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com=0A= >>>>> ]=0A= >>>>> Sent: Thursday, February 13, 2014 10:31 AM=0A= >>>>> To: Ron Parker >>>> >;=0A= >>>>> mohamed.boucadair@orange.com=0A= >>>>> =0A= >>>>> >>>> >__; Dave Dolson;= =0A= >>>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>>> '=0A= >>>>> >>>> >; 'paulq@cisco.co= m=0A= >>>>> ' >>>> >=0A= >>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org= =0A= >>>>> ' >;=0A= >>>>> 'linda.dunbar@huawei.com '=0A= >>>>> >=0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> I mostly agree with you Ron. I can probably come up w= ith=0A= >>>>> some other variations, but your second point is that t= he=0A= >>>>> transport must deal with the issue of frame size / fit= .=0A= >>>>>=0A= >>>>> I would note that if we assume that the carrying encap= s=0A= >>>>> (IPv4/v6 outer) is being fragmented, then we are assum= ing=0A= >>>>> that the exit from service chaining can and will reass= emble.=0A= >>>>>=0A= >>>>> Yours,=0A= >>>>> Joel=0A= >>>>>=0A= >>>>> On 2/13/14, 10:18 AM, Ron Parker wrote:=0A= >>>>>=0A= >>>>> Joel,=0A= >>>>>=0A= >>>>> That is an excellent point to consider when choosi= ng=0A= >>>>> transport=0A= >>>>> encapsulations. If the transport encapsulation i= s IPv4=0A= >>>>> or IPv6=0A= >>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=0A= >>>>> etc.), then=0A= >>>>> fragmentation and defragmentation are naturally=0A= >>>>> supported. If the=0A= >>>>> transport encapsulation is VLAN, MPLS, etc., then = I=0A= >>>>> believe one of the=0A= >>>>> following must be true:=0A= >>>>>=0A= >>>>> * The end-to-end path is known to support the resu= lting=0A= >>>>> larger frames=0A= >>>>> * A path discovery mechanism is mandated by SFC wh= en=0A= >>>>> non-IP transports=0A= >>>>> are used * An SFC-specific fragmentation header an= d=0A= >>>>> mechanisms must be=0A= >>>>> defined (i.e.,=0A= >>>>>=0A= >>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or=0A= >>>>> -=0A= >>>>> f=0A= >>>>> rame)=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: Joel M. Halpern= =0A= >>>>> [mailto:jmh@joelhalpern.com=0A= >>>>> ] Sent: Thursday, Febr= uary=0A= >>>>> 13, 2014 10:10=0A= >>>>> AM To: mohamed.boucadair@orange.com=0A= >>>>> ; Dave Dolson= ;=0A= >>>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>>> '; Ron Parker;= =0A= >>>>> 'paulq@cisco.com ' Cc:=0A= >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org ';=0A= >>>>> 'linda.dunbar@huawei.com=0A= >>>>> ' Subject:=0A= >>>>> Re: [sfc] Framework=0A= >>>>>=0A= >>>>> There is a related complexity. I hope that we expe= ct to=0A= >>>>> support IPv6.=0A= >>>>> IPv6 explicitly prohibits network elements from=0A= >>>>> fragmenting end user=0A= >>>>> packets.=0A= >>>>>=0A= >>>>> Yours, Joel=0A= >>>>>=0A= >>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com= =0A= >>>>> wrote:=0A= >>>>>=0A= >>>>> Re-,=0A= >>>>>=0A= >>>>> FWIW, one of the existing architecture drafts= =0A= >>>>> includes the following=0A= >>>>> behavior=0A= >>>>>=0A= >>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#s=0A= >>>>> e=0A= >>>>> c=0A= >>>>> tion-=0A= >>>>> 6=0A= >>>>>=0A= >>>>> ):=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> "=0A= >>>>>=0A= >>>>> 6. Fragmentation Considerations=0A= >>>>>=0A= >>>>> If adding the Service Chaining Header would re= sult=0A= >>>>> in a fragmented=0A= >>>>> packet, the classifier should include a Servic= e=0A= >>>>> Chaining Header in=0A= >>>>> each fragment. Doing so would prevent SF Node= s to=0A= >>>>> dedicate resource=0A= >>>>> to handle fragments. "=0A= >>>>>=0A= >>>>> Cheers, Med=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Message d'origine----- De : sfc=0A= >>>>> [mailto:sfc-bounces@ietf.org=0A= >>>>> ]=0A= >>>>> De la part de Dave Dolson Envoy=E9 :=0A= >>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 :=0A= >>>>> 'Nicolas.BOUTHORS@qosmos.com=0A= >>>>> ';=0A= >>>>> 'Ron_Parker@affirmednetworks.__com=0A= >>>>> ';= =0A= >>>>> 'jmh@joelhalpern.com=0A= >>>>> ';=0A= >>>>> 'paulq@cisco.com '= Cc :=0A= >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org=0A= >>>>> ';=0A= >>>>> 'linda.dunbar@huawei.com=0A= >>>>> ' Objet : = Re:=0A= >>>>> [sfc] Framework=0A= >>>>>=0A= >>>>> Good point to consider fragmentation.=0A= >>>>>=0A= >>>>> We should design the encapsulation such th= at the=0A= >>>>> forwarding=0A= >>>>> functions do not need to reassemble. Each= =0A= >>>>> fragment should be=0A= >>>>> independently forwardable; some SFs may ch= oose=0A= >>>>> to ignore these=0A= >>>>> packets.=0A= >>>>>=0A= >>>>> Any layer 2.5 protocol like VLAN or MPLS w= ould=0A= >>>>> support this.=0A= >>>>> Otherwise, a reassembly layer could be add= ed=0A= >>>>> after the forwarding=0A= >>>>> coordinates. Think of something like the I= Pv6=0A= >>>>> reassembly option=0A= >>>>> after a GRE header, for instance.=0A= >>>>>=0A= >>>>> IP | GRE | reassem | frag data=0A= >>>>>=0A= >>>>> We could alternatively mandate the inner I= P be=0A= >>>>> fragmented and that=0A= >>>>> path-MTU discovery be supported.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> ----- Original Message ----- From:=0A= >>>>> Nicolas BOUTHORS=0A= >>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com=0A= >>>>> ] Sent= :=0A= >>>>> Thursday, February 13,=0A= >>>>> 2014 04:13 AM To: Ron Parker=0A= >>>>> >>>> >;= =0A= >>>>> Dave Dolson; Joel M. Halpern=0A= >>>>> >>>> >; Paul Quinn= =0A= >>>>> (paulq) >>>> > Cc: Sumandra Maj= ee=0A= >>>>> ;=0A= >>>>> sfc@ietf.org >>>> >; Linda Dunbar=0A= >>>>> >>>> >=0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> If we do not enforce a fix header size we = have=0A= >>>>> other implication.=0A= >>>>>=0A= >>>>> There is the question of segmentation and= =0A= >>>>> reassembly responsibility=0A= >>>>> as well.=0A= >>>>>=0A= >>>>> If adding length to the service header for= ces=0A= >>>>> segmentation, then=0A= >>>>> whose responsibility is it to reassemble t= he=0A= >>>>> payload before passing=0A= >>>>> it to the SF.=0A= >>>>>=0A= >>>>> Similar question for packet re-ordering.= =0A= >>>>>=0A= >>>>>=0A= >>>>> __________________________________________= From:=0A= >>>>> Ron Parker=0A= >>>>> [Ron_Parker@affirmednetworks.__com=0A= >>>>> ] = Sent:=0A= >>>>> Wednesday, February 12,=0A= >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Hal= pern;=0A= >>>>> Paul Quinn=0A= >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org= =0A= >>>>> ; Linda Dunbar Subjec= t:=0A= >>>>> Re: [sfc] Framework=0A= >>>>>=0A= >>>>> Dave,=0A= >>>>>=0A= >>>>> Yes, that is a good point if we logically= =0A= >>>>> separate the forwarding=0A= >>>>> function from the SFC-aware service functi= on, as=0A= >>>>> we should. The=0A= >>>>> forwarding function is concerned with only= the=0A= >>>>> inbound transport=0A= >>>>> header, the fixed portion of the service = header=0A= >>>>> containing the=0A= >>>>> chain information, and the outbound transp= ort=0A= >>>>> header. The=0A= >>>>> service function may look at the entirety = of the=0A= >>>>> service header and=0A= >>>>> would look at the encapsulated packet.=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: Dave Dols= on=0A= >>>>> [mailto:ddolson@sandvine.com=0A= >>>>> ] Sent: Wedne= sday,=0A= >>>>> February 12, 2014=0A= >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; P= aul=0A= >>>>> Quinn (paulq) Cc:=0A= >>>>> Sumandra Majee; sfc@ietf.org=0A= >>>>> ; Linda Dunbar Subjec= t: RE:=0A= >>>>> [sfc]=0A= >>>>> Framework=0A= >>>>>=0A= >>>>> The forwarding plane might not even need t= o look=0A= >>>>> at the encapsulated=0A= >>>>> packet.=0A= >>>>>=0A= >>>>> For example, (if the SF Identifier is a VL= AN=0A= >>>>> tag), an Ethernet=0A= >>>>> switch can forward packets of the form: E= ther |=0A= >>>>> VLAN | BLOB.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: sfc=0A= >>>>> [mailto:sfc-bounces@ietf.org=0A= >>>>> ]=0A= >>>>> On Behalf Of Joel M. Halpern Sent:=0A= >>>>> Wednesday, February 12, 2014 4:30 PM To: R= on=0A= >>>>> Parker; Dave Dolson;=0A= >>>>> Paul Quinn (paulq) Cc: Sumandra Majee;=0A= >>>>> sfc@ietf.org ; Linda = Dunbar=0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> I agree as well. Yours, Joel=0A= >>>>>=0A= >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote:=0A= >>>>>=0A= >>>>> Hi, Dave.=0A= >>>>>=0A= >>>>> I Agree with your statement. And i= f the=0A= >>>>> total length of the=0A= >>>>> header is=0A= >>>>>=0A= >>>>> contained in the mandatory portion, the ha= rdware=0A= >>>>> implementation can=0A= >>>>> easily locate the encapsulated packet.=0A= >>>>>=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: Dave = Dolson=0A= >>>>> [mailto:ddolson@sandvine.com=0A= >>>>> ] Sent:= =0A= >>>>> Wednesday, February 12,=0A= >>>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n=0A= >>>>> (paulq) Cc: Joel M.=0A= >>>>> Halpern; Sumandra Majee; sfc@ietf.org= =0A= >>>>> ; Linda Dunbar Su= bject:=0A= >>>>> RE: [sfc] Framework=0A= >>>>>=0A= >>>>> I think a good approach would be:=0A= >>>>>=0A= >>>>> The information required for forwardin= g (the=0A= >>>>> SF Identifier) should=0A= >>>>> be in=0A= >>>>>=0A= >>>>> a mandatory fixed-size header.=0A= >>>>>=0A= >>>>>=0A= >>>>> Optional information (if any) is NOT t= o be=0A= >>>>> used for forwarding, but=0A= >>>>> is=0A= >>>>>=0A= >>>>> for consumption by one or more of the=0A= >>>>> applications in the chain.=0A= >>>>>=0A= >>>>>=0A= >>>>> Then the forwarding plane, and even th= e PDP,=0A= >>>>> can be agnostic about=0A= >>>>> the=0A= >>>>>=0A= >>>>> meta-data.=0A= >>>>>=0A= >>>>>=0A= >>>>> -Dave=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: sfc= =0A= >>>>> [mailto:sfc-bounces@ietf.org=0A= >>>>> ]=0A= >>>>> On Behalf Of Ron Parker Sent:=0A= >>>>> Wednesday, February 12, 2014 4:05 PM T= o:=0A= >>>>> Paul Quinn (paulq) Cc:=0A= >>>>> Joel M. Halpern; Sumandra Majee;=0A= >>>>> sfc@ietf.org ;=0A= >>>>> Linda Dunbar=0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> Paul,=0A= >>>>>=0A= >>>>> That is why I am proposing a hybrid wh= ere=0A= >>>>> extensions or options can=0A= >>>>> be=0A= >>>>>=0A= >>>>> added but the total length is contained in= the=0A= >>>>> fixed portion. I=0A= >>>>> can envision certain deployments (e.g.,=0A= >>>>> Enterprise) where perhaps=0A= >>>>> extensions are not needed and the SFC=0A= >>>>> functionality is realized=0A= >>>>> in hardware. And, I can envision certain= other=0A= >>>>> deployments=0A= >>>>> (e.g., 3gpp) where the extension headers a= dd=0A= >>>>> sufficient value to=0A= >>>>> justify software based implementations.=0A= >>>>>=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From: Paul = Quinn=0A= >>>>> (paulq)=0A= >>>>> [mailto:paulq@cisco.com=0A= >>>>> ] Sent: Wednes= day,=0A= >>>>> February 12, 2014=0A= >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Ma= jee;=0A= >>>>> Linda Dunbar; Joel M.=0A= >>>>> Halpern; sfc@ietf.org =0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> Hi,=0A= >>>>>=0A= >>>>> We certainly need to be very careful w= ith=0A= >>>>> variable length headers=0A= >>>>> when=0A= >>>>>=0A= >>>>> hardware platform are in play.=0A= >>>>>=0A= >>>>>=0A= >>>>> Ron, your examples of IP options and v= 6 EH=0A= >>>>> have both suffered from=0A= >>>>>=0A= >>>>> significant implementation and deployment= =0A= >>>>> hurdles due to the=0A= >>>>> complexity and cost associated with hardwa= re=0A= >>>>> support for the=0A= >>>>> option/EH.=0A= >>>>>=0A= >>>>>=0A= >>>>> Paul=0A= >>>>>=0A= >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r=0A= >>>>> >>>>=0A= >>>>> >=0A= >>>>>=0A= >>>>> wrote:=0A= >>>>>=0A= >>>>>=0A= >>>>> Hi, Sumandra.=0A= >>>>>=0A= >>>>> Regarding service header flexibili= ty, I=0A= >>>>> completely agree. I=0A= >>>>> might=0A= >>>>>=0A= >>>>> suggest a compromise between hardware=0A= >>>>> friendliness and software=0A= >>>>> flexibility. If the header had the abil= ity to=0A= >>>>> add extensions=0A= >>>>> (perhaps similar to IPv6) but also had the= =0A= >>>>> header length encoded in=0A= >>>>> the mandatory part (like IPv4), then a har= dware=0A= >>>>> implementation would=0A= >>>>> be free to skip over the extensions (in ca= ses=0A= >>>>> where the deployment=0A= >>>>> justifies ignoring the extensions).=0A= >>>>>=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- From:= =0A= >>>>> Sumandra Majee=0A= >>>>> [mailto:S.Majee@F5.com=0A= >>>>> ] Sent:=0A= >>>>> Wednesday, February 12, 2014=0A= >>>>> 3:04 PM To: Ron Parker; Linda Dunb= ar;=0A= >>>>> Joel M. Halpern;=0A= >>>>> sfc@ietf.org = =0A= >>>>> Subject: Re: [sfc] Framework=0A= >>>>>=0A= >>>>> For all of those reasons, = I=0A= >>>>> strongly support a=0A= >>>>> canonical service=0A= >>>>> header that is independent= of=0A= >>>>> the transport methodology.= =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> I agree. However the format of ser= vice=0A= >>>>> header should be=0A= >>>>> standardized in=0A= >>>>>=0A= >>>>> a way that is flexible. Some of us would l= ike to=0A= >>>>> see variable length=0A= >>>>> header that is also HW friendly. The servi= ce=0A= >>>>> header can be=0A= >>>>> represented as a mandotory fixed length he= ader=0A= >>>>> (like IP=0A= >>>>> header) along with an optional variable le= ngth=0A= >>>>> attribute field.=0A= >>>>> Different services can be interested in=0A= >>>>> different metadata, for=0A= >>>>> example subscriber ID could be of interest= in=0A= >>>>> the mobile core=0A= >>>>> service chain only.=0A= >>>>>=0A= >>>>>=0A= >>>>> Sumandra=0A= >>>>>=0A= >>>>> On 2/12/14, 11:32 AM, "Ron Parker"= =0A= >>>>>=0A= >>>>> >>>>=0A= >>>>> >=0A= >>>>>=0A= >>>>> wrote:=0A= >>>>>=0A= >>>>>=0A= >>>>> Linda,=0A= >>>>>=0A= >>>>> My interpretation of the=0A= >>>>> architecture docs is that=0A= >>>>> the service=0A= >>>>> function chain is built in an= =0A= >>>>> abstract manner (i.e., SF-A th= en=0A= >>>>> SF-B=0A= >>>>>=0A= >>>>> then SF-C).=0A= >>>>>=0A= >>>>> Separately, a locator table pr= ovides=0A= >>>>> network location for=0A= >>>>> each of those service function= s.=0A= >>>>> In this way, you can=0A= >>>>> locate the service=0A= >>>>> functions=0A= >>>>>=0A= >>>>> in=0A= >>>>>=0A= >>>>> a manner appropriate to the ty= pe of=0A= >>>>> transport you are=0A= >>>>> using. If you want that to b= e=0A= >>>>> interface+VLAN,=0A= >>>>> gateway-IP+MPLS label=0A= >>>>> stack, IP=0A= >>>>>=0A= >>>>> address,=0A= >>>>>=0A= >>>>> GRE tunnel remote IP + key, et= c.,=0A= >>>>> you can do that. You=0A= >>>>> can even potentially locate=0A= >>>>> different service functions th= at=0A= >>>>> reside in the same chain with= =0A= >>>>> different flavors of=0A= >>>>> network locators. Another= =0A= >>>>> justification to separate the= =0A= >>>>> identity of a service function= from=0A= >>>>> its network location is=0A= >>>>> load balancing. If, for exam= ple,=0A= >>>>> SF-A had 3 IP addresses,=0A= >>>>> that would imply load balancin= g to 3=0A= >>>>> instances using IP as a=0A= >>>>> transport layer.=0A= >>>>>=0A= >>>>> For all of those reasons, I st= rongly=0A= >>>>> support a canonical service=0A= >>>>> header that is independent of = the=0A= >>>>> transport=0A= >>>>> methodology. At a particula= r=0A= >>>>> node, the decision as to=0A= >>>>> where to go next should be bas= ed=0A= >>>>> solely on information carried = in=0A= >>>>> the canonical service header a= nd not=0A= >>>>> on the=0A= >>>>>=0A= >>>>> fields=0A= >>>>>=0A= >>>>> in the transport header. Tha= t is,=0A= >>>>> the SFC node discards=0A= >>>>> the transport header and extra= cts=0A= >>>>> the chain ID from the=0A= >>>>> service header. Through=0A= >>>>> mechanisms we have not yet beg= un=0A= >>>>> to discuss, the SFC node knows= how=0A= >>>>> to interpret the chain ID and= =0A= >>>>> ultimately how to progress=0A= >>>>> the packet.=0A= >>>>>=0A= >>>>> Ron=0A= >>>>>=0A= >>>>>=0A= >>>>> -----Original Message----- Fro= m: sfc=0A= >>>>> [mailto:sfc-bounces@ietf.org= =0A= >>>>> ]= On=0A= >>>>> Behalf Of Linda Dunbar=0A= >>>>> Sent: Wednesday, February 12, = 2014=0A= >>>>> 12:01 PM To: Joel M.=0A= >>>>> Halpern; sfc@ietf.org=0A= >>>>> Subject:= Re:=0A= >>>>> [sfc] Framework=0A= >>>>>=0A= >>>>> Agree with Joel's statement.= =0A= >>>>>=0A= >>>>> I think a simple sentence belo= w=0A= >>>>> should be added Section 5.2 (S= FC=0A= >>>>> Classifier) to emphasize this = point.=0A= >>>>>=0A= >>>>> "A Service Chain Classifier no= de can=0A= >>>>> associate a unique Layer 2=0A= >>>>> or 3 Label (e.g. VLAN, MPLS la= bel)=0A= >>>>> to the packets in the flow.=0A= >>>>> Those Layer 2 or 3 Label makes= it=0A= >>>>> easier for subsequent nodes=0A= >>>>> along the flow path to steer t= he=0A= >>>>> flow to the service functions= =0A= >>>>> specified by the flow's=0A= >>>>> service chain."=0A= >>>>>=0A= >>>>>=0A= >>>>> Linda -----Original Message---= --=0A= >>>>> From: sfc=0A= >>>>> [mailto:sfc-bounces@ietf.org= =0A= >>>>> ]= On=0A= >>>>> Behalf Of Joel M. Halpern=0A= >>>>> Sent: Wednesday, February 12, = 2014=0A= >>>>> 10:20 AM To:=0A= >>>>> sfc@ietf.org =0A= >>>>> Subject: [sfc] Framework=0A= >>>>>=0A= >>>>> I was looking at the framework= =0A= >>>>> proposal. The proposal has a v= ery=0A= >>>>> specific model of the scope of= the=0A= >>>>> transport header (that it is= =0A= >>>>> derived from, and relates only= to,=0A= >>>>> the first service function to= =0A= >>>>> which the packet will be direc= ted.=0A= >>>>> That is clearly an operational= =0A= >>>>> model we need to support.=0A= >>>>>=0A= >>>>> However, I would like to allow= other=0A= >>>>> transport operational=0A= >>>>> models, such as the use of a V= LAN to=0A= >>>>> direct traffic along a=0A= >>>>> chain. Or the use of an MPLS = label,=0A= >>>>> or an MPLS label stack.=0A= >>>>>=0A= >>>>> Yours, Joel M. Halpern=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org=0A= >>>>> =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org=0A= >>>>> =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org=0A= >>>>> =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org=0A= >>>>> =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________ sfc=0A= >>>>> mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________ sfc=0A= >>>>> mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________ sfc=0A= >>>>> mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>>=0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>>=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> _________________________________________________=0A= >>>>> sfc mailing list=0A= >>>>> sfc@ietf.org =0A= >>>>> https://www.ietf.org/mailman/__listinfo/sfc=0A= >>>>> =0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>>=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >>=0A= >>=0A= >>=0A= >=0A= > _______________________________________________=0A= > sfc mailing list=0A= > sfc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= > _______________________________________________=0A= > sfc mailing list=0A= > sfc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= =0A= =0A= From nobody Fri Feb 14 01:13:56 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40471A0201 for ; Fri, 14 Feb 2014 01:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 rU1RLSpjXp1s for ; Fri, 14 Feb 2014 01:13:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2CF1A01D8 for ; Fri, 14 Feb 2014 01:13:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD01387; Fri, 14 Feb 2014 09:13:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 09:13:22 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 09:13:40 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 17:13:37 +0800 From: Wangdanhua To: "sfc@ietf.org" Thread-Topic: Forward: New Version Notification for draft-ww-sfc-control-plane-00.txt Thread-Index: AQHPKWULXxKZcEZY8U2kxLzmvAcuSQ== Date: Fri, 14 Feb 2014 09:13:36 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/krhB-YdkhRh0xBzdr7SRRQY85xg Subject: [sfc] Forward: New Version Notification for draft-ww-sfc-control-plane-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:13:52 -0000 DQpIaSBhbGwsDQoNCldlJ3ZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IChkcmFmdC13dy1z ZmMtY29udHJvbC1wbGFuZS0wMCkgdG8gU0ZDIFdHLiBBbnkgY29tbWVudHMgb3Igc3VnZ2VzdGlv bnMgYXJlIGFwcHJlY2lhdGVkLg0KDQpCZXN0IHdpc2hlcywNCkRhbmh1YSBXYW5nDQoNCg0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUWluIFd1IGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13dy1zZmMtY29udHJvbC1wbGFu ZQ0KUmV2aXNpb246CTAwDQpUaXRsZToJCVNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gQ29udHJvbCBQ bGFuZSBPdmVydmlldw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMi0xNA0KR3JvdXA6CQlJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 dy1zZmMtY29udHJvbC1wbGFuZS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wMA0KDQoNCkFic3RyYWN0Og0KICAg QXMgZGVzY3JpYmVkIGluIFtJLkQtYm91Y2FkYWlyLXNmYy1mcmFtZXdvcmtdLCB0aGUgZHluYW1p Yw0KICAgZW5mb3JjZW1lbnQgb2YgYSBTZXJ2aWNlLWRlcml2ZWQsIGFkZXF1YXRlIGZvcndhcmRp bmcgcG9saWN5IGZvcg0KICAgcGFja2V0cyBlbnRlcmluZyBhIG5ldHdvcmsgdGhhdCBzdXBwb3J0 cyBzdWNoIGFkdmFuY2VkIFNlcnZpY2UNCiAgIEZ1bmN0aW9ucyBoYXMgYmVjb21lIGEga2V5IGNo YWxsZW5nZSBmb3Igb3BlcmF0b3JzIGFuZCBzZXJ2aWNlDQogICBwcm92aWRlcnMuDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgYmFzZWQgb24gW0kuRC1ib3VjYWRhaXItc2ZjLWZyYW1ld29ya10gYW5k IGZvY3VzaW5nDQogICBvbiBkaXNjdXNzaW5nIGhvdyB0aGUgU2VydmljZSBGdW5jdGlvbnMgYXJl IGRpc2NvdmVyZWQgYW5kDQogICBwcm92aXNpb25lZCBhbmQgaG93IFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5pbmcgcGF0aCBpcyBzZXR1cC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Fri Feb 14 04:40:36 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAC51A03BB for ; Thu, 13 Feb 2014 10:39:26 -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 84l9E48WVVTY for ; Thu, 13 Feb 2014 10:39:20 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 514CF1A03C0 for ; Thu, 13 Feb 2014 10:39:20 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so8840876veb.14 for ; Thu, 13 Feb 2014 10:39:18 -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=0yPkgzG2HwjBkS9hvu3rFQm0LzhXVxq4FekJ1Nd8ILc=; b=UKQ6xfmTexLLR0nMw3ThelrPI2fbx1cGjnXb2YVIGzPtynu5JlRKgYrETZbfi4ZL0b FxBqxnM/CDAIcXu7V/AWCbCUvUmcobKYLSRn7gg7ll9aIO+y6qj11IBpxiBeAEDqpJQT wXDZkuPanxbfbIoBWxYfu1c2JpatN98o7F4dnvsKIWIwiptSG5VEQh/iZ1AHrl306i2v DqiR97x/3E7xHpq5x12QBDgQjvgKSTkSrRiHsRY8Qy7HTMA05lNLfJnUDVjLHOYOoZls eppcWLWk+PN/dj7MZOjnKga1msOhCqJ4/FFPc7h4q915KA86Hz/VlpVU6B2m2zY06SKI 0t6A== MIME-Version: 1.0 X-Received: by 10.58.54.15 with SMTP id f15mr1803906vep.5.1392316758808; Thu, 13 Feb 2014 10:39:18 -0800 (PST) Received: by 10.58.133.109 with HTTP; Thu, 13 Feb 2014 10:39:18 -0800 (PST) In-Reply-To: <52FD0BE3.7050903@joelhalpern.com> References: <52FCE54A.5090403@joelhalpern.com> <4d18b3b776594bbd986589d6a6858aed@CO2PR05MB716.namprd05.prod.outlook.com> <52FD0BE3.7050903@joelhalpern.com> Date: Thu, 13 Feb 2014 13:39:18 -0500 Message-ID: From: Bruno Rijsman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e01294232d2de8904f24e01d4 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RWGeSv-SNm_BZgrVOOTQC0Dd__8 X-Mailman-Approved-At: Fri, 14 Feb 2014 04:40:35 -0800 Cc: "Nicolas.BOUTHORS@qosmos.com" , "S.Majee@F5.com" , "sfc@ietf.org" , "linda.dunbar@huawei.com" , "paulq@cisco.com" , "Ron_Parker@affirmednetworks.com" , "mohamed.boucadair@orange.com" , Dave Dolson Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:39:26 -0000 --089e01294232d2de8904f24e01d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are ways to signal variable length amounts of metadata without needing an additional variable-length header on each data packet. draft-rijsman-sfc-metadata-considerations-00 discusses some of the possible approaches: out-of-band signaling (congruent or non-congruent) or a hybrid approach using a fix-length in-band correlator and out-of-band additional metadata. See sections 3.3, 3.4 and 3.5 in the draft. The issue of fixed-length encoding versus variable length encoding is discussion in the challenges chapter in section 4.3. I should probably mention the MTU and segmentation issues as well in that section. On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern wrote= : > The variable length shim header is needed even if every individual piece > of metadata has a fixed length. Different service chains will need > different combinations of metadata. So the metadata portion of the heade= r > needs to be variable length. > > I think the approach of a fixed length initial part, and a variable lengt= h > extension part, is the right model. > > Yours, > Joel > > > On 2/13/14, 11:13 AM, Jerome Moisand wrote: > >> Yes, fragmentation and variable headers are usually a really bad thing >> for forwarding performance. Let's not forget that we live in a 100G-ish >> kind of world nowadays. >> >> Now the question should be: WHY would we want to do that (variable >> headers leading to fragmentation issues)? >> >> For example, the type of metadata that may require variable-length field= s >> might be a better candidate for some out-of-band signaling mechanism. If >> this is service authorization data (e.g. a service profile/policy), this >> sounds likely. Not 100% sure this is true for all use cases though. Only= a >> good understanding of use cases, grounded by reflecting on existing netw= ork >> architectures (notably broadband, fixed or mobile), would tell us if one >> approach or another is the most appropriate. >> >> Anyhoo, we're jumping way deep in the detailed protocol design here. Thi= s >> seems a tad premature. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Thursday, February 13, 2014 11:03 AM >> To: 'jmh@joelhalpern.com'; 'Ron_Parker@affirmednetworks.com'; ' >> mohamed.boucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; ' >> paulq@cisco.com' >> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' >> Subject: Re: [sfc] Framework >> >> it is overall more efficient to support PMTU discovery rather than >> fragmenting every large packet. The is why TCP adopted it so early on. >> >> The fragmenting also puts huge performance burden on the service >> functions. >> Fragmenting may also affect the ability of load balancers to get each >> fragment to the correct destination. >> >> So PMTU discovery SHOULD be used, in my opinion. By this I mean the >> client or server is informed that its packets are too big (for IPv6 or I= Pv4 >> with DF=3D1). >> >> Some operators may wish to incur the extra cost to hide the existence of >> the tunneling, when the elements of the chain can support it, so we coul= d >> consider that as an optional mechanism. >> >> -Dave >> >> >> ----- Original Message ----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Thursday, February 13, 2014 10:31 AM >> To: Ron Parker ; >> mohamed.boucadair@orange.com ; Dave >> Dolson; 'Nicolas.BOUTHORS@qosmos.com' ; ' >> paulq@cisco.com' >> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org' ; ' >> linda.dunbar@huawei.com' >> Subject: Re: [sfc] Framework >> >> I mostly agree with you Ron. I can probably come up with some other >> variations, but your second point is that the transport must deal with t= he >> issue of frame size / fit. >> >> I would note that if we assume that the carrying encaps (IPv4/v6 outer) >> is being fragmented, then we are assuming that the exit from service >> chaining can and will reassemble. >> >> Yours, >> Joel >> >> On 2/13/14, 10:18 AM, Ron Parker wrote: >> >>> Joel, >>> >>> That is an excellent point to consider when choosing transport >>> encapsulations. If the transport encapsulation is IPv4 or IPv6 >>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then >>> fragmentation and defragmentation are naturally supported. If the >>> transport encapsulation is VLAN, MPLS, etc., then I believe one of the >>> following must be true: >>> >>> * The end-to-end path is known to support the resulting larger frames >>> * A path discovery mechanism is mandated by SFC when non-IP transports >>> are used * An SFC-specific fragmentation header and mechanisms must be >>> defined (i.e., >>> SFC-transport/SFC-fragmentation/SFC-service/original-packet-or-frame) >>> >>> Ron >>> >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com] Sent: Thursday, February 13, 2014 10:10 >>> AM To: mohamed.boucadair@orange.com; Dave Dolson; >>> 'Nicolas.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc: >>> 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject: >>> Re: [sfc] Framework >>> >>> There is a related complexity. I hope that we expect to support IPv6. >>> IPv6 explicitly prohibits network elements from fragmenting end user >>> packets. >>> >>> Yours, Joel >>> >>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote: >>> >>>> Re-, >>>> >>>> FWIW, one of the existing architecture drafts includes the following >>>> behavior >>>> (http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6 >>>> ): >>>> >>>> >>>> >>>> " >> >>> 6. Fragmentation Considerations >>>> >>>> If adding the Service Chaining Header would result in a fragmented >>>> packet, the classifier should include a Service Chaining Header in >>>> each fragment. Doing so would prevent SF Nodes to dedicate resource >>>> to handle fragments. " >>>> >>>> Cheers, Med >>>> >>>> >>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >>>>> De la part de Dave Dolson Envoy=E9 : >>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com'; >>>>> 'Ron_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com'; >>>>> 'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org'; >>>>> 'linda.dunbar@huawei.com' Objet : Re: [sfc] Framework >>>>> >>>>> Good point to consider fragmentation. >>>>> >>>>> We should design the encapsulation such that the forwarding >>>>> functions do not need to reassemble. Each fragment should be >>>>> independently forwardable; some SFs may choose to ignore these >>>>> packets. >>>>> >>>>> Any layer 2.5 protocol like VLAN or MPLS would support this. >>>>> Otherwise, a reassembly layer could be added after the forwarding >>>>> coordinates. Think of something like the IPv6 reassembly option >>>>> after a GRE header, for instance. >>>>> >>>>> IP | GRE | reassem | frag data >>>>> >>>>> We could alternatively mandate the inner IP be fragmented and that >>>>> path-MTU discovery be supported. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: Nicolas BOUTHORS >>>>> [mailto:Nicolas.BOUTHORS@qosmos.com] Sent: Thursday, February 13, >>>>> 2014 04:13 AM To: Ron Parker ; >>>>> Dave Dolson; Joel M. Halpern ; Paul Quinn >>>>> (paulq) Cc: Sumandra Majee ; >>>>> sfc@ietf.org ; Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> If we do not enforce a fix header size we have other implication. >>>>> >>>>> There is the question of segmentation and reassembly responsibility >>>>> as well. >>>>> >>>>> If adding length to the service header forces segmentation, then >>>>> whose responsibility is it to reassemble the payload before passing >>>>> it to the SF. >>>>> >>>>> Similar question for packet re-ordering. >>>>> >>>>> >>>>> ________________________________________ From: Ron Parker >>>>> [Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 12, >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> Dave, >>>>> >>>>> Yes, that is a good point if we logically separate the forwarding >>>>> function from the SFC-aware service function, as we should. The >>>>> forwarding function is concerned with only the inbound transport >>>>> header, the fixed portion of the service header containing the >>>>> chain information, and the outbound transport header. The >>>>> service function may look at the entirety of the service header and >>>>> would look at the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dolson >>>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, 2014 >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc: >>>>> Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: RE: [sfc] >>>>> Framework >>>>> >>>>> The forwarding plane might not even need to look at the encapsulated >>>>> packet. >>>>> >>>>> For example, (if the SF Identifier is a VLAN tag), an Ethernet >>>>> switch can forward packets of the form: Ether | VLAN | BLOB. >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of Joel M. Halpern Sent: >>>>> Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson; >>>>> Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I agree as well. Yours, Joel >>>>> >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> >>>>>> Hi, Dave. >>>>>> >>>>>> I Agree with your statement. And if the total length of the >>>>>> header is >>>>>> >>>>> contained in the mandatory portion, the hardware implementation can >>>>> easily locate the encapsulated packet. >>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Dave Dolson >>>>>> [mailto:ddolson@sandvine.com] Sent: Wednesday, February 12, >>>>>> 2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M. >>>>>> Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject: >>>>>> RE: [sfc] Framework >>>>>> >>>>>> I think a good approach would be: >>>>>> >>>>>> The information required for forwarding (the SF Identifier) should >>>>>> be in >>>>>> >>>>> a mandatory fixed-size header. >>>>> >>>>>> >>>>>> Optional information (if any) is NOT to be used for forwarding, but >>>>>> is >>>>>> >>>>> for consumption by one or more of the applications in the chain. >>>>> >>>>>> >>>>>> Then the forwarding plane, and even the PDP, can be agnostic about >>>>>> the >>>>>> >>>>> meta-data. >>>>> >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>>> On Behalf Of Ron Parker Sent: >>>>>> Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc: >>>>>> Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Paul, >>>>>> >>>>>> That is why I am proposing a hybrid where extensions or options can >>>>>> be >>>>>> >>>>> added but the total length is contained in the fixed portion. I >>>>> can envision certain deployments (e.g., Enterprise) where perhaps >>>>> extensions are not needed and the SFC functionality is realized >>>>> in hardware. And, I can envision certain other deployments >>>>> (e.g., 3gpp) where the extension headers add sufficient value to >>>>> justify software based implementations. >>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Paul Quinn (paulq) >>>>>> [mailto:paulq@cisco.com] Sent: Wednesday, February 12, 2014 >>>>>> 3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M. >>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>> >>>>>> Hi, >>>>>> >>>>>> We certainly need to be very careful with variable length headers >>>>>> when >>>>>> >>>>> hardware platform are in play. >>>>> >>>>>> >>>>>> Ron, your examples of IP options and v6 EH have both suffered from >>>>>> >>>>> significant implementation and deployment hurdles due to the >>>>> complexity and cost associated with hardware support for the >>>>> option/EH. >>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> On Feb 12, 2014, at 3:10 PM, Ron Parker >>>>>> >>>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi, Sumandra. >>>>>>> >>>>>>> Regarding service header flexibility, I completely agree. I >>>>>>> might >>>>>>> >>>>>> suggest a compromise between hardware friendliness and software >>>>> flexibility. If the header had the ability to add extensions >>>>> (perhaps similar to IPv6) but also had the header length encoded in >>>>> the mandatory part (like IPv4), then a hardware implementation would >>>>> be free to skip over the extensions (in cases where the deployment >>>>> justifies ignoring the extensions). >>>>> >>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>> [mailto:S.Majee@F5.com] Sent: Wednesday, February 12, 2014 >>>>>>> 3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern; >>>>>>> sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>> >>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>>>> header that is independent of the transport methodology. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I agree. However the format of service header should be >>>>>>> standardized in >>>>>>> >>>>>> a way that is flexible. Some of us would like to see variable length >>>>> header that is also HW friendly. The service header can be >>>>> represented as a mandotory fixed length header (like IP >>>>> header) along with an optional variable length attribute field. >>>>> Different services can be interested in different metadata, for >>>>> example subscriber ID could be of interest in the mobile core >>>>> service chain only. >>>>> >>>>>> >>>>>>> Sumandra >>>>>>> >>>>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>>>> >>>>>>> >>>>>> wrote: >>>>> >>>>>> >>>>>>> Linda, >>>>>>>> >>>>>>>> My interpretation of the architecture docs is that the service >>>>>>>> function chain is built in an abstract manner (i.e., SF-A then >>>>>>>> SF-B >>>>>>>> >>>>>>> then SF-C). >>>>> >>>>>> Separately, a locator table provides network location for >>>>>>>> each of those service functions. In this way, you can >>>>>>>> locate the service functions >>>>>>>> >>>>>>> in >>>>> >>>>>> a manner appropriate to the type of transport you are >>>>>>>> using. If you want that to be interface+VLAN, >>>>>>>> gateway-IP+MPLS label stack, IP >>>>>>>> >>>>>>> address, >>>>> >>>>>> GRE tunnel remote IP + key, etc., you can do that. You >>>>>>>> can even potentially locate different service functions that >>>>>>>> reside in the same chain with different flavors of >>>>>>>> network locators. Another justification to separate the >>>>>>>> identity of a service function from its network location is >>>>>>>> load balancing. If, for example, SF-A had 3 IP addresses, >>>>>>>> that would imply load balancing to 3 instances using IP as a >>>>>>>> transport layer. >>>>>>>> >>>>>>>> For all of those reasons, I strongly support a canonical service >>>>>>>> header that is independent of the transport >>>>>>>> methodology. At a particular node, the decision as to >>>>>>>> where to go next should be based solely on information carried in >>>>>>>> the canonical service header and not on the >>>>>>>> >>>>>>> fields >>>>> >>>>>> in the transport header. That is, the SFC node discards >>>>>>>> the transport header and extracts the chain ID from the >>>>>>>> service header. Through mechanisms we have not yet begun >>>>>>>> to discuss, the SFC node knows how to interpret the chain ID and >>>>>>>> ultimately how to progress the packet. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >>>>>>>> Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M. >>>>>>>> Halpern; sfc@ietf.org Subject: Re: [sfc] Framework >>>>>>>> >>>>>>>> Agree with Joel's statement. >>>>>>>> >>>>>>>> I think a simple sentence below should be added Section 5.2 (SFC >>>>>>>> Classifier) to emphasize this point. >>>>>>>> >>>>>>>> "A Service Chain Classifier node can associate a unique Layer 2 >>>>>>>> or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow. >>>>>>>> Those Layer 2 or 3 Label makes it easier for subsequent nodes >>>>>>>> along the flow path to steer the flow to the service functions >>>>>>>> specified by the flow's service chain." >>>>>>>> >>>>>>>> >>>>>>>> Linda -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>> Sent: Wednesday, February 12, 2014 10:20 AM To: >>>>>>>> sfc@ietf.org Subject: [sfc] Framework >>>>>>>> >>>>>>>> I was looking at the framework proposal. The proposal has a very >>>>>>>> specific model of the scope of the transport header (that it is >>>>>>>> derived from, and relates only to, the first service function to >>>>>>>> which the packet will be directed. That is clearly an operational >>>>>>>> model we need to support. >>>>>>>> >>>>>>>> However, I would like to allow other transport operational >>>>>>>> models, such as the use of a VLAN to direct traffic along a >>>>>>>> chain. Or the use of an MPLS label, or an MPLS label stack. >>>>>>>> >>>>>>>> Yours, Joel M. Halpern >>>>>>>> >>>>>>>> _______________________________________________ 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 >>>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>>>> >>>> >>>> >>> >> _______________________________________________ >> 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 > --089e01294232d2de8904f24e01d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are ways to signal variable length amounts of metada= ta without needing an additional variable-length header on each data packet= .

draft-rijsman-sfc-metadata-considerations-00 discusses= some of the possible approaches: out-of-band signaling (congruent or non-c= ongruent) or a hybrid approach using a fix-length in-band correlator and ou= t-of-band additional metadata. =A0See sections 3.3, 3.4 and 3.5 in the draf= t. =A0

The issue of fixed-length encoding versus variabl= e length encoding is discussion in the challenges chapter in section 4.3. = =A0I should probably mention the MTU and segmentation issues as well in tha= t section.


On Thu,= Feb 13, 2014 at 1:16 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
The variable length shim header is needed ev= en if every individual piece of metadata has a fixed length. =A0Different s= ervice chains will need different combinations of metadata. =A0So the metad= ata portion of the header needs to be variable length.

I think the approach of a fixed length initial part, and a variable length = extension part, is the right model.

Yours,
Joel


On 2/13/14, 11:13 AM, Jerome Moisand wrote:
Yes, fragmentation and variable headers are usually a really bad thing for = forwarding performance. Let's not forget that we live in a 100G-ish kin= d of world nowadays.

Now the question should be: WHY would we want to do that (variable headers = leading to fragmentation issues)?

For example, the type of metadata that may require variable-length fields m= ight be a better candidate for some out-of-band signaling mechanism. If thi= s is service authorization data (e.g. a service profile/policy), this sound= s likely. Not 100% sure this is true for all use cases though. Only a good = understanding of use cases, grounded by reflecting on existing network arch= itectures (notably broadband, fixed or mobile), would tell us if one approa= ch or another is the most appropriate.

Anyhoo, we're jumping way deep in the detailed protocol design here. Th= is seems a tad premature.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, February 13, 2014 11:03 AM
To: 'jmh@joelh= alpern.com'; 'Ron_Parker@affirmednetworks.com'; '<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com'; 'Nicolas.BOUTHORS@qosmos.com'; '<= a href=3D"mailto:paulq@cisco.com" target=3D"_blank">paulq@cisco.com'= ;
Cc: 'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com'
Subject: Re: [sfc] Framework

it is overall more efficient to support PMTU discovery rather than fragment= ing every large packet. The is why TCP adopted it so early on.

The fragmenting also puts huge performance burden on the service functions.=
Fragmenting may also affect the ability of load balancers to get each fragm= ent to the correct destination.

So PMTU discovery SHOULD be used, in my opinion. By this I mean the client = or server is informed that its packets are too big (for IPv6 or IPv4 with D= F=3D1).

Some operators may wish to incur the extra cost to hide the existence of th= e tunneling, when the elements of the chain can support it, so we could con= sider that as an optional mechanism.

-Dave


----- Original Message -----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, February 13, 2014 10:31 AM
To: Ron Parker <Ron_Parker@affirmednetworks.com>; mohamed.boucadair@orang= e.com <mohamed.boucadair@orange.com>; Dave Dolson; 'Nicolas.BOUTHORS@= qosmos.com' <Nicolas.BOUTHORS@qosmos.com>; 'paulq@cisco.com' <paulq@cisco.com>
Cc: 'S.Majee@F5.com' <S.Majee@F5.com>; 'sfc@ietf.org' <sfc@ietf.org>; 'linda.dunbar@huawei.com&= #39; <linda= .dunbar@huawei.com>
Subject: Re: [sfc] Framework

I mostly agree with you Ron. =A0I can probably come up with some other vari= ations, but your second point is that the transport must deal with the issu= e of frame size / fit.

I would note that if we assume that the carrying encaps (IPv4/v6 outer) is = being fragmented, then we are assuming that the exit from service chaining = can and will reassemble.

Yours,
Joel

On 2/13/14, 10:18 AM, Ron Parker wrote:
Joel,

That is an excellent point to consider when choosing transport
encapsulations. =A0 If the transport encapsulation is IPv4 or IPv6
based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, etc.), then
fragmentation and defragmentation are naturally supported. =A0 =A0If the transport encapsulation is VLAN, MPLS, etc., then I believe one of the
following must be true:

* The end-to-end path is known to support the resulting larger frames
* A path discovery mechanism is mandated by SFC when non-IP transports
are used * An SFC-specific fragmentation header and mechanisms must be
defined (i.e.,
SFC-transport/SFC-fragmentation/SFC-service/original-packet-o= r-frame)

=A0 Ron


-----Original Message----- From: Joel M. Halpern
[mailto:jmh@joelha= lpern.com] Sent: Thursday, February 13, 2014 10:10
AM To: mo= hamed.boucadair@orange.com; Dave Dolson;
'Nicol= as.BOUTHORS@qosmos.com'; Ron Parker; 'paulq@cisco.com' Cc:
'S.Majee@F5.com'; 'sfc@ietf.org'; 'linda.dunbar@huawei.com' Subject:
Re: [sfc] Framework

There is a related complexity. I hope that we expect to support IPv6.
IPv6 explicitly prohibits network elements from fragmenting end user
packets.

Yours, Joel

On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com wrote:
Re-,

FWIW, one of the existing architecture drafts includes the following
behavior
(http://tools.ietf.org/html/draft-boucadair= -sfc-framework-02#section-6):



"
6. Fragmentation Considerations

If adding the Service Chaining Header would result in a fragmented
packet, the classifier should include a Service Chaining Header in
each fragment. =A0Doing so would prevent SF Nodes to dedicate resource
to handle fragments. "

Cheers, Med


-----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org]
De la part de Dave Dolson Envoy=E9 :
jeudi 13 f=E9vrier 2014 13:39 =C0 : 'Nicolas.BOUTHORS@qosmos.com';
'R= on_Parker@affirmednetworks.com'; 'jmh@joelhalpern.com';
'paulq@cisco.com' Cc : 'S.Majee@F5.com'; 'sfc@ietf.org';
'linda.dun= bar@huawei.com' Objet : Re: [sfc] Framework

Good point to consider fragmentation.

We should design the encapsulation such that the forwarding
functions do not need to reassemble. Each fragment should be
independently forwardable; some SFs may choose to ignore these
packets.

Any layer 2.5 protocol like VLAN or MPLS would support this.
Otherwise, a reassembly layer could be added after the forwarding
coordinates. Think of something like the IPv6 reassembly option
after a GRE header, for instance.

IP | GRE | reassem | frag data

We could alternatively mandate the inner IP be fragmented and that
path-MTU discovery be supported.




----- Original Message ----- From: Nicolas BOUTHORS
[mailto:Ni= colas.BOUTHORS@qosmos.com] Sent: Thursday, February 13,
2014 04:13 AM To: Ron Parker <Ron_Parker@affirmednetworks.com>;<= br> Dave Dolson; Joel M. Halpern <jmh@joelhalpern.com>; Paul Quinn
(paulq) <paulq@cisc= o.com> Cc: Sumandra Majee <S.Majee@F5.com>;
sfc@ietf.org <sfc@ietf.org>; Linda D= unbar <lind= a.dunbar@huawei.com>
Subject: Re: [sfc] Framework

If we do not enforce a fix header size we have other implication.

There is the question of segmentation and reassembly responsibility
as well.

If adding length to the service header forces segmentation, then
whose responsibility is it to reassemble the payload before passing
it to the SF.

Similar question for packet re-ordering.


________________________________________ From: Ron Parker
[Ron_P= arker@affirmednetworks.com] Sent: Wednesday, February 12,
2014 11:25 PM To: Dave Dolson; Joel M. Halpern; Paul Quinn
(paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar Subject:
Re: [sfc] Framework

Dave,

Yes, that is a good point if we logically separate the forwarding
function from the SFC-aware service function, as we should. =A0 The
forwarding function is concerned with only the inbound transport
header, the fixed =A0portion of the service header containing the
chain information, and the outbound transport header. =A0 =A0The
service function may look at the entirety of the service header and
would look at the encapsulated packet.

Ron


-----Original Message----- From: Dave Dolson
[mailto:ddolson@s= andvine.com] Sent: Wednesday, February 12, 2014
5:18 PM To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq) Cc:
Sumandra Majee; sfc@ietf.= org; Linda Dunbar Subject: RE: [sfc]
Framework

The forwarding plane might not even need to look at the encapsulated
packet.

For example, (if the SF Identifier is a VLAN tag), an Ethernet
switch can forward packets of the form: =A0Ether | VLAN | BLOB.



-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Joel M. Halpern Sent:
Wednesday, February 12, 2014 4:30 PM To: Ron Parker; Dave Dolson;
Paul Quinn (paulq) Cc: Sumandra Majee; sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc] Framework

I agree as well. Yours, Joel

On 2/12/14, 4:24 PM, Ron Parker wrote:
Hi, Dave.

I =A0Agree with your statement. =A0 =A0And if the total length of the
header is
contained in the mandatory portion, the hardware implementation can
easily locate the encapsulated packet.

Ron


-----Original Message----- From: Dave Dolson
[mailto:ddolson@s= andvine.com] Sent: Wednesday, February 12,
2014 4:10 PM To: Ron Parker; Paul Quinn (paulq) Cc: Joel M.
Halpern; Sumandra Majee; = sfc@ietf.org; Linda Dunbar Subject:
RE: [sfc] Framework

I think a good approach would be:

The information required for forwarding (the SF Identifier) should
be in
a mandatory fixed-size header.

Optional information (if any) is NOT to be used for forwarding, but
is
for consumption by one or more of the applications in the chain.

Then the forwarding plane, and even the PDP, can be agnostic about
the
meta-data.

-Dave


-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Ron Parker Sent:
Wednesday, February 12, 2014 4:05 PM To: Paul Quinn (paulq) Cc:
Joel M. Halpern; Sumandra Majee; sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc] Framework

Paul,

That is why I am proposing a hybrid where extensions or options can
be
added but the total length is contained in the fixed portion. =A0 I
can envision certain deployments (e.g., Enterprise) where perhaps
extensions are not needed and the SFC functionality is realized
in hardware. =A0 And, I can envision certain other deployments
(e.g., 3gpp) where the extension headers add sufficient value to
justify software based implementations.

Ron


-----Original Message----- From: Paul Quinn (paulq)
[mailto:paulq@cisco.co= m] Sent: Wednesday, February 12, 2014
3:40 PM To: Ron Parker Cc: Sumandra Majee; Linda Dunbar; Joel M.
Halpern; sfc@ietf.org= Subject: Re: [sfc] Framework

Hi,

We certainly need to be very careful with variable length headers
when
hardware platform are in play.

Ron, your examples of IP options and v6 EH have both suffered from
significant implementation and deployment hurdles due to the
complexity and cost associated with hardware support for the
option/EH.

Paul

On Feb 12, 2014, at 3:10 PM, Ron Parker
<Ro= n_Parker@affirmednetworks.com>
wrote:

Hi, Sumandra.

Regarding service header flexibility, I completely agree. =A0 I
might
suggest a compromise between hardware friendliness and software
flexibility. =A0 =A0If the header had the ability to add extensions
(perhaps similar to IPv6) but also had the header length encoded in
the mandatory part (like IPv4), then a hardware implementation would
be free to skip over the extensions (in cases where the deployment
justifies ignoring the extensions).

Ron


-----Original Message----- From: Sumandra Majee
[mailto:S.Majee@F5.com<= /a>] Sent: Wednesday, February 12, 2014
3:04 PM To: Ron Parker; Linda Dunbar; Joel M. Halpern;
sfc@ietf.org Subject:= Re: [sfc] Framework

For all of those reasons, I strongly support a canonical service
header that is independent of the transport methodology.


I agree. However the format of service header should be
standardized in
a way that is flexible. Some of us would like to see variable length
header that is also HW friendly. The service header can be
represented as a mandotory fixed length header (like IP
header) along with an optional variable length attribute field.
Different services can be interested in different metadata, for
example subscriber ID could be of interest in the mobile core
service chain only.

Sumandra

On 2/12/14, 11:32 AM, "Ron Parker"
<Ro= n_Parker@affirmednetworks.com>
wrote:

Linda,

My interpretation of the architecture docs is that the service
function chain is built in an abstract manner (i.e., SF-A then
SF-B
then SF-C).
Separately, a locator table provides network location for
each of those service functions. =A0 In this way, you can
locate the service functions
in
a manner appropriate to the type of transport you are
using. =A0 If you want that to be interface+VLAN,
gateway-IP+MPLS label stack, IP
address,
GRE tunnel remote IP + key, etc., you can do that. =A0 =A0You
can even potentially locate different service functions that
reside in the same chain with different flavors of
network locators. =A0 =A0Another justification to separate the
identity of a service function from its network location is
load balancing. =A0 If, for example, SF-A had 3 IP addresses,
that would imply load balancing to 3 instances using IP as a
transport layer.

For all of those reasons, I strongly support a canonical service
header that is independent of the transport
methodology. =A0 =A0At a particular node, the decision as to
where to go next should be based solely on information carried in
the canonical service header and not on the
fields
in the transport header. =A0 That is, the SFC node discards
the transport header and extracts the chain ID from the
service header. =A0 =A0Through mechanisms we have not yet begun
to discuss, the SFC node knows how to interpret the chain ID and
ultimately how to progress the packet.

Ron


-----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, February 12, 2014 12:01 PM To: Joel M.
Halpern; sfc@ietf.org= Subject: Re: [sfc] Framework

Agree with Joel's statement.

I think a simple sentence below should be added Section 5.2 (SFC
Classifier) to emphasize this point.

"A Service Chain Classifier node can associate a unique Layer 2
or 3 Label (e.g. VLAN, MPLS label) to the packets in the flow.
Those Layer 2 or 3 Label makes it easier for subsequent nodes
along the flow path to steer the flow to the service functions
specified by the flow's service chain."


Linda -----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 12, 2014 10:20 AM To:
sfc@ietf.org Subject:= [sfc] Framework

I was looking at the framework proposal. The proposal has a very
specific model of the scope of the transport header (that it is
derived from, and relates only to, the first service function to
which the packet will be directed. That is clearly an operational
model we need to support.

However, I would like to allow other transport operational
models, such as the use of a VLAN to direct traffic along a
chain. =A0Or the use of an MPLS label, or an MPLS label stack.

Yours, Joel M. Halpern

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc


_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc



_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc



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





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

--089e01294232d2de8904f24e01d4-- From nobody Fri Feb 14 05:42:45 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8AC1A0217 for ; Fri, 14 Feb 2014 05:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quofg4TDsIqQ for ; Fri, 14 Feb 2014 05:42:42 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 357F41A0218 for ; Fri, 14 Feb 2014 05:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1307; q=dns/txt; s=iport; t=1392385361; x=1393594961; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Pklx2AMj98KpV0Ff6Fyton4BmVMaYbdTpFq+Qtq5hEY=; b=biifLomWPnSIsHfyK99abCb+kGJoZIxf5xoRwaq6geun7S8iaEC2RuzY Mq2beOifu+D42vhmTb1j85C8lbTTNeTzSsC9hHSbxQWgQP1nhDoVoOiqC VTet4pXFsmqZ7u8twYBec+zzIL+RPEydLRWwls8dJvMCaqDUm4+A8g9TR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAAgc/lKtJXG+/2dsb2JhbABZgwY4UQbARhZ0giUBAQEDATo9BwsCAT4QMhsKAgQch3QICAXJEheSJIEUBJgsgTKQcYMtgio X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="20463826" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 14 Feb 2014 13:42:40 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1EDgeJn006988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 13:42:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 07:42:40 -0600 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-nsh-01.txt Thread-Index: AQHPKQtxF9lk9dollky0jAJfa0Whug== Date: Fri, 14 Feb 2014 13:42:39 +0000 Message-ID: <202AA27C-0605-4729-89B1-7366AD3B1449@cisco.com> References: <20140213223210.8255.90935.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="us-ascii" Content-ID: <97D55AC3A8FDE149A7FF12B727C7695A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OjJ7oxllNlLJ98ejsVlMGQ8ZSuw Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-nsh-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, 14 Feb 2014 13:42:44 -0000 SFCers, We submitted a new version of the draft-quinn-sfc-nsh yesterday. This draf= t updates the base header format, and incorporates comments from reviewers. We welcome your comments, and suggestions! Thanks Paul > A new version of I-D, draft-quinn-sfc-nsh-01.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-quinn-sfc-nsh > Revision: 01 > Title: Network Service Header > Document date: 2014-02-13 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-nsh-0= 1.txt > Status: https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-nsh-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-nsh-01 >=20 > Abstract: > This draft describes a Network Service Header (NSH) added to > encapsulated packets or frames to realize service function paths. > NSH also provides a mechanism for metadata exchange along the > instantiated service path. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Feb 14 05:44:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3551A0218 for ; Fri, 14 Feb 2014 05:44:38 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n-XLgbvvY6i for ; Fri, 14 Feb 2014 05:44:33 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6C51A0217 for ; Fri, 14 Feb 2014 05:44:33 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 05:44:31 -0800 From: Ron Parker To: Nicolas BOUTHORS , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Sg2Ayd84yH0WUHw67lVJO2JqyXfUA//+hziCAAJFagP//euxwgACPGgD//4A48AARBvCAABBNRgD//4NNgIAADUiAgACFeFCAADG0gIAAOXoAgAALywCAAB5PgIAAheoA//+ADwCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAcmAgAABywCAAAR+gIAAEKYAgAA6AACAAAHDAIAAhU8ggAABhoCAAC4U4A== Date: Fri, 14 Feb 2014 13:44:30 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com>, <76B41B8FACE1514795D30EC137FF391D3E5408@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D3E5408@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pqbhbApBb3KwdnSYJ_VOJTbU7Bk Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:44:38 -0000 Nicolas, By transparent, I meant solely that it is not addressed by the endpoints of= the communication. I did not intend to mean that it didn't change the pa= ckets or flows. Perhaps I should have said simply midboxes to mean this. Ron -----Original Message----- From: Nicolas BOUTHORS [mailto:Nicolas.BOUTHORS@qosmos.com]=20 Sent: Friday, February 14, 2014 3:28 AM To: Ron Parker; sfc@ietf.org Subject: RE: [sfc] Framework Hello Ron, I agree on your statement that Metadata is beyond that required for proper = steering, given we have addressable applications or transparent mid-boxes. What about Transparent proxies, used for header insertion? They are not exp= licitly addresses and are not transparent middle boxes as they terminate a = tcp connection on one side, and create one on the other. They are quite common and they should be address via ad'hoc mechanisms as y= ou pointed out in a previous message, similarly to the issue of revealing H= ost Id discussed in RFC 6967.=20 I am just concerned to keep them in scope of what sfc should cover. Nicolas ________________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Friday, February 14, 2014 1:33 AM To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework Linda, Also, let's please separate "applications" and "service functions". I vie= w "applications" as things that are explicitly addressed, like an Apache Se= rver that realizes some web service -- no SFC steering was necessary to cau= se packets to reach it. "Service functions", on the other hand and purel= y from an SFC perspective, are transparent mid-boxes that would not have no= rmally been part of the data path unless special steering mechanisms were a= pplied or certain forced topologies were present in the network. Metadat= a, for SFC, is information above and beyond that required for proper steeri= ng that is passed amongst and between the SFC classifier(s) and the SFC ser= vice functions. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 7:25 PM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework I only consider the first of those to be metadata. The chain identificatio= n in the service chaining header or the transport header are not metadata. = Treating fields which are needed for steering as metadata induces massive = confusion. can we please keep those two concepts separate?! Yours, Joel On 2/13/14, 7:18 PM, Linda Dunbar wrote: > > I see two types of "metadata" being discussed here: > > 1. The "flow metadata", like the transactions carried by http flows. > They are inserted by applications, or inserted by a service function=20 > to pass some "cookies" to the next one. (many proxy based service=20 > functions have those capability) > > 2. The "Service Chain metadata", that are inserted by "Chain Classifier= " or control plane to carry extra information (in additional to Chain ID) f= or the purpose of controlling the sequence of functions on a chain. > > Correct? > > IMHO, the first bullet above are specific to applications or service func= tions internal processing. Many of today's proxy based service functions ma= ke changes to data packets, some of them make those changes for other servi= ce functions. Those changes won't be in the Service Chain Header field. > > Linda > > > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 2:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not address= the majority of requirement. Also a typical http flow carries many transac= tions and each can have different or additional classification. So a metada= ta can not be simple connected with one flow either. Current implementation= s of proxies and load balancers has addressed this in many ways including c= ustome header insertion. The custom header in this case equivalent of metad= ata vector. > > I think we need an efficient way annotate actual data with inline=20 > metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 > [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short ide= ntifier, and using it to select the desired behavior that has been pre-popu= lated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for out-of-ban= d metadata. > > However, claiming that a single such correlator is all that is needed for= even 80% of SFC cases (and I very much supporting trying to focus on the 8= 0% cases), just does not seem to work, given the broad range of requirement= s that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: >> Joel, >> >> Protocols like GTP and L2TP work exactly that, with a form of session co= rrelator between the data plane and the control plane. This is very handy f= or subscriber and service management. Also if a correlator is defined as an= opaque and unique number, then one can avoid some of the pitfalls you desc= ribed. Long-lived metadata is clearly useful (and thanks for sharing, Reina= ldo, will read), and there is clear applicability to various service chaini= ng needs. >> >> Now this is just one way. The I-D Bruno referred to was just listing thi= s approach as one possible way among others. I totally agree with you that = other forms of metadata (like an outcome of the classification of a packet = or a sequence of a few packets) may not be suitable for out-of-band signali= ng. >> >> Bottomline seems to be that we have too many options to choose from, and= none of them solving it all... Tough. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 13, 2014 2:29 PM >> To: sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> As I understand it, the tsvwg (and aeon) work is about flow metadata. >> That is long-lived metadata of use across many packets. That does indee= d seem well-suited to out-of-band cases. >> >> My concern is that in SFC, there are many cases which are at best badly-= addressed if we insist that they be solved using out-of-band metadata. >> >> Yours, >> Joel >> >> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>> There is draft about transport independent metadata. >>> >>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodin >>> g >>> - >>> 01 >>> >>> The complexities you mention are discussed there: variable-encoding,=20 >>> direction, security of metadata, etc. >>> >>> Thanks, >>> >>> -RP >>> >>> >>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>> >>>> While there are cases where out-of-band metadata makes sense, There=20 >>>> are many cases I would not want to try to cover that way. The best=20 >>>> examples are situations where the metadata changes from packet to=20 >>>> packet (such as the data produced by a DPI engine for consumption=20 >>>> by other applications in the chain.) >>>> >>>> More importantly, if you are putting correlators in the packet, it=20 >>>> is still very complex if you want to use one correlator to handle=20 >>>> metadata produced by several different entities (the initial=20 >>>> classifer, the DPI engine, ...) You quickly end up deciding that=20 >>>> you need several correlators. At which point we are back to variable = amounts of metadata. >>>> >>>> The alternative is to require exceedingly specific and strong=20 >>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>> be a very bad idea. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>> resend to avoid "too many recipients" warning >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>> > wrote: >>>>> >>>>> There are ways to signal variable length amounts of metadata w= ithout >>>>> needing an additional variable-length header on each data pack= et. >>>>> >>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of= the >>>>> possible approaches: out-of-band signaling (congruent or >>>>> non-congruent) or a hybrid approach using a fix-length in-band >>>>> correlator and out-of-band additional metadata. See sections = 3.3, >>>>> 3.4 and 3.5 in the draft. >>>>> >>>>> The issue of fixed-length encoding versus variable length enco= ding >>>>> is discussion in the challenges chapter in section 4.3. I sho= uld >>>>> probably mention the MTU and segmentation issues as well in th= at >>>>> section. >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> The variable length shim header is needed even if every >>>>> individual piece of metadata has a fixed length. Differen= t >>>>> service chains will need different combinations of metadat= a. So >>>>> the metadata portion of the header needs to be variable le= ngth. >>>>> >>>>> I think the approach of a fixed length initial part, and a >>>>> variable length extension part, is the right model. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>> >>>>> Yes, fragmentation and variable headers are usually a = really >>>>> bad thing for forwarding performance. Let's not forget= that >>>>> we live in a 100G-ish kind of world nowadays. >>>>> >>>>> Now the question should be: WHY would we want to do th= at >>>>> (variable headers leading to fragmentation issues)? >>>>> >>>>> For example, the type of metadata that may require >>>>> variable-length fields might be a better candidate for= some >>>>> out-of-band signaling mechanism. If this is service >>>>> authorization data (e.g. a service profile/policy), th= is >>>>> sounds likely. Not 100% sure this is true for all use = cases >>>>> though. Only a good understanding of use cases, ground= ed by >>>>> reflecting on existing network architectures (notably >>>>> broadband, fixed or mobile), would tell us if one appr= oach >>>>> or another is the most appropriate. >>>>> >>>>> Anyhoo, we're jumping way deep in the detailed protoco= l >>>>> design here. This seems a tad premature. >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>> ] On Behalf Of Dave Dolso= n >>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>> To: 'jmh@joelhalpern.com '= ; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'mohamed.boucadair@orange.com >>>>> '__; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; 'paulq@cisco.co= m >>>>> ' >>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com ' >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> it is overall more efficient to support PMTU discovery >>>>> rather than fragmenting every large packet. The is why= TCP >>>>> adopted it so early on. >>>>> >>>>> The fragmenting also puts huge performance burden on t= he >>>>> service functions. >>>>> Fragmenting may also affect the ability of load balanc= ers to >>>>> get each fragment to the correct destination. >>>>> >>>>> So PMTU discovery SHOULD be used, in my opinion. By th= is I >>>>> mean the client or server is informed that its packets= are >>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>> >>>>> Some operators may wish to incur the extra cost to hid= e the >>>>> existence of the tunneling, when the elements of the c= hain >>>>> can support it, so we could consider that as an option= al >>>>> mechanism. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>> ] >>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>> To: Ron Parker >>>> >; >>>>> mohamed.boucadair@orange.com >>>>> >>>>> >>>> >__; Dave Dolson; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> ' >>>>> >>>> >; 'paulq@cisco.co= m >>>>> ' >>>> > >>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>> ' >; >>>>> 'linda.dunbar@huawei.com ' >>>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I mostly agree with you Ron. I can probably come up w= ith >>>>> some other variations, but your second point is that t= he >>>>> transport must deal with the issue of frame size / fit= . >>>>> >>>>> I would note that if we assume that the carrying encap= s >>>>> (IPv4/v6 outer) is being fragmented, then we are assum= ing >>>>> that the exit from service chaining can and will reass= emble. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>> >>>>> Joel, >>>>> >>>>> That is an excellent point to consider when choosi= ng >>>>> transport >>>>> encapsulations. If the transport encapsulation i= s IPv4 >>>>> or IPv6 >>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>>>> etc.), then >>>>> fragmentation and defragmentation are naturally >>>>> supported. If the >>>>> transport encapsulation is VLAN, MPLS, etc., then = I >>>>> believe one of the >>>>> following must be true: >>>>> >>>>> * The end-to-end path is known to support the resu= lting >>>>> larger frames >>>>> * A path discovery mechanism is mandated by SFC wh= en >>>>> non-IP transports >>>>> are used * An SFC-specific fragmentation header an= d >>>>> mechanisms must be >>>>> defined (i.e., >>>>> >>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or >>>>> - >>>>> f >>>>> rame) >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Joel M. Halpern >>>>> [mailto:jmh@joelhalpern.com >>>>> ] Sent: Thursday, Febr= uary >>>>> 13, 2014 10:10 >>>>> AM To: mohamed.boucadair@orange.com >>>>> ; Dave Dolson= ; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; Ron Parker; >>>>> 'paulq@cisco.com ' Cc: >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> There is a related complexity. I hope that we expe= ct to >>>>> support IPv6. >>>>> IPv6 explicitly prohibits network elements from >>>>> fragmenting end user >>>>> packets. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>> wrote: >>>>> >>>>> Re-, >>>>> >>>>> FWIW, one of the existing architecture drafts >>>>> includes the following >>>>> behavior >>>>> >>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#s >>>>> e >>>>> c >>>>> tion- >>>>> 6 >>>>> >>>>> ): >>>>> >>>>> >>>>> >>>>> " >>>>> >>>>> 6. Fragmentation Considerations >>>>> >>>>> If adding the Service Chaining Header would re= sult >>>>> in a fragmented >>>>> packet, the classifier should include a Servic= e >>>>> Chaining Header in >>>>> each fragment. Doing so would prevent SF Node= s to >>>>> dedicate resource >>>>> to handle fragments. " >>>>> >>>>> Cheers, Med >>>>> >>>>> >>>>> -----Message d'origine----- De : sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> De la part de Dave Dolson Envoy=E9 : >>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'jmh@joelhalpern.com=20 >>>>> '; >>>>> 'paulq@cisco.com '= Cc : >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>> '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Objet : = Re: >>>>> [sfc] Framework >>>>> >>>>> Good point to consider fragmentation. >>>>> >>>>> We should design the encapsulation such th= at the >>>>> forwarding >>>>> functions do not need to reassemble. Each >>>>> fragment should be >>>>> independently forwardable; some SFs may ch= oose >>>>> to ignore these >>>>> packets. >>>>> >>>>> Any layer 2.5 protocol like VLAN or MPLS w= ould >>>>> support this. >>>>> Otherwise, a reassembly layer could be add= ed >>>>> after the forwarding >>>>> coordinates. Think of something like the I= Pv6 >>>>> reassembly option >>>>> after a GRE header, for instance. >>>>> >>>>> IP | GRE | reassem | frag data >>>>> >>>>> We could alternatively mandate the inner I= P be >>>>> fragmented and that >>>>> path-MTU discovery be supported. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: >>>>> Nicolas BOUTHORS >>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>> ] Sent= : >>>>> Thursday, February 13, >>>>> 2014 04:13 AM To: Ron Parker >>>>> >>>> >; >>>>> Dave Dolson; Joel M. Halpern >>>>> >>>> >; Paul Quinn >>>>> (paulq) >>>> > Cc: Sumandra Maj= ee >>>>> ; >>>>> sfc@ietf.org >>>> >; Linda Dunbar >>>>> >>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> If we do not enforce a fix header size we = have >>>>> other implication. >>>>> >>>>> There is the question of segmentation and >>>>> reassembly responsibility >>>>> as well. >>>>> >>>>> If adding length to the service header for= ces >>>>> segmentation, then >>>>> whose responsibility is it to reassemble t= he >>>>> payload before passing >>>>> it to the SF. >>>>> >>>>> Similar question for packet re-ordering. >>>>> >>>>> >>>>> __________________________________________= From: >>>>> Ron Parker >>>>> [Ron_Parker@affirmednetworks.__com >>>>> ] = Sent: >>>>> Wednesday, February 12, >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Hal= pern; >>>>> Paul Quinn >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: >>>>> Re: [sfc] Framework >>>>> >>>>> Dave, >>>>> >>>>> Yes, that is a good point if we logically >>>>> separate the forwarding >>>>> function from the SFC-aware service functi= on, as >>>>> we should. The >>>>> forwarding function is concerned with only= the >>>>> inbound transport >>>>> header, the fixed portion of the service = header >>>>> containing the >>>>> chain information, and the outbound transp= ort >>>>> header. The >>>>> service function may look at the entirety = of the >>>>> service header and >>>>> would look at the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dols= on >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: Wedne= sday, >>>>> February 12, 2014 >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; P= aul >>>>> Quinn (paulq) Cc: >>>>> Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: RE: >>>>> [sfc] >>>>> Framework >>>>> >>>>> The forwarding plane might not even need t= o look >>>>> at the encapsulated >>>>> packet. >>>>> >>>>> For example, (if the SF Identifier is a VL= AN >>>>> tag), an Ethernet >>>>> switch can forward packets of the form: E= ther | >>>>> VLAN | BLOB. >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Joel M. Halpern Sent: >>>>> Wednesday, February 12, 2014 4:30 PM To: R= on >>>>> Parker; Dave Dolson; >>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>> sfc@ietf.org ; Linda = Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I agree as well. Yours, Joel >>>>> >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> >>>>> Hi, Dave. >>>>> >>>>> I Agree with your statement. And i= f the >>>>> total length of the >>>>> header is >>>>> >>>>> contained in the mandatory portion, the ha= rdware >>>>> implementation can >>>>> easily locate the encapsulated packet. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave = Dolson >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: >>>>> Wednesday, February 12, >>>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n >>>>> (paulq) Cc: Joel M. >>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Su= bject: >>>>> RE: [sfc] Framework >>>>> >>>>> I think a good approach would be: >>>>> >>>>> The information required for forwardin= g (the >>>>> SF Identifier) should >>>>> be in >>>>> >>>>> a mandatory fixed-size header. >>>>> >>>>> >>>>> Optional information (if any) is NOT t= o be >>>>> used for forwarding, but >>>>> is >>>>> >>>>> for consumption by one or more of the >>>>> applications in the chain. >>>>> >>>>> >>>>> Then the forwarding plane, and even th= e PDP, >>>>> can be agnostic about >>>>> the >>>>> >>>>> meta-data. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Ron Parker Sent: >>>>> Wednesday, February 12, 2014 4:05 PM T= o: >>>>> Paul Quinn (paulq) Cc: >>>>> Joel M. Halpern; Sumandra Majee; >>>>> sfc@ietf.org ;=20 >>>>> Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Paul, >>>>> >>>>> That is why I am proposing a hybrid wh= ere >>>>> extensions or options can >>>>> be >>>>> >>>>> added but the total length is contained in= the >>>>> fixed portion. I >>>>> can envision certain deployments (e.g., >>>>> Enterprise) where perhaps >>>>> extensions are not needed and the SFC >>>>> functionality is realized >>>>> in hardware. And, I can envision certain= other >>>>> deployments >>>>> (e.g., 3gpp) where the extension headers a= dd >>>>> sufficient value to >>>>> justify software based implementations. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Paul = Quinn >>>>> (paulq) >>>>> [mailto:paulq@cisco.com >>>>> ] Sent: Wednes= day, >>>>> February 12, 2014 >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Ma= jee; >>>>> Linda Dunbar; Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Hi, >>>>> >>>>> We certainly need to be very careful w= ith >>>>> variable length headers >>>>> when >>>>> >>>>> hardware platform are in play. >>>>> >>>>> >>>>> Ron, your examples of IP options and v= 6 EH >>>>> have both suffered from >>>>> >>>>> significant implementation and deployment >>>>> hurdles due to the >>>>> complexity and cost associated with hardwa= re >>>>> support for the >>>>> option/EH. >>>>> >>>>> >>>>> Paul >>>>> >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibili= ty, I >>>>> completely agree. I >>>>> might >>>>> >>>>> suggest a compromise between hardware >>>>> friendliness and software >>>>> flexibility. If the header had the abil= ity to >>>>> add extensions >>>>> (perhaps similar to IPv6) but also had the >>>>> header length encoded in >>>>> the mandatory part (like IPv4), then a har= dware >>>>> implementation would >>>>> be free to skip over the extensions (in ca= ses >>>>> where the deployment >>>>> justifies ignoring the extensions). >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: >>>>> Sumandra Majee >>>>> [mailto:S.Majee@F5.com >>>>> ] Sent: >>>>> Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunb= ar; >>>>> Joel M. Halpern; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> For all of those reasons, = I >>>>> strongly support a=20 >>>>> canonical service >>>>> header that is independent= of >>>>> the transport methodology. >>>>> >>>>> >>>>> >>>>> I agree. However the format of ser= vice >>>>> header should be >>>>> standardized in >>>>> >>>>> a way that is flexible. Some of us would l= ike to >>>>> see variable length >>>>> header that is also HW friendly. The servi= ce >>>>> header can be >>>>> represented as a mandotory fixed length he= ader >>>>> (like IP >>>>> header) along with an optional variable le= ngth >>>>> attribute field. >>>>> Different services can be interested in >>>>> different metadata, for >>>>> example subscriber ID could be of interest= in >>>>> the mobile core >>>>> service chain only. >>>>> >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Linda, >>>>> >>>>> My interpretation of the >>>>> architecture docs is that=20 >>>>> the service >>>>> function chain is built in an >>>>> abstract manner (i.e., SF-A th= en >>>>> SF-B >>>>> >>>>> then SF-C). >>>>> >>>>> Separately, a locator table pr= ovides >>>>> network location for >>>>> each of those service function= s. >>>>> In this way, you can >>>>> locate the service=20 >>>>> functions >>>>> >>>>> in >>>>> >>>>> a manner appropriate to the ty= pe of >>>>> transport you are >>>>> using. If you want that to b= e >>>>> interface+VLAN, >>>>> gateway-IP+MPLS label=20 >>>>> stack, IP >>>>> >>>>> address, >>>>> >>>>> GRE tunnel remote IP + key, et= c., >>>>> you can do that. You >>>>> can even potentially locate >>>>> different service functions th= at >>>>> reside in the same chain with >>>>> different flavors of >>>>> network locators. Another >>>>> justification to separate the >>>>> identity of a service function= from >>>>> its network location is >>>>> load balancing. If, for exam= ple, >>>>> SF-A had 3 IP addresses, >>>>> that would imply load balancin= g to 3 >>>>> instances using IP as a >>>>> transport layer. >>>>> >>>>> For all of those reasons, I st= rongly >>>>> support a canonical service >>>>> header that is independent of = the >>>>> transport >>>>> methodology. At a particula= r >>>>> node, the decision as to >>>>> where to go next should be bas= ed >>>>> solely on information carried = in >>>>> the canonical service header a= nd not >>>>> on the >>>>> >>>>> fields >>>>> >>>>> in the transport header. Tha= t is, >>>>> the SFC node discards >>>>> the transport header and extra= cts >>>>> the chain ID from the >>>>> service header. Through >>>>> mechanisms we have not yet beg= un >>>>> to discuss, the SFC node knows= how >>>>> to interpret the chain ID and >>>>> ultimately how to progress=20 >>>>> the packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- Fro= m: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 12:01 PM To: Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject:= Re: >>>>> [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence belo= w >>>>> should be added Section 5.2 (S= FC >>>>> Classifier) to emphasize this = point. >>>>> >>>>> "A Service Chain Classifier no= de can >>>>> associate a unique Layer 2 >>>>> or 3 Label (e.g. VLAN, MPLS la= bel) >>>>> to the packets in the flow. >>>>> Those Layer 2 or 3 Label makes= it >>>>> easier for subsequent nodes >>>>> along the flow path to steer t= he >>>>> flow to the service functions >>>>> specified by the flow's=20 >>>>> service chain." >>>>> >>>>> >>>>> Linda -----Original Message---= -- >>>>> From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Joel M. Halpern >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 10:20 AM To: >>>>> sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework >>>>> proposal. The proposal has a v= ery >>>>> specific model of the scope of= the >>>>> transport header (that it is >>>>> derived from, and relates only= to, >>>>> the first service function to >>>>> which the packet will be direc= ted. >>>>> That is clearly an operational >>>>> model we need to support. >>>>> >>>>> However, I would like to allow= other >>>>> transport operational >>>>> models, such as the use of a V= LAN to >>>>> direct traffic along a >>>>> chain. Or the use of an MPLS = label, >>>>> or an MPLS label stack. >>>>> >>>>> Yours, Joel M. Halpern >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ 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 >>> >>> >> >> _______________________________________________ >> 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 Fri Feb 14 05:50:26 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372421A0223 for ; Fri, 14 Feb 2014 05:50:25 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZkMEo8iRYL for ; Fri, 14 Feb 2014 05:50:22 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3F1A0222 for ; Fri, 14 Feb 2014 05:50:21 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 05:50:20 -0800 From: Ron Parker To: "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: Ac8ozSirZF8xjnYbSj+erc/EuLq/gAAeGWdwABFavlA= Date: Fri, 14 Feb 2014 13:50:19 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983D73A44@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2983D73A44@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hFnT0ygLtXoi6JFxQnRVFD_y27s Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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, 14 Feb 2014 13:50:25 -0000 Why do we need to pin down the location of the classifier? The classifier= is a logical function that may use out-of-band data, local policy, deliver= ed policy, local state, and the packets, themselves, to intelligently steer= packets through a sequence of midboxes. By keeping the definition high l= evel, implementors can innovate on useful and practical compositions of fun= ctions. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D Sent: Friday, February 14, 2014 12:35 AM To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); sfc@iet= f.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt I support Med's opinion that we should not exclude all existing methods of = classifying flows which include the TDF, DPI, LB, Openflow switch, Grid com= puter, PGw etc. Due to constraint obviously we cannot include all of these candidate method= s in the draft but there is no reason to explicitly remove any of them in t= he draft which have been chosen to be included as examples of typical curre= nt deployments. Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, 14 February 2014 1:51 AM To: Alla Goldner; Liushucheng (Will); sfc@ietf.org Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases= -01.txt Re-, I hear your argument, but the point is we cannot ignore existing deployment= s that are not relying on such functional element. We should reflect both s= ituations IMHO.=20 Cheers, Med >-----Message d'origine----- >De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13 f=E9= vrier >2014 15:43 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases- 01.txt > >Dear Mohamed, > >Thanks a lot for your kind response. > >On the point: >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > >I don't think I agree with such a view. As long as we present=20 >standardized Mobile Network (defined by a different SDO i.e. 3GPP and=20 >not within a scope of IETF) it is very important to reference the=20 >existing well-defined Network Elements. DPI functionality in mobile=20 >network is fulfilled by the TDF. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >agoldner@allot.com www.allot.com > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com=20 >[mailto:mohamed.boucadair@orange.com] >Sent: Thursday, February 13, 2014 4:22 PM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >cases-01.txt > >Re-, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De=A0: Alla Goldner [mailto:agoldner@allot.com] Envoy=E9=A0: jeudi 13=20 >>f=E9vrier >>2014 14:59 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will);=20 >>sfc@ietf.org Objet=A0: RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind consideration of my comment! >> >>I still have 3 comments in this regard: >> >>1. It would be useful to mention within the newly introduced text that=20 >>TDF resides on Gi/SGi interface >[Med] All the functions listed in this section resides in the Gi interface= . >The TDF text is just after a paragraph starting with "Gi Interface=20 >...". We can repeat it also for TDF but we thought it is redundant. > >>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network=20 >>Architecture in order to outline it correctly (Figure 2 and Figure 4); >[Med] As you know there are DPI boxes in operational mobile networks=20 >that are not compliant with 3GPP specifications. Instead of updating=20 >existing figures, adding a NEW figure with TDF can be considered. > > also >>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >[Med] Will do. Thanks. > >>3. It makes sense to reference latest available 3GPP TS 23.203 version >>(R12) - December 2013 >[Med] OK. > >> >>Best regards and thanks in advance, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com=20 >>[mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 3:16 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use-=20 >>cases-01.txt >> >>Dear Alla, >> >>The new version cites now TS 23.203. You can check the diff available at: >> >>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner=20 >>>Envoy=E9=A0: mardi 11 f=E9vrier 2014 11:53 =C0=A0: Liushucheng (Will);=20 >>>sfc@ietf.org Objet=A0: Re: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Shucheng, >>> >>>With regard to this use case description, it would be useful, in my=20 >>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>23.203 where Traffic Detection Function (TDF) is a standardized=20 >>>element residing on Gi/SGi which implements DPI (detection)=20 >>>functionality along with enforcement and charging of the=20 >>>corresponding detected applications. This is missing from your use=20 >>>case description. I think such a comment was already provided in a diffe= rent email thread. >>> >>>Best Regards, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications=20 >>>Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng=20 >>>(Will) >>>Sent: Tuesday, February 11, 2014 11:18 AM >>>To: sfc@ietf.org >>>Subject: [sfc] FW: New Version Notification for=20 >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Hi all, >>> >>>We've just updated our use case draft. The main change is in the=20 >>>section >>of >>>Use Case of Service Function Chain in Mobile Core Network. Looking >forward >>>to your comments. >>> >>>Regards, >>>Shucheng (Will) >>> >>> >>>-----Original Message----- >>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>Sent: Tuesday, February 11, 2014 5:14 PM >>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu;=20 >>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >Leymann; >>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu;=20 >>>Huangyong (Oliver) >>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>> >>> >>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >successfully >>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>> >>>Name: draft-liu-sfc-use-cases >>>Revision: 01 >>>Title: Service Function Chaining (SFC) Use Cases >>>Document date: 2014-02-11 >>>Group: Individual Submission >>>Pages: 15 >>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>>cases-01.txt >>>Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= / >>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cas= es- >>01 >>> >>>Abstract: >>> The delivery of value-added services relies on the invocation of >>> advanced Service Functions in a sequential order. This mechanism is >>> called Service Function Chaining (SFC). The set of involved Service >>> Functions and their order depends on the service context. >>> >>> This document presents a set of use cases of Service Function >>> Chaining (SFC). >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>> >>>The IETF Secretariat >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>>##################################################################### >>>#### ># >># >>>################### >>>This message is intended only for the designated recipient(s).It may=20 >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or=20 >>>distribute this message. >>>If you have mistakenly received this message, please notify the=20 >>>sender by >>a >>>reply e-mail and delete this message. >>>Thank you. >>>##################################################################### >>>#### ># >># >>>################### >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >>###################################################################### >>#### ># >>################### >>This message is intended only for the designated recipient(s).It may=20 >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or=20 >>distribute this message. >>If you have mistakenly received this message, please notify the sender=20 >>by >a >>reply e-mail and delete this message. >>Thank you. >>###################################################################### >>#### ># >>################### >####################################################################### >#### >################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >#### >################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 14 06:01:15 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6F1A0203 for ; Fri, 14 Feb 2014 06:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhZbEe5DZ1j1 for ; Fri, 14 Feb 2014 06:01:11 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC61A024F for ; Fri, 14 Feb 2014 06:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11370; q=dns/txt; s=iport; t=1392386470; x=1393596070; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WUMLXLHkoWSla/FAi0hhtpn+3sSAR7/BE5+4aDKoCOw=; b=IL50i6qBi/+OMZisICVIg8vzsJxXAGveqQqOWL5HpqV0NSLJ0XqSnHQ4 O9X2Neei+VpzR/njQ/RU3t8H0hTcYZlsc3CyTcdxRIwNMFmjNAbPZbaQ0 XhD0zdjbJzfeR4rAksx4wNT0bCYu/OJaGOsEK+uy9yUjw7ygyKMUfzugW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAGgg/lKtJV2d/2dsb2JhbABZgwY4UQa/MoEUFnSCJQEBAQQBAQFGJQkOBAIBCBEBAwEBKAcnCxQDBQEIAgQBEgmHfAgFyRgXjhcRAR0IMgIEhDIEiRCLM4NpgTKQcYMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="20469544" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 14 Feb 2014 14:01:08 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1EE18OE021768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 14:01:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 08:01:08 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-01.txt Thread-Index: AQHPKY01/TF3ioCpfkSY7rPueJQ9Qg== Date: Fri, 14 Feb 2014 14:01:08 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36F4C31EAD3@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB53@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F4C31EB80@PUEXCB1B.nanterre.francetelecom.fr> <5602569641FB314FB4D9AD5659D41B9C2983D73A44@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.213.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6118DF4A8AE1124F8581F5786EF20834@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OECnRIA1nXARvabheSDzb9Kkrrc Subject: Re: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-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, 14 Feb 2014 14:01:14 -0000 I completely agree Ron. On 2/14/14, 8:50 AM, "Ron Parker" wrote: >Why do we need to pin down the location of the classifier? The >classifier is a logical function that may use out-of-band data, local >policy, delivered policy, local state, and the packets, themselves, to >intelligently steer packets through a sequence of midboxes. By keeping >the definition high level, implementors can innovate on useful and >practical compositions of functions. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Pham, Chuong D >Sent: Friday, February 14, 2014 12:35 AM >To: mohamed.boucadair@orange.com; Alla Goldner; Liushucheng (Will); >sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases-01.txt > >I support Med's opinion that we should not exclude all existing methods >of classifying flows which include the TDF, DPI, LB, Openflow switch, >Grid computer, PGw etc. > >Due to constraint obviously we cannot include all of these candidate >methods in the draft but there is no reason to explicitly remove any of >them in the draft which have been chosen to be included as examples of >typical current deployments. > >Regards, >Chuong > > > > > >-----Original Message----- >From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Sent: Friday, 14 February 2014 1:51 AM >To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >Subject: Re: [sfc] FW: New Version Notification for >draft-liu-sfc-use-cases-01.txt > >Re-, > >I hear your argument, but the point is we cannot ignore existing >deployments that are not relying on such functional element. We should >reflect both situations IMHO. > >Cheers, >Med > >>-----Message d'origine----- >>De : Alla Goldner [mailto:agoldner@allot.com] Envoy=E9 : jeudi 13 f=E9vri= er >>2014 15:43 =C0 : BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>sfc@ietf.org Objet : RE: [sfc] FW: New Version Notification for >>draft-liu-sfc-use-cases- 01.txt >> >>Dear Mohamed, >> >>Thanks a lot for your kind response. >> >>On the point: >>>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>>Architecture in order to outline it correctly (Figure 2 and Figure 4); >>[Med] As you know there are DPI boxes in operational mobile networks >>that are not compliant with 3GPP specifications. Instead of updating >>existing figures, adding a NEW figure with TDF can be considered. >> >> >>I don't think I agree with such a view. As long as we present >>standardized Mobile Network (defined by a different SDO i.e. 3GPP and >>not within a scope of IETF) it is very important to reference the >>existing well-defined Network Elements. DPI functionality in mobile >>network is fulfilled by the TDF. >> >>Best regards, >> >> >>Alla Goldner >>Director of Mobile Technologies and Standards Allot Communications Tel >>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>agoldner@allot.com www.allot.com >> >> >> >> >> >>-----Original Message----- >>From: mohamed.boucadair@orange.com >>[mailto:mohamed.boucadair@orange.com] >>Sent: Thursday, February 13, 2014 4:22 PM >>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>cases-01.txt >> >>Re-, >> >>Please see inline. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Alla Goldner [mailto:agoldner@allot.com] Envoy=E9 : jeudi 13 >>>f=E9vrier >>>2014 14:59 =C0 : BOUCADAIR Mohamed IMT/OLN; Liushucheng (Will); >>>sfc@ietf.org Objet : RE: [sfc] FW: New Version Notification for >>>draft-liu-sfc-use-cases- 01.txt >>> >>>Dear Mohamed, >>> >>>Thanks a lot for your kind consideration of my comment! >>> >>>I still have 3 comments in this regard: >>> >>>1. It would be useful to mention within the newly introduced text that >>>TDF resides on Gi/SGi interface >>[Med] All the functions listed in this section resides in the Gi >>interface. >>The TDF text is just after a paragraph starting with "Gi Interface >>...". We can repeat it also for TDF but we thought it is redundant. >> >>>2. Would be helpful to have "TDF" instead of "DPI" for Mobile Network >>>Architecture in order to outline it correctly (Figure 2 and Figure 4); >>[Med] As you know there are DPI boxes in operational mobile networks >>that are not compliant with 3GPP specifications. Instead of updating >>existing figures, adding a NEW figure with TDF can be considered. >> >> also >>>correct "GGSN" to "GGSN/PGW" to align with 3GPP architecture >>[Med] Will do. Thanks. >> >>>3. It makes sense to reference latest available 3GPP TS 23.203 version >>>(R12) - December 2013 >>[Med] OK. >> >>> >>>Best regards and thanks in advance, >>> >>> >>>Alla Goldner >>>Director of Mobile Technologies and Standards Allot Communications Tel >>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>agoldner@allot.com www.allot.com >>> >>> >>> >>> >>>-----Original Message----- >>>From: mohamed.boucadair@orange.com >>>[mailto:mohamed.boucadair@orange.com] >>>Sent: Thursday, February 13, 2014 3:16 PM >>>To: Alla Goldner; Liushucheng (Will); sfc@ietf.org >>>Subject: RE: [sfc] FW: New Version Notification for draft-liu-sfc-use- >>>cases-01.txt >>> >>>Dear Alla, >>> >>>The new version cites now TS 23.203. You can check the diff available >>>at: >>> >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-02 >>> >>>Cheers, >>>Med >>> >>>>-----Message d'origine----- >>>>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Alla Goldner >>>>Envoy=E9 : mardi 11 f=E9vrier 2014 11:53 =C0 : Liushucheng (Will); >>>>sfc@ietf.org Objet : Re: [sfc] FW: New Version Notification for >>>>draft-liu-sfc-use-cases- 01.txt >>>> >>>>Dear Shucheng, >>>> >>>>With regard to this use case description, it would be useful, in my >>>>opinion, referring to the existing 3GPP architecture as per 3GPP TS >>>>23.203 where Traffic Detection Function (TDF) is a standardized >>>>element residing on Gi/SGi which implements DPI (detection) >>>>functionality along with enforcement and charging of the >>>>corresponding detected applications. This is missing from your use >>>>case description. I think such a comment was already provided in a >>>>different email thread. >>>> >>>>Best Regards, >>>> >>>> >>>>Alla Goldner >>>>Director of Mobile Technologies and Standards Allot Communications >>>>Tel >>>>+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 >>>>agoldner@allot.com www.allot.com >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Liushucheng >>>>(Will) >>>>Sent: Tuesday, February 11, 2014 11:18 AM >>>>To: sfc@ietf.org >>>>Subject: [sfc] FW: New Version Notification for >>>>draft-liu-sfc-use-cases- 01.txt >>>> >>>>Hi all, >>>> >>>>We've just updated our use case draft. The main change is in the >>>>section >>>of >>>>Use Case of Service Function Chain in Mobile Core Network. Looking >>forward >>>>to your comments. >>>> >>>>Regards, >>>>Shucheng (Will) >>>> >>>> >>>>-----Original Message----- >>>>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>Sent: Tuesday, February 11, 2014 5:14 PM >>>>To: Nicolai Leymann; Hongyu Li (Julio); Liushucheng (Will); Jie Hu; >>>>Huangyong (Oliver); Hongyu Li (Julio); Mohamed Boucadair; Nicolai >>Leymann; >>>>Liushucheng (Will); Zhen Cao; Mohamed Boucadair; Zhen Cao; Jie Hu; >>>>Huangyong (Oliver) >>>>Subject: New Version Notification for draft-liu-sfc-use-cases-01.txt >>>> >>>> >>>>A new version of I-D, draft-liu-sfc-use-cases-01.txt has been >>successfully >>>>submitted by Will(Shucheng) Liu and posted to the IETF repository. >>>> >>>>Name: draft-liu-sfc-use-cases >>>>Revision: 01 >>>>Title: Service Function Chaining (SFC) Use Cases >>>>Document date: 2014-02-11 >>>>Group: Individual Submission >>>>Pages: 15 >>>>URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use- >>>>cases-01.txt >>>>Status: =20 >>>>https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ >>>>Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-01 >>>>Diff: =20 >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases- >>>01 >>>> >>>>Abstract: >>>> The delivery of value-added services relies on the invocation of >>>> advanced Service Functions in a sequential order. This mechanism is >>>> called Service Function Chaining (SFC). The set of involved Service >>>> Functions and their order depends on the service context. >>>> >>>> This document presents a set of use cases of Service Function >>>> Chaining (SFC). >>>> >>>> >>>> >>>> >>>>Please note that it may take a couple of minutes from the time of >>>>submission until the htmlized version and diff are available at >>>>tools.ietf.org. >>>> >>>>The IETF Secretariat >>>> >>>>_______________________________________________ >>>>sfc mailing list >>>>sfc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sfc >>>>##################################################################### >>>>#### >># >>># >>>>################### >>>>This message is intended only for the designated recipient(s).It may >>>>contain confidential or proprietary information. >>>>If you are not the designated recipient, you may not review, copy or >>>>distribute this message. >>>>If you have mistakenly received this message, please notify the >>>>sender by >>>a >>>>reply e-mail and delete this message. >>>>Thank you. >>>>##################################################################### >>>>#### >># >>># >>>>################### >>>> >>>>_______________________________________________ >>>>sfc mailing list >>>>sfc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sfc >>>###################################################################### >>>#### >># >>>################### >>>This message is intended only for the designated recipient(s).It may >>>contain confidential or proprietary information. >>>If you are not the designated recipient, you may not review, copy or >>>distribute this message. >>>If you have mistakenly received this message, please notify the sender >>>by >>a >>>reply e-mail and delete this message. >>>Thank you. >>>###################################################################### >>>#### >># >>>################### >>####################################################################### >>#### >>################### >>This message is intended only for the designated recipient(s).It may >>contain confidential or proprietary information. >>If you are not the designated recipient, you may not review, copy or >>distribute this message. >>If you have mistakenly received this message, please notify the sender >>by a reply e-mail and delete this message. >>Thank you. >>####################################################################### >>#### >>################### > > >_______________________________________________ >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 Feb 14 06:06:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B76F1A0273 for ; Fri, 14 Feb 2014 06:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHZsQQiE1zWx for ; Fri, 14 Feb 2014 06:06:47 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id B193B1A026B for ; Fri, 14 Feb 2014 06:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48026; q=dns/txt; s=iport; t=1392386805; x=1393596405; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=P8Ld4AA3CgjKmbLXuYKyAjVkxvS1JUhB3B25tzDLxwM=; b=OC/4LEApKFPmUDQNVrPuAzdoIEmGxUgvyfAJinoi/QlXgVi+YZ/gciow L3gN8R/K988/JtxePObVLSMLwZzb4J/PgiMmQg2GN19hxmjN7JvzM4oIx WLVyzKwU+67Hve4ok348eog8rHIrOeb0mmRpY44PSc6oFZD0sexMB7Ss2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAOoh/lKtJV2c/2dsb2JhbABQCYMGOFe/MoEUFnSCJQEBAQQBAQEXAUoCBxcEAgEIEQEDAQEBJwchBgsUAwYIAgQBEodxAxENwFENiDwXjF+BPygIMgIEhDIEiRCNMIFsgTKLLIVFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="20478576" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 14 Feb 2014 14:06:43 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1EE6h5I029029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 14:06:43 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 08:06:43 -0600 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5UwnREFNrUG0aiDEicuLyqC5qyPG4AgAAqPQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYD//6Jp6oAAbhkAgAACIACAAAHIgIAAAcsAgAAEf4CAABClAIAAOgEAgAABwwCAAJG3AA== Date: Fri, 14 Feb 2014 14:06:42 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> In-Reply-To: <52FD6262.1040605@joelhalpern.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: [10.82.213.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EmYHwX5SX6pkIoTSTB-Go1Nmj3M Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:06:52 -0000 Yes agreed Joel. Metadata is really =B3context=B2 that is consumable by any element of a given SFC. While our SFC encapsulation will of course carry information relevant to the steering of traffic through the desired set of service functions, I would not characterize that as metadata. On 2/13/14, 7:25 PM, "Joel M. Halpern" wrote: >I only consider the first of those to be metadata. The chain >identification in the service chaining header or the transport header >are not metadata. Treating fields which are needed for steering as >metadata induces massive confusion. can we please keep those two >concepts separate?! > >Yours, >Joel > >On 2/13/14, 7:18 PM, Linda Dunbar wrote: >> >> I see two types of "metadata" being discussed here: >> >> 1. The "flow metadata", like the transactions carried by http flows. >>They are inserted by applications, or inserted by a service function to >>pass some "cookies" to the next one. (many proxy based service functions >>have those capability) >> >> 2. The "Service Chain metadata", that are inserted by "Chain >>Classifier" or control plane to carry extra information (in additional >>to Chain ID) for the purpose of controlling the sequence of functions on >>a chain. >> >> Correct? >> >> IMHO, the first bullet above are specific to applications or service >>functions internal processing. Many of today's proxy based service >>functions make changes to data packets, some of them make those changes >>for other service functions. Those changes won't be in the Service Chain >>Header field. >> >> Linda >> >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee >> Sent: Thursday, February 13, 2014 2:51 PM >> To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I believe most of us agree that an out of bad signalling will not >>address the majority of requirement. Also a typical http flow carries >>many transactions and each can have different or additional >>classification. So a metadata can not be simple connected with one flow >>either. Current implementations of proxies and load balancers has >>addressed this in many ways including custome header insertion. The >>custom header in this case equivalent of metadata vector. >> >> I think we need an efficient way annotate actual data with inline >>metadata. I also strongly believe in solving the 80% of the use case >> >> Regards >> Sumandra >> ________________________________________ >> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>[jmh@joelhalpern.com] >> Sent: Thursday, February 13, 2014 11:51 AM >> To: Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I know very well what GTP does in terms of correlators, and why. >> If all you need is an identifier for the subscriber, carrying a short >>identifier, and using it to select the desired behavior that has been >>pre-populated when the subscribers session starts works really well. >> That is part of why I am not objecting to having provision for >>out-of-band metadata. >> >> However, claiming that a single such correlator is all that is needed >>for even 80% of SFC cases (and I very much supporting trying to focus on >>the 80% cases), just does not seem to work, given the broad range of >>requirements that we have seen. >> >> Yours, >> Joel >> >> On 2/13/14, 2:35 PM, Jerome Moisand wrote: >>> Joel, >>> >>> Protocols like GTP and L2TP work exactly that, with a form of session >>>correlator between the data plane and the control plane. This is very >>>handy for subscriber and service management. Also if a correlator is >>>defined as an opaque and unique number, then one can avoid some of the >>>pitfalls you described. Long-lived metadata is clearly useful (and >>>thanks for sharing, Reinaldo, will read), and there is clear >>>applicability to various service chaining needs. >>> >>> Now this is just one way. The I-D Bruno referred to was just listing >>>this approach as one possible way among others. I totally agree with >>>you that other forms of metadata (like an outcome of the classification >>>of a packet or a sequence of a few packets) may not be suitable for >>>out-of-band signaling. >>> >>> Bottomline seems to be that we have too many options to choose from, >>>and none of them solving it all... Tough. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 13, 2014 2:29 PM >>> To: sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> As I understand it, the tsvwg (and aeon) work is about flow metadata. >>> That is long-lived metadata of use across many packets. That does >>>indeed seem well-suited to out-of-band cases. >>> >>> My concern is that in SFC, there are many cases which are at best >>>badly-addressed if we insist that they be solved using out-of-band >>>metadata. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>>> There is draft about transport independent metadata. >>>> >>>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding >>>> - >>>> 01 >>>> >>>> The complexities you mention are discussed there: variable-encoding, >>>> direction, security of metadata, etc. >>>> >>>> Thanks, >>>> >>>> -RP >>>> >>>> >>>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>>> >>>>> While there are cases where out-of-band metadata makes sense, There >>>>> are many cases I would not want to try to cover that way. The best >>>>> examples are situations where the metadata changes from packet to >>>>> packet (such as the data produced by a DPI engine for consumption by >>>>> other applications in the chain.) >>>>> >>>>> More importantly, if you are putting correlators in the packet, it >>>>> is still very complex if you want to use one correlator to handle >>>>> metadata produced by several different entities (the initial >>>>> classifer, the DPI engine, ...) You quickly end up deciding that >>>>> you need several correlators. At which point we are back to >>>>>variable amounts of metadata. >>>>> >>>>> The alternative is to require exceedingly specific and strong >>>>> coupling to a mandated out-of-band mechanism. That seems to me to >>>>> be a very bad idea. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>>> resend to avoid "too many recipients" warning >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman >>>>>> > wrote: >>>>>> >>>>>> There are ways to signal variable length amounts of metadata >>>>>>without >>>>>> needing an additional variable-length header on each data >>>>>>packet. >>>>>> >>>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some >>>>>>of the >>>>>> possible approaches: out-of-band signaling (congruent or >>>>>> non-congruent) or a hybrid approach using a fix-length >>>>>>in-band >>>>>> correlator and out-of-band additional metadata. See >>>>>>sections 3.3, >>>>>> 3.4 and 3.5 in the draft. >>>>>> >>>>>> The issue of fixed-length encoding versus variable length >>>>>>encoding >>>>>> is discussion in the challenges chapter in section 4.3. I >>>>>>should >>>>>> probably mention the MTU and segmentation issues as well in >>>>>>that >>>>>> section. >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>>> > wrote: >>>>>> >>>>>> The variable length shim header is needed even if every >>>>>> individual piece of metadata has a fixed length. >>>>>>Different >>>>>> service chains will need different combinations of >>>>>>metadata. So >>>>>> the metadata portion of the header needs to be variable >>>>>>length. >>>>>> >>>>>> I think the approach of a fixed length initial part, and >>>>>>a >>>>>> variable length extension part, is the right model. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>>> >>>>>> Yes, fragmentation and variable headers are usually >>>>>>a really >>>>>> bad thing for forwarding performance. Let's not >>>>>>forget that >>>>>> we live in a 100G-ish kind of world nowadays. >>>>>> >>>>>> Now the question should be: WHY would we want to do >>>>>>that >>>>>> (variable headers leading to fragmentation issues)? >>>>>> >>>>>> For example, the type of metadata that may require >>>>>> variable-length fields might be a better candidate >>>>>>for some >>>>>> out-of-band signaling mechanism. If this is service >>>>>> authorization data (e.g. a service profile/policy), >>>>>>this >>>>>> sounds likely. Not 100% sure this is true for all >>>>>>use cases >>>>>> though. Only a good understanding of use cases, >>>>>>grounded by >>>>>> reflecting on existing network architectures (notably >>>>>> broadband, fixed or mobile), would tell us if one >>>>>>approach >>>>>> or another is the most appropriate. >>>>>> >>>>>> Anyhoo, we're jumping way deep in the detailed >>>>>>protocol >>>>>> design here. This seems a tad premature. >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>>> ] On Behalf Of Dave >>>>>>Dolson >>>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>>> To: 'jmh@joelhalpern.com >>>>>>'; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> '; >>>>>> 'mohamed.boucadair@orange.com >>>>>> '__; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>>'paulq@cisco.com >>>>>> ' >>>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>>'; >>>>>> 'linda.dunbar@huawei.com >>>>>>' >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> it is overall more efficient to support PMTU >>>>>>discovery >>>>>> rather than fragmenting every large packet. The is >>>>>>why TCP >>>>>> adopted it so early on. >>>>>> >>>>>> The fragmenting also puts huge performance burden on >>>>>>the >>>>>> service functions. >>>>>> Fragmenting may also affect the ability of load >>>>>>balancers to >>>>>> get each fragment to the correct destination. >>>>>> >>>>>> So PMTU discovery SHOULD be used, in my opinion. By >>>>>>this I >>>>>> mean the client or server is informed that its >>>>>>packets are >>>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>>> >>>>>> Some operators may wish to incur the extra cost to >>>>>>hide the >>>>>> existence of the tunneling, when the elements of the >>>>>>chain >>>>>> can support it, so we could consider that as an >>>>>>optional >>>>>> mechanism. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>>> ] >>>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>>> To: Ron Parker >>>>> >; >>>>>> mohamed.boucadair@orange.com >>>>>> >>>>>> >>>>> >__; Dave >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> ' >>>>>> >>>>> >; >>>>>>'paulq@cisco.com >>>>>> ' >>>>> > >>>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>>> ' >>>>>>; >>>>>> 'linda.dunbar@huawei.com >>>>>>' >>>>>> >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I mostly agree with you Ron. I can probably come up >>>>>>with >>>>>> some other variations, but your second point is that >>>>>>the >>>>>> transport must deal with the issue of frame size / >>>>>>fit. >>>>>> >>>>>> I would note that if we assume that the carrying >>>>>>encaps >>>>>> (IPv4/v6 outer) is being fragmented, then we are >>>>>>assuming >>>>>> that the exit from service chaining can and will >>>>>>reassemble. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> That is an excellent point to consider when >>>>>>choosing >>>>>> transport >>>>>> encapsulations. If the transport encapsulation >>>>>>is IPv4 >>>>>> or IPv6 >>>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, >>>>>> etc.), then >>>>>> fragmentation and defragmentation are naturally >>>>>> supported. If the >>>>>> transport encapsulation is VLAN, MPLS, etc., >>>>>>then I >>>>>> believe one of the >>>>>> following must be true: >>>>>> >>>>>> * The end-to-end path is known to support the >>>>>>resulting >>>>>> larger frames >>>>>> * A path discovery mechanism is mandated by SFC >>>>>>when >>>>>> non-IP transports >>>>>> are used * An SFC-specific fragmentation header >>>>>>and >>>>>> mechanisms must be >>>>>> defined (i.e., >>>>>> >>>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or- >>>>>> f >>>>>> rame) >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com >>>>>> ] Sent: Thursday, >>>>>>February >>>>>> 13, 2014 10:10 >>>>>> AM To: mohamed.boucadair@orange.com >>>>>> ; Dave >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; Ron >>>>>>Parker; >>>>>> 'paulq@cisco.com ' Cc: >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>>'; >>>>>> 'linda.dunbar@huawei.com >>>>>> ' Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> There is a related complexity. I hope that we >>>>>>expect to >>>>>> support IPv6. >>>>>> IPv6 explicitly prohibits network elements from >>>>>> fragmenting end user >>>>>> packets. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>>> wrote: >>>>>> >>>>>> Re-, >>>>>> >>>>>> FWIW, one of the existing architecture drafts >>>>>> includes the following >>>>>> behavior >>>>>> >>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#se >>>>>> c >>>>>> tion- >>>>>> 6 >>>>>> >>>>>>=20 >>>>>>>>>>>6>): >>>>>> >>>>>> >>>>>> >>>>>> " >>>>>> >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> If adding the Service Chaining Header would >>>>>>result >>>>>> in a fragmented >>>>>> packet, the classifier should include a >>>>>>Service >>>>>> Chaining Header in >>>>>> each fragment. Doing so would prevent SF >>>>>>Nodes to >>>>>> dedicate resource >>>>>> to handle fragments. " >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>> >>>>>> -----Message d'origine----- De : sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>'; >>>>>> 'jmh@joelhalpern.com >>>>>> '; >>>>>> 'paulq@cisco.com >>>>>>' Cc : >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>> '; >>>>>> 'linda.dunbar@huawei.com >>>>>> ' Objet >>>>>>: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Good point to consider fragmentation. >>>>>> >>>>>> We should design the encapsulation such >>>>>>that the >>>>>> forwarding >>>>>> functions do not need to reassemble. Each >>>>>> fragment should be >>>>>> independently forwardable; some SFs may >>>>>>choose >>>>>> to ignore these >>>>>> packets. >>>>>> >>>>>> Any layer 2.5 protocol like VLAN or MPLS >>>>>>would >>>>>> support this. >>>>>> Otherwise, a reassembly layer could be >>>>>>added >>>>>> after the forwarding >>>>>> coordinates. Think of something like the >>>>>>IPv6 >>>>>> reassembly option >>>>>> after a GRE header, for instance. >>>>>> >>>>>> IP | GRE | reassem | frag data >>>>>> >>>>>> We could alternatively mandate the inner >>>>>>IP be >>>>>> fragmented and that >>>>>> path-MTU discovery be supported. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: >>>>>> Nicolas BOUTHORS >>>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>>> ] >>>>>>Sent: >>>>>> Thursday, February 13, >>>>>> 2014 04:13 AM To: Ron Parker >>>>>> >>>>> =20 >>>>>>>; >>>>>> Dave Dolson; Joel M. Halpern >>>>>> >>>>> >; Paul Quinn >>>>>> (paulq) >>>>> > Cc: Sumandra >>>>>>Majee >>>>>> ; >>>>>> sfc@ietf.org >>>>>>>>>>> >; Linda Dunbar >>>>>> >>>>> > >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> If we do not enforce a fix header size >>>>>>we have >>>>>> other implication. >>>>>> >>>>>> There is the question of segmentation and >>>>>> reassembly responsibility >>>>>> as well. >>>>>> >>>>>> If adding length to the service header >>>>>>forces >>>>>> segmentation, then >>>>>> whose responsibility is it to reassemble >>>>>>the >>>>>> payload before passing >>>>>> it to the SF. >>>>>> >>>>>> Similar question for packet re-ordering. >>>>>> >>>>>> >>>>>> =20 >>>>>>__________________________________________ From: >>>>>> Ron Parker >>>>>> [Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>>>Halpern; >>>>>> Paul Quinn >>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> Dave, >>>>>> >>>>>> Yes, that is a good point if we logically >>>>>> separate the forwarding >>>>>> function from the SFC-aware service >>>>>>function, as >>>>>> we should. The >>>>>> forwarding function is concerned with >>>>>>only the >>>>>> inbound transport >>>>>> header, the fixed portion of the >>>>>>service header >>>>>> containing the >>>>>> chain information, and the outbound >>>>>>transport >>>>>> header. The >>>>>> service function may look at the >>>>>>entirety of the >>>>>> service header and >>>>>> would look at the encapsulated packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Dave >>>>>>Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; >>>>>>Paul >>>>>> Quinn (paulq) Cc: >>>>>> Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: RE: >>>>>> [sfc] >>>>>> Framework >>>>>> >>>>>> The forwarding plane might not even need >>>>>>to look >>>>>> at the encapsulated >>>>>> packet. >>>>>> >>>>>> For example, (if the SF Identifier is a >>>>>>VLAN >>>>>> tag), an Ethernet >>>>>> switch can forward packets of the form: >>>>>>Ether | >>>>>> VLAN | BLOB. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>> Wednesday, February 12, 2014 4:30 PM To: >>>>>>Ron >>>>>> Parker; Dave Dolson; >>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>>> sfc@ietf.org ; >>>>>>Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I agree as well. Yours, Joel >>>>>> >>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>> >>>>>> Hi, Dave. >>>>>> >>>>>> I Agree with your statement. And >>>>>>if the >>>>>> total length of the >>>>>> header is >>>>>> >>>>>> contained in the mandatory portion, the >>>>>>hardware >>>>>> implementation can >>>>>> easily locate the encapsulated packet. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Dave Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 4:10 PM To: Ron Parker; Paul >>>>>>Quinn >>>>>> (paulq) Cc: Joel M. >>>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: >>>>>> RE: [sfc] Framework >>>>>> >>>>>> I think a good approach would be: >>>>>> >>>>>> The information required for >>>>>>forwarding (the >>>>>> SF Identifier) should >>>>>> be in >>>>>> >>>>>> a mandatory fixed-size header. >>>>>> >>>>>> >>>>>> Optional information (if any) is NOT >>>>>>to be >>>>>> used for forwarding, but >>>>>> is >>>>>> >>>>>> for consumption by one or more of the >>>>>> applications in the chain. >>>>>> >>>>>> >>>>>> Then the forwarding plane, and even >>>>>>the PDP, >>>>>> can be agnostic about >>>>>> the >>>>>> >>>>>> meta-data. >>>>>> >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Ron Parker Sent: >>>>>> Wednesday, February 12, 2014 4:05 PM >>>>>>To: >>>>>> Paul Quinn (paulq) Cc: >>>>>> Joel M. Halpern; Sumandra Majee; >>>>>> sfc@ietf.org ; >>>>>> Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Paul, >>>>>> >>>>>> That is why I am proposing a hybrid >>>>>>where >>>>>> extensions or options can >>>>>> be >>>>>> >>>>>> added but the total length is contained >>>>>>in the >>>>>> fixed portion. I >>>>>> can envision certain deployments (e.g., >>>>>> Enterprise) where perhaps >>>>>> extensions are not needed and the SFC >>>>>> functionality is realized >>>>>> in hardware. And, I can envision >>>>>>certain other >>>>>> deployments >>>>>> (e.g., 3gpp) where the extension headers >>>>>>add >>>>>> sufficient value to >>>>>> justify software based implementations. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Paul Quinn >>>>>> (paulq) >>>>>> [mailto:paulq@cisco.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 3:40 PM To: Ron Parker Cc: Sumandra >>>>>>Majee; >>>>>> Linda Dunbar; Joel M. >>>>>> Halpern; sfc@ietf.org >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Hi, >>>>>> >>>>>> We certainly need to be very careful >>>>>>with >>>>>> variable length headers >>>>>> when >>>>>> >>>>>> hardware platform are in play. >>>>>> >>>>>> >>>>>> Ron, your examples of IP options and >>>>>>v6 EH >>>>>> have both suffered from >>>>>> >>>>>> significant implementation and deployment >>>>>> hurdles due to the >>>>>> complexity and cost associated with >>>>>>hardware >>>>>> support for the >>>>>> option/EH. >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> On Feb 12, 2014, at 3:10 PM, Ron >>>>>>Parker >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, Sumandra. >>>>>> >>>>>> Regarding service header >>>>>>flexibility, I >>>>>> completely agree. I >>>>>> might >>>>>> >>>>>> suggest a compromise between hardware >>>>>> friendliness and software >>>>>> flexibility. If the header had the >>>>>>ability to >>>>>> add extensions >>>>>> (perhaps similar to IPv6) but also had >>>>>>the >>>>>> header length encoded in >>>>>> the mandatory part (like IPv4), then a >>>>>>hardware >>>>>> implementation would >>>>>> be free to skip over the extensions (in >>>>>>cases >>>>>> where the deployment >>>>>> justifies ignoring the extensions). >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>> Sumandra Majee >>>>>> [mailto:S.Majee@F5.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, 2014 >>>>>> 3:04 PM To: Ron Parker; Linda >>>>>>Dunbar; >>>>>> Joel M. Halpern; >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> For all of those=20 >>>>>>reasons, I >>>>>> strongly support a >>>>>> canonical service >>>>>> header that is=20 >>>>>>independent of >>>>>> the transport=20 >>>>>>methodology. >>>>>> >>>>>> >>>>>> >>>>>> I agree. However the format of=20 >>>>>>service >>>>>> header should be >>>>>> standardized in >>>>>> >>>>>> a way that is flexible. Some of us would= =20 >>>>>>like to >>>>>> see variable length >>>>>> header that is also HW friendly. The=20 >>>>>>service >>>>>> header can be >>>>>> represented as a mandotory fixed length=20 >>>>>>header >>>>>> (like IP >>>>>> header) along with an optional variable=20 >>>>>>length >>>>>> attribute field. >>>>>> Different services can be interested in >>>>>> different metadata, for >>>>>> example subscriber ID could be of=20 >>>>>>interest in >>>>>> the mobile core >>>>>> service chain only. >>>>>> >>>>>> >>>>>> Sumandra >>>>>> >>>>>> On 2/12/14, 11:32 AM, "Ron=20 >>>>>>Parker" >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the >>>>>> architecture docs is that the >>>>>> service >>>>>> function chain is built in an >>>>>> abstract manner (i.e., SF-A=20 >>>>>>then >>>>>> SF-B >>>>>> >>>>>> then SF-C). >>>>>> >>>>>> Separately, a locator table=20 >>>>>>provides >>>>>> network location for >>>>>> each of those service=20 >>>>>>functions. >>>>>> In this way, you can >>>>>> locate the service functions >>>>>> >>>>>> in >>>>>> >>>>>> a manner appropriate to the=20 >>>>>>type of >>>>>> transport you are >>>>>> using. If you want that to= =20 >>>>>>be >>>>>> interface+VLAN, >>>>>> gateway-IP+MPLS label stack, >>>>>> IP >>>>>> >>>>>> address, >>>>>> >>>>>> GRE tunnel remote IP + key,=20 >>>>>>etc., >>>>>> you can do that. You >>>>>> can even potentially locate >>>>>> different service functions=20 >>>>>>that >>>>>> reside in the same chain with >>>>>> different flavors of >>>>>> network locators. Another >>>>>> justification to separate the >>>>>> identity of a service=20 >>>>>>function from >>>>>> its network location is >>>>>> load balancing. If, for=20 >>>>>>example, >>>>>> SF-A had 3 IP addresses, >>>>>> that would imply load=20 >>>>>>balancing to 3 >>>>>> instances using IP as a >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons, I=20 >>>>>>strongly >>>>>> support a canonical service >>>>>> header that is independent=20 >>>>>>of the >>>>>> transport >>>>>> methodology. At a=20 >>>>>>particular >>>>>> node, the decision as to >>>>>> where to go next should be=20 >>>>>>based >>>>>> solely on information=20 >>>>>>carried in >>>>>> the canonical service header= =20 >>>>>>and not >>>>>> on the >>>>>> >>>>>> fields >>>>>> >>>>>> in the transport header. =20 >>>>>>That is, >>>>>> the SFC node discards >>>>>> the transport header and=20 >>>>>>extracts >>>>>> the chain ID from the >>>>>> service header. Through >>>>>> mechanisms we have not yet=20 >>>>>>begun >>>>>> to discuss, the SFC node=20 >>>>>>knows how >>>>>> to interpret the chain ID and >>>>>> ultimately how to progress >>>>>> the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message-----=20 >>>>>>From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org >>>>>> =20 >>>>>>Subject: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence=20 >>>>>>below >>>>>> should be added Section 5.2=20 >>>>>>(SFC >>>>>> Classifier) to emphasize=20 >>>>>>this point. >>>>>> >>>>>> "A Service Chain Classifier=20 >>>>>>node can >>>>>> associate a unique Layer 2 >>>>>> or 3 Label (e.g. VLAN, MPLS=20 >>>>>>label) >>>>>> to the packets in the flow. >>>>>> Those Layer 2 or 3 Label=20 >>>>>>makes it >>>>>> easier for subsequent nodes >>>>>> along the flow path to steer= =20 >>>>>>the >>>>>> flow to the service functions >>>>>> specified by the flow's >>>>>> service chain." >>>>>> >>>>>> >>>>>> Linda -----Original=20 >>>>>>Message----- >>>>>> From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 10:20 AM To: >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the=20 >>>>>>framework >>>>>> proposal. The proposal has a= =20 >>>>>>very >>>>>> specific model of the scope=20 >>>>>>of the >>>>>> transport header (that it is >>>>>> derived from, and relates=20 >>>>>>only to, >>>>>> the first service function to >>>>>> which the packet will be=20 >>>>>>directed. >>>>>> That is clearly an=20 >>>>>>operational >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to=20 >>>>>>allow other >>>>>> transport operational >>>>>> models, such as the use of a= =20 >>>>>>VLAN to >>>>>> direct traffic along a >>>>>> chain. Or the use of an=20 >>>>>>MPLS label, >>>>>> or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 Fri Feb 14 06:23:54 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A650A1A027E for ; Fri, 14 Feb 2014 06:23:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5x0tJ2iPcMW for ; Fri, 14 Feb 2014 06:23:50 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id BAF791A0262 for ; Fri, 14 Feb 2014 06:23:50 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 06:23:49 -0800 From: Ron Parker To: "sfc@ietf.org" Thread-Topic: comments on draft-quinn-nsh Thread-Index: Ac8pjlJAii6JsZ8NQ9uMaAqBcjV9pg== Date: Fri, 14 Feb 2014 14:23:48 +0000 Message-ID: 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_CDF2F015F4429F458815ED2A6C2B6B0B1A7A8AFDMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wRGgK8t8AnQ03kDtKLy8HkNoNzQ Subject: [sfc] comments on draft-quinn-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:23:52 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A8AFDMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello authors of draft-quinn-nsh. Thanks for posting the update. I ha= ve concerns on the metadata portion of the proposal. I think there are s= ome requirements that the group should work through, first, before we can p= in down the actual bits and bytes. For example, a very partial list of re= quirements that come to mind: * Registered metadata types o Like the official IPv4 options or the official IPv6 extension headers * Vendor specific metadata types o Using an OUI of some sort * Flexible length metadata o For example, a 64-bit subscriber ID * Support for both long lived (for the duration of the flow or unti= l changed or revoked) and temporal (packet by packet) inband metadata o Acknowledgement scheme that long lived data no longer needs to be inser= ted There was an example in Vancouver where 2 non-adjacent coordinated service = functions shared a priority discard eligibility between them. In draft-ma= -sfc, there is the need to insert private correlation handles. All of th= is can be happening at the same time. The metadata capabilities need to s= upport these types of models, and more, if SFC is really going to enable in= novation in the networks. Thanks. Ron --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A8AFDMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello authors of draft-quinn-nsh.   Thanks= for posting the update.     I have concerns on the met= adata portion of the proposal.    I think there are some req= uirements that the group should work through, first, before we can pin down= the actual bits and bytes.   For example, a very partial list of req= uirements that come to mind:

 

·         Registered metadata types

o   Like the official IPv4 options or the offici= al IPv6 extension headers

·         Vendor specific metadata types

o   Using an OUI of some sort

·         Flexible length metadata

o   For example, a 64-bit subscriber ID

·         Support for both long lived (for the duratio= n of the flow or until changed or revoked) and temporal (packet by packet) = inband metadata

o   Acknowledgement scheme that long lived data = no longer needs to be inserted

 

There was an example in Vancouver where 2 non-adjace= nt coordinated service functions shared a priority discard eligibility betw= een them.   In draft-ma-sfc, there is the need to insert private = correlation handles.    All of this can be happening at the same time.   The metadata capabilities need to support th= ese types of models, and more, if SFC is really going to enable innovation = in the networks.

 

Thanks.

 

    Ron

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A7A8AFDMBX021W3CA2exch_-- From nobody Fri Feb 14 07:29:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ECC1A0274 for ; Fri, 14 Feb 2014 07:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kcp1x3L-4gU for ; Fri, 14 Feb 2014 07:29:00 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 927601A0284 for ; Fri, 14 Feb 2014 07:29:00 -0800 (PST) Received: from mail44-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE041.bigfish.com (10.243.66.106) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 15:28:58 +0000 Received: from mail44-co1 (localhost [127.0.0.1]) by mail44-co1-R.bigfish.com (Postfix) with ESMTP id CF512CC0160; Fri, 14 Feb 2014 15:28:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(z579ehf7Iz9371Ic89bh2174M936eI146fId772h1102I542I1432I12d5I4015I1447I14ffI9a6kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdch70kz1de098h1033IL17326ah8275bh8275dh1de097h186068h18602ehz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail44-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(53754006)(48214007)(37745?= =?iso-8859-1?Q?4003)(377424004)(189002)(51704005)(2473001)(199002)(435440?= =?iso-8859-1?Q?03)(85644002)(164054003)(52314003)(13464003)(51914003)(815?= =?iso-8859-1?Q?42001)(87936001)(74366001)(81342001)(224303002)(2656002)(8?= =?iso-8859-1?Q?7266001)(76786001)(74706001)(76576001)(4396001)(1520234500?= =?iso-8859-1?Q?3)(85852003)(74316001)(74876001)(90146001)(76796001)(83072?= =?iso-8859-1?Q?002)(2201001)(92566001)(56816005)(95666001)(95416001)(1958?= =?iso-8859-1?Q?0405001)(79102001)(59766001)(19580395003)(56776001)(779820?= =?iso-8859-1?Q?01)(93516002)(54316002)(54356001)(80976001)(85306002)(6581?= =?iso-8859-1?Q?6001)(551544002)(80022001)(53806001)(47736001)(50986001)(3?= =?iso-8859-1?Q?3646001)(31966008)(94946001)(93136001)(49866001)(83322001)?= =?iso-8859-1?Q?(47976001)(15974865002)(81686001)(69226001)(15975445006)(6?= =?iso-8859-1?Q?3696002)(46102001)(51856001)(66066001)(76482001)(74662001)?= =?iso-8859-1?Q?(74502001)(81816001)(86362001)(94316002)(47446002)(921002)?= =?iso-8859-1?Q?(1121002)(24704002)(24736002)(579004);DIR:OUT;SFP:1101;SCL?= =?iso-8859-1?Q?:1;SRVR:CO2PR05MB714;H:CO2PR05MB716.namprd05.prod.outlook.?= =?iso-8859-1?Q?com;CLIP:66.129.241.12;FPR:E7DFFDE5.ABBAD391.8DD0F847.9225?= =?iso-8859-1?Q?6848.20A76;InfoNoRecordsMX:1;A:1;LANG:en;?= Received: from mail44-co1 (localhost.localdomain [127.0.0.1]) by mail44-co1 (MessageSwitch) id 1392391736603390_31449; Fri, 14 Feb 2014 15:28:56 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.237]) by mail44-co1.bigfish.com (Postfix) with ESMTP id 8EE7FAC004B; Fri, 14 Feb 2014 15:28:56 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 15:28:56 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 15:28:54 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 15:28:51 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 15:28:51 +0000 From: Jerome Moisand To: Alla Goldner , Linda Dunbar , "Jeffrey Napper (jenapper)" , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPKVAO6BL+JnzsO0CP8G69JVjjU5q03wZA Date: Fri, 14 Feb 2014 15:28:50 +0000 Message-ID: <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 01221E3973 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/afKWpHOf_QRMdlpaJD9XTewnTZ0 Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:29:06 -0000 Linda, A PGW is a PCEF for sure (hence is more than a classifier). So this part of= your proposed drawing would have to be improved. Now in the TDF case, a better drawing would show PGW(PCEF) and TDF(PCEF) in= sequence. As this is the reality of things, a TDF does not replace a PGW, = it (optionally) complements it. Anyhoo, I feel we're going a bit in circles here. Why not letting the autho= rs of this draft (who obviously know the 3GPP constructs very well) improve= it as they see fit based on the feedback? Tx Jerome -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com]=20 Sent: Friday, February 14, 2014 1:43 AM To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Dear Linda, all, I think this presentation is more correct, thank you. One thing though may need to be corrected: PCEF is an integral part of PGW = as defined by 3GPP standards. Therefore, we may, as an option, mention "PC= EF/TDF" without "PGW", and then put a note that PCEF resides in PGW. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, February 14, 2014 1:17 AM To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Alla, Jerome,=20 Since 3GPP has defined many components and are still involving, can we use = a simplified box to represent an entity associated with P-GW that classifie= s the traffic based on PCRF rules, TDF, and/or PCEF? Such as: | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF/| | |Network| =20 |rules| < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 V | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| & or | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> |TDF/PCEF | | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network As for the description of metadata used by Gi-LAN service function, we don'= t have to specifically say which elements defined by 3GPP encoded them in.= =20 Linda -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 10:30 AM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt I don't know if the whole PCC architecture is truly optional in 3GPP theory= (I've never seen it expressed that way, but I'll take your word for it), b= ut one would be hard-pressed to find a 3G/LTE mobile broadband network with= out it. So in practice my 100% statement remains true (I'll give you 99.9% = if you wish!).=20 So I have a bit of an issue putting PGW and TDF at the same level. This sim= ply doesn't reflect any reality, nor the spirit of the 3GPP specs. And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory (= I took a very active role in several of those specs, e.g. TR-101). While a = DPI function is truly optional (and not that many subscribers in absolute %= go through it in practice) and not standardized. Anyway, I agree with you that mobile use cases with or without TDF should b= e considered. A case without PGW would seem much more dubious to me. We may= be saying more or the same thing, overall. -----Original Message----- From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, February 13, 2014 11:15 AM To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Dear Jerome, Yes, TDF is an optional element in mobile networks. As a such, Sd interface= is also optional. However, the GGSN/PGW-PCRF (Gx) interface is optional in= exactly the same way. The whole 3GPP PCC architecture is optional. Therefo= re, the claim about 100% of mobile data subscribers may not be fully correc= t. And with regards to the features required for service classification and= service enforcement that you describe below - they are present at both GG= SN/PGW and TDF. The bottom line is that use cases where PGW is considered as classifier OF = COURSE should be considered, same as use cases where TDF is considered as a= classifier. And, once describing those use cases, the existing 3GPP archit= ecture should be assumed. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Thursday, February 13, 2014 5:27 PM To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter= , Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case= -mobility@tools.ietf.org; sfc@ietf.org Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Alla & folks, Well... I don't know... Getting deep in network architectures and the role = of the various network elements is indeed crucial. Both 3GPP and BBF (Broad= band Forum) did a lot of work in the past decade to define architecture & n= odal requirements, which shaped in turn the deployment of all major Service= Providers worldwide. So quite clearly, service chaining have to build on t= hat and find a good way to insert itself into such architectures while exte= nding them. Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for s= ervice classification/enforcement, as it... already does it for its own pur= pose! This is BY NATURE a highly scalable subscriber & service management s= ystem, classifying and enforcing policies (usually L3, occasionally higher)= , and fully integrated with the HSS/PCRF chain which holds the subscriber/s= ervice authentication & authorization data. As such, service classification= *and* service enforcement (and service accounting) is already there. For 1= 00% of the mobile (data) subscribers. Sure enough, a TDF system may also do= its own form of service classification (and processing too), but let's not= forget this is an OPTIONAL system on the data path on the recently defined= 3GPP architectures you referred to. For many use cases, there is just no p= oint going through a DPI function. While for other use cases, there is clea= rly such a point, but only when it brings clear value for a given service c= onstruct, only applicable to corresponding subscribers. In the same vein, in fixed-broadband architectures, a BNG is the primary su= bscriber management system on the data path, fully integrated with a AAA sy= stem, and already doing service classification *and* service processing at = scale for 100% of the subscribers. Any classification/enforcement system be= hind it is optional and only applicable to a subset of services & subscribe= rs. Bottomline: sure, use cases with TDF should be described, but PGW-centric u= se cases remain the rule, not the exception. And double-clicking on existin= g standardized network architectures (e.g. 3GPP and BBF) and related deploy= ments is crucial for our SFC endeavor. Jerome Moisand. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner Sent: Thursday, February 13, 2014 1:18 AM To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE;= Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tool= s.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Deal Linda,=20 The 3GPP architecture picture described below is not accurate.=20 Starting from R11, PCRF interacts also with TDF (Traffic Detection Function= ) for providing ADC (Application Detection and Control) Rules for applicati= on detection, enforcement and also charging starting from R12. Please see a= rchitecture diagram for your reference in the 3GPP TS 23.203. Therefore, we can't assume that "Since PCRF usually only interfaces with th= e GGSN (via Diameter), not the service functions, do you mean "for the GGSN= (or the flow classifier) to carry the data passed down from PCRF to packet= s' metadata field to service functions on the chain"?" Furthermore, also the claim that "The P-GW/PCEF (per 3GPP terminology) determines the desired service treatm= ent, i.e. desired sequence of service functions, to specific flows based on= the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions." is not correct as well as PGW/PC= EF is not the only element which enforces different support per different f= lows based on policies received from PCRF, but also TDF! My general feeling is that we are getting here deeply into 3GPP architectur= e and make assumptions and conclusions about potential 3GPP elements functi= onality which are not in scope of IETF. If we want to define use cases for = 3GPP networks, then we should show correct picture of 3GPP architecture wi= thout redesigning it and leave 3GPP Network Elements functionality potentia= l extensions to 3GPP. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 13, 2014 12:13 AM To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave Dolson; = Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sf= c@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Jeffrey and Walter,=20 Here are some suggestions to your draft: Section 2.2:=20 - your draft states "The Gi-LAN service functions may use subscriber and se= rvice related metadata delivered from mobile control plane function like PC= RF to process the flows according to service related policies" Since PCRF usually only interfaces with the GGSN (via Diameter), not the se= rvice functions, do you mean "for the GGSN (or the flow classifier) to carr= y the data passed down from PCRF to packets' metadata field to service func= tions on the chain"? Since the policies passed down by PCRF usually can't be understood by servi= ce functions, I suggest changing to the following text: "The (S)Gi-LAN service functions may use subscriber and service related inf= ormation, that are either embedded in packets as metadata or passed down fr= om control plane, to process the flows according to service related polici= es" Section 2.3 The most common classification scheme I think this section is very confusing. How is "APN for P-GW IP address" us= ed in traffic classification?=20 Are you saying that traffic are grouped to specific P-GW? And each APN has = a VLAN-ID?=20 I understand that some common classification scheme could be encoding a cer= tain QoS to a specific flow, applying some security functions to some flows= , etc. The classification node can use simple VLAN-ID to mark different cla= ssification.=20 P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? =20 I think the Wireless Service Chain example given by Walter at Berlin SFC BO= F is very good.=20 Walter's wireless example is described in the Section 3.2 of https://datatr= acker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ Maybe you can use the text to replace your Section 2.3? Here is the suggest= ed text: ----------------- The P-GW/PCEF (per 3GPP terminology) determines the desired service treatme= nt, i.e. desired sequence of service functions, to specific flows based on = the policies from PCRF.=20 The P-GW in the figure acts as the Service Chain Classification Node. P-GW = separates the traffic into different categories (or flows) based on the pol= icies from PCRF. The traffic in each category (or flow) is mapped to a uniq= ue interface (a physical or virtual port) or a tunnel that is connected to = the needed sequence of service functions.=20 =20 | Mobile backhaul Network =20 +-----+ | +---+---+ =20 |PCRF | | |Network| =20 | | < ---- > |Ctrller| =20 +-----+ | +----+--+=20 | | =20 | | =20 +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ =20 -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | |=20 | | | +---------+ +----+ --->| | | +--------+ +-----+ =20 -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | |=20 +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Linda -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] Sent: Sunday, February 09, 2014 1:44 PM To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin Stieme= rling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi Linda, First, thanks for the feedback. While it may look like a lot of components,= we still have simplified 3GPP quite a lot. For example, in the first draft= we left out the TDF that appears in recent standards. We=B9ll be adding th= at in response to other comments. I believe the overview section is still q= uite short, but we will try to shorten it a bit further if it is too long. = If you feel anything in particular is missing or extraneous, please let us = know. Yes, it is probably overkill to have two example APNs. The User & Pass are = important for example in cases of hot-lining where the user must first be a= uthenticated (for various reasons) before data services are provided/contin= ued. It is just another example of the important relationship between Class= ification (in an SFC sense) and Policy and Charging (in a 3GPP sense). Cheers, Jeff -----Original Message----- From: Linda Dunbar Date: Friday, February 7, 2014 at 11:14 PM To: "Haeffner, Walter, Vodafone DE" , Dave Do= lson , Martin Stiemerling , "draf= t-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Cc: Jeffrey Napper Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Walter, et al, > >While it is interesting to show all the components of 3GPP for GiLAN,=20 >but I don't think it is necessary to have all of them in the SFC use=20 >case draft. > >For example, on your Section 2.3 ("The Most common classification=20 >scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >"User name & Password". Does it mean that the "User Name & Password" >have to associated with data packets? Or to be detected by the=20 >Classification nodes? > >Linda > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >Vodafone DE >Sent: Wednesday, February 05, 2014 7:21 PM >To: Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Dave, >Thanks for your comment. We are going to include a Rel.11 TDF paragraph=20 >in -01. Possibly we will consider 2 sections: most simple case (with=20 >APN), actual most advanced case (with TDF). >Regards, >Walter > >-----Urspr=FCngliche Nachricht----- >Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >Gesendet: Dienstag, 4. Februar 2014 20:23 >An: Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Betreff: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >arrangement of mobility architecture, it neglects to show the role of=20 >the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >TS >23.203 (Version 12). > >I don't want to argue with the use cases, just the implied network=20 >architecture. > >In all of the network diagrams and examples, it should be understood=20 >that the P-GW is not the only location from which a policy-based=20 >service chain could be initiated; the standard TDF function can also=20 >initiate service chains selected by policy and traffic type. > >Section 2.1 should show an optional TDF element between the P-GW and=20 >the (S)Gi-LAN. > >A TDF communicates with a PCRF using the Sd interface, from which it=20 >receives Application Detection and Control (ADC) rules, similar to the=20 >rules deployed to the P-GW via the Gx interface. > >Aside from the APN classification scheme mentioned in section 2.3 of=20 >the draft, ADC rules can cause decisions based on application type (not=20 >just based on APN or UDP/TCP port classification). > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >Sent: Wednesday, January 29, 2014 9:46 AM >To: sfc@ietf.org >Subject: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi all, > >I wanted to raise your attention to the below quoted draft, as it=20 >wasn't posted to the SFC list. > >The draft outlines very well the use cases in mobile networks. > >Thanks, > > Martin > > >-------- Original Message -------- >Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Date: Tue, 28 Jan 2014 14:26:15 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Filename : draft-haeffner-sfc-use-case-mobility-00.txt > Pages : 17 > Date : 2014-01-28 > >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 and framework statements > 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 ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery, take care of security and privacy or > support application and business support platforms. 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 IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >_______________________________________________ >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 ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### From nobody Fri Feb 14 07:40:18 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957F51A025E for ; Fri, 14 Feb 2014 07:40:16 -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 IZ4YGMP1LBta for ; Fri, 14 Feb 2014 07:40:11 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id BCD601A0274 for ; Fri, 14 Feb 2014 07:40:10 -0800 (PST) Received: from mail144-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 15:40:09 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id DFFA4140141 for ; Fri, 14 Feb 2014 15:40:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -76 X-BigFish: VPS-76(zzbb2dI98dI9371Ic89bh146fI148cI542I1432I15caKJd799h4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail144-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(52314003)(13464003)(377454003)(52604005)(24454002)(199002)(189002)(479174003)(51704005)(55784002)(81542001)(561944002)(49866001)(50986001)(47736001)(74316001)(54356001)(47976001)(66066001)(69226001)(59766001)(77982001)(76482001)(74502001)(47446002)(74662001)(31966008)(46102001)(79102001)(81342001)(74366001)(74706001)(74876001)(53806001)(51856001)(4396001)(86362001)(65816001)(94316002)(63696002)(54316002)(76796001)(94946001)(15975445006)(76786001)(95416001)(56776001)(81816001)(93516002)(551934002)(76576001)(83072002)(85852003)(90146001)(2656002)(85306002)(80976001)(83322001)(56816005)(80022001)(93136001)(33646001)(19580395003)(87266001)(19580405001)(81686001)(95666001)(92566001)(15202345003)(87936001)(24736002)(559001)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:E66DF9D9.A3FA938B.BBC17173.82A95849.20B4C; InfoNoRecordsA:1; MX:1; LA NG:en; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1392392405889167_20842; Fri, 14 Feb 2014 15:40:05 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.241]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id CA6932C0062 for ; Fri, 14 Feb 2014 15:40:05 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 15:40:05 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 15:40:00 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 15:39:58 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 15:39:57 +0000 From: Jerome Moisand To: "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKO/ox4fmGuSHEU24oNCjTCFRY5qzkBAAgAAByYCAAABOIIAABfuAgAAQpgCAADviRoAA5W8AgAAXepA= Date: Fri, 14 Feb 2014 15:39:56 +0000 Message-ID: <739c691f09f94f27ac6f96317e0b74ab@CO2PR05MB716.namprd05.prod.outlook.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 01221E3973 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hADrnOediZfO0F5uw3KV8A93iaw Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:40:16 -0000 Jim, Joel, glad to hear you guys express such views.=20 This was a key point we were trying to convey in draft-rijsman-sfc-metadata= -considerations (section 4.8 and conclusion). See the figure below: ................. . Service Node . . . +-----------+ . +-----------+ . +-----------+ \ | Service | . | Virtual | . | Physical | | Service | Classifier| . | Service | . | Service | | Function | | . | Function | . | Function | | Layer | | . +-----------+ . +-----------+ / | | . | | . | | | | . +-----------+ . +-----------+ \ | | . | vSwitch | . | Proxy | | Service | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| or |=3D=3D=3D=3D= =3D| or |=3D=3D | Path | | Overlay . | vRouter | . | Gateway | | Layer +-----------+ Tunnel . +-----------+ . +-----------+ / | ........|........ | | | | +-----------+ +-----------+ +-----------+ \ | Underlay | | Underlay | | Underlay | | Network | Switch or |-----------| Switch or |-----| Switch or |-- | Layer | Router | | Router | | Router | | +-----------+ +-----------+ +-----------+ / Figure 8: Layers So yes, there are TWO layers here (to map Jim's words, steering is in the s= ervice path layer; exchanging context is in the service function layer). An= d they probably should be thought about more independently that what we've = seen so far in various encoding proposals. Anyway, irrespective of the solution, it seems that the problem statement n= eeds to be improved a tad to better convey those two aspects more independe= ntly. Let me try to make a rewording proposal on the corresponding e-mail t= hread later today... Tx Jerome -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, February 14, 2014 9:07 AM To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework Yes agreed Joel. Metadata is really =B3context=B2 that is consumable by any= element of a given SFC. While our SFC encapsulation will of course carry i= nformation relevant to the steering of traffic through the desired set of s= ervice functions, I would not characterize that as metadata. On 2/13/14, 7:25 PM, "Joel M. Halpern" wrote: >I only consider the first of those to be metadata. The chain=20 >identification in the service chaining header or the transport header=20 >are not metadata. Treating fields which are needed for steering as=20 >metadata induces massive confusion. can we please keep those two=20 >concepts separate?! > >Yours, >Joel > >On 2/13/14, 7:18 PM, Linda Dunbar wrote: >> >> I see two types of "metadata" being discussed here: >> >> 1. The "flow metadata", like the transactions carried by http flows. >>They are inserted by applications, or inserted by a service function=20 >>to pass some "cookies" to the next one. (many proxy based service=20 >>functions have those capability) >> >> 2. The "Service Chain metadata", that are inserted by "Chain=20 >>Classifier" or control plane to carry extra information (in additional=20 >>to Chain ID) for the purpose of controlling the sequence of functions=20 >>on a chain. >> >> Correct? >> >> IMHO, the first bullet above are specific to applications or service=20 >>functions internal processing. Many of today's proxy based service=20 >>functions make changes to data packets, some of them make those=20 >>changes for other service functions. Those changes won't be in the=20 >>Service Chain Header field. >> >> Linda >> >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee >> Sent: Thursday, February 13, 2014 2:51 PM >> To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I believe most of us agree that an out of bad signalling will not=20 >>address the majority of requirement. Also a typical http flow carries=20 >>many transactions and each can have different or additional=20 >>classification. So a metadata can not be simple connected with one=20 >>flow either. Current implementations of proxies and load balancers has=20 >>addressed this in many ways including custome header insertion. The=20 >>custom header in this case equivalent of metadata vector. >> >> I think we need an efficient way annotate actual data with inline=20 >>metadata. I also strongly believe in solving the 80% of the use case >> >> Regards >> Sumandra >> ________________________________________ >> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 >>[jmh@joelhalpern.com] >> Sent: Thursday, February 13, 2014 11:51 AM >> To: Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I know very well what GTP does in terms of correlators, and why. >> If all you need is an identifier for the subscriber, carrying a short=20 >>identifier, and using it to select the desired behavior that has been=20 >>pre-populated when the subscribers session starts works really well. >> That is part of why I am not objecting to having provision for=20 >>out-of-band metadata. >> >> However, claiming that a single such correlator is all that is needed=20 >>for even 80% of SFC cases (and I very much supporting trying to focus=20 >>on the 80% cases), just does not seem to work, given the broad range=20 >>of requirements that we have seen. >> >> Yours, >> Joel >> >> On 2/13/14, 2:35 PM, Jerome Moisand wrote: >>> Joel, >>> >>> Protocols like GTP and L2TP work exactly that, with a form of=20 >>>session correlator between the data plane and the control plane. This=20 >>>is very handy for subscriber and service management. Also if a=20 >>>correlator is defined as an opaque and unique number, then one can=20 >>>avoid some of the pitfalls you described. Long-lived metadata is=20 >>>clearly useful (and thanks for sharing, Reinaldo, will read), and=20 >>>there is clear applicability to various service chaining needs. >>> >>> Now this is just one way. The I-D Bruno referred to was just listing=20 >>>this approach as one possible way among others. I totally agree with=20 >>>you that other forms of metadata (like an outcome of the=20 >>>classification of a packet or a sequence of a few packets) may not be=20 >>>suitable for out-of-band signaling. >>> >>> Bottomline seems to be that we have too many options to choose from,=20 >>>and none of them solving it all... Tough. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 13, 2014 2:29 PM >>> To: sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> As I understand it, the tsvwg (and aeon) work is about flow metadata. >>> That is long-lived metadata of use across many packets. That does=20 >>>indeed seem well-suited to out-of-band cases. >>> >>> My concern is that in SFC, there are many cases which are at best=20 >>>badly-addressed if we insist that they be solved using out-of-band=20 >>>metadata. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>>> There is draft about transport independent metadata. >>>> >>>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi >>>> ng >>>> - >>>> 01 >>>> >>>> The complexities you mention are discussed there:=20 >>>> variable-encoding, direction, security of metadata, etc. >>>> >>>> Thanks, >>>> >>>> -RP >>>> >>>> >>>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>>> >>>>> While there are cases where out-of-band metadata makes sense,=20 >>>>> There are many cases I would not want to try to cover that way. =20 >>>>> The best examples are situations where the metadata changes from=20 >>>>> packet to packet (such as the data produced by a DPI engine for=20 >>>>> consumption by other applications in the chain.) >>>>> >>>>> More importantly, if you are putting correlators in the packet, it =20 >>>>>is still very complex if you want to use one correlator to handle =20 >>>>>metadata produced by several different entities (the initial =20 >>>>>classifer, the DPI engine, ...) You quickly end up deciding that =20 >>>>>you need several correlators. At which point we are back to=20 >>>>>variable amounts of metadata. >>>>> >>>>> The alternative is to require exceedingly specific and strong=20 >>>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>>> be a very bad idea. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>>> resend to avoid "too many recipients" warning >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>>> > wrote: >>>>>> >>>>>> There are ways to signal variable length amounts of=20 >>>>>>metadata without >>>>>> needing an additional variable-length header on each data=20 >>>>>>packet. >>>>>> >>>>>> draft-rijsman-sfc-metadata-considerations-00 discusses=20 >>>>>>some of the >>>>>> possible approaches: out-of-band signaling (congruent or >>>>>> non-congruent) or a hybrid approach using a fix-length=20 >>>>>>in-band >>>>>> correlator and out-of-band additional metadata. See=20 >>>>>>sections 3.3, >>>>>> 3.4 and 3.5 in the draft. >>>>>> >>>>>> The issue of fixed-length encoding versus variable length=20 >>>>>>encoding >>>>>> is discussion in the challenges chapter in section 4.3. I=20 >>>>>>should >>>>>> probably mention the MTU and segmentation issues as well=20 >>>>>>in that >>>>>> section. >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>>> > wrote: >>>>>> >>>>>> The variable length shim header is needed even if every >>>>>> individual piece of metadata has a fixed length. >>>>>>Different >>>>>> service chains will need different combinations of=20 >>>>>>metadata. So >>>>>> the metadata portion of the header needs to be=20 >>>>>>variable length. >>>>>> >>>>>> I think the approach of a fixed length initial part,=20 >>>>>>and a >>>>>> variable length extension part, is the right model. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>>> >>>>>> Yes, fragmentation and variable headers are=20 >>>>>>usually a really >>>>>> bad thing for forwarding performance. Let's not=20 >>>>>>forget that >>>>>> we live in a 100G-ish kind of world nowadays. >>>>>> >>>>>> Now the question should be: WHY would we want to=20 >>>>>>do that >>>>>> (variable headers leading to fragmentation issues)? >>>>>> >>>>>> For example, the type of metadata that may require >>>>>> variable-length fields might be a better candidate=20 >>>>>>for some >>>>>> out-of-band signaling mechanism. If this is service >>>>>> authorization data (e.g. a service=20 >>>>>>profile/policy), this >>>>>> sounds likely. Not 100% sure this is true for all=20 >>>>>>use cases >>>>>> though. Only a good understanding of use cases,=20 >>>>>>grounded by >>>>>> reflecting on existing network architectures (notably >>>>>> broadband, fixed or mobile), would tell us if one=20 >>>>>>approach >>>>>> or another is the most appropriate. >>>>>> >>>>>> Anyhoo, we're jumping way deep in the detailed=20 >>>>>>protocol >>>>>> design here. This seems a tad premature. >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>>> ] On Behalf Of Dave=20 >>>>>>Dolson >>>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>>> To: 'jmh@joelhalpern.com=20 >>>>>>'; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> '; >>>>>> 'mohamed.boucadair@orange.com >>>>>> '__; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>>'paulq@cisco.com >>>>>> ' >>>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>'; >>>>>> 'linda.dunbar@huawei.com=20 >>>>>>' >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> it is overall more efficient to support PMTU=20 >>>>>>discovery >>>>>> rather than fragmenting every large packet. The is=20 >>>>>>why TCP >>>>>> adopted it so early on. >>>>>> >>>>>> The fragmenting also puts huge performance burden=20 >>>>>>on the >>>>>> service functions. >>>>>> Fragmenting may also affect the ability of load=20 >>>>>>balancers to >>>>>> get each fragment to the correct destination. >>>>>> >>>>>> So PMTU discovery SHOULD be used, in my opinion.=20 >>>>>>By this I >>>>>> mean the client or server is informed that its=20 >>>>>>packets are >>>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>>> >>>>>> Some operators may wish to incur the extra cost to=20 >>>>>>hide the >>>>>> existence of the tunneling, when the elements of=20 >>>>>>the chain >>>>>> can support it, so we could consider that as an=20 >>>>>>optional >>>>>> mechanism. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>>> ] >>>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>>> To: Ron Parker >>>>> >; >>>>>> mohamed.boucadair@orange.com >>>>>> >>>>>> >>>>> >__; Dave=20 >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> ' >>>>>> >>>>> >; >>>>>>'paulq@cisco.com >>>>>> ' >>>>> > >>>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>>> ' >>>>>>; >>>>>> 'linda.dunbar@huawei.com=20 >>>>>>' >>>>>> >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I mostly agree with you Ron. I can probably come=20 >>>>>>up with >>>>>> some other variations, but your second point is=20 >>>>>>that the >>>>>> transport must deal with the issue of frame size /=20 >>>>>>fit. >>>>>> >>>>>> I would note that if we assume that the carrying=20 >>>>>>encaps >>>>>> (IPv4/v6 outer) is being fragmented, then we are=20 >>>>>>assuming >>>>>> that the exit from service chaining can and will=20 >>>>>>reassemble. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> That is an excellent point to consider when=20 >>>>>>choosing >>>>>> transport >>>>>> encapsulations. If the transport encapsulation >>>>>>is IPv4 >>>>>> or IPv6 >>>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, =20 >>>>>>etc.), then >>>>>> fragmentation and defragmentation are naturally >>>>>> supported. If the >>>>>> transport encapsulation is VLAN, MPLS, etc.,=20 >>>>>>then I >>>>>> believe one of the >>>>>> following must be true: >>>>>> >>>>>> * The end-to-end path is known to support the=20 >>>>>>resulting >>>>>> larger frames >>>>>> * A path discovery mechanism is mandated by=20 >>>>>>SFC when >>>>>> non-IP transports >>>>>> are used * An SFC-specific fragmentation=20 >>>>>>header and >>>>>> mechanisms must be >>>>>> defined (i.e., >>>>>> >>>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o >>>>>> r- >>>>>> f >>>>>> rame) >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com >>>>>> ] Sent: Thursday,=20 >>>>>>February >>>>>> 13, 2014 10:10 >>>>>> AM To: mohamed.boucadair@orange.com >>>>>> ; Dave=20 >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; Ron=20 >>>>>>Parker; >>>>>> 'paulq@cisco.com ' Cc: >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>'; >>>>>> 'linda.dunbar@huawei.com >>>>>> ' Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> There is a related complexity. I hope that we=20 >>>>>>expect to >>>>>> support IPv6. >>>>>> IPv6 explicitly prohibits network elements from >>>>>> fragmenting end user >>>>>> packets. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>>> wrote: >>>>>> >>>>>> Re-, >>>>>> >>>>>> FWIW, one of the existing architecture drafts >>>>>> includes the following >>>>>> behavior >>>>>> >>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02# >>>>>> se >>>>>> c >>>>>> tion- >>>>>> 6 >>>>>> >>>>>>=20 >>>>>>>>>>>on- >>>>>>6>): >>>>>> >>>>>> >>>>>> >>>>>> " >>>>>> >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> If adding the Service Chaining Header=20 >>>>>>would result >>>>>> in a fragmented >>>>>> packet, the classifier should include a=20 >>>>>>Service >>>>>> Chaining Header in >>>>>> each fragment. Doing so would prevent SF=20 >>>>>>Nodes to >>>>>> dedicate resource >>>>>> to handle fragments. " >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>> >>>>>> -----Message d'origine----- De : sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>'; >>>>>> 'jmh@joelhalpern.com =20 >>>>>>'; >>>>>> 'paulq@cisco.com=20 >>>>>>' Cc : >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>> '; >>>>>> 'linda.dunbar@huawei.com >>>>>> '=20 >>>>>>Objet >>>>>>: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Good point to consider fragmentation. >>>>>> >>>>>> We should design the encapsulation=20 >>>>>>such that the >>>>>> forwarding >>>>>> functions do not need to reassemble. Each >>>>>> fragment should be >>>>>> independently forwardable; some SFs=20 >>>>>>may choose >>>>>> to ignore these >>>>>> packets. >>>>>> >>>>>> Any layer 2.5 protocol like VLAN or=20 >>>>>>MPLS would >>>>>> support this. >>>>>> Otherwise, a reassembly layer could be=20 >>>>>>added >>>>>> after the forwarding >>>>>> coordinates. Think of something like=20 >>>>>>the >>>>>>IPv6 >>>>>> reassembly option >>>>>> after a GRE header, for instance. >>>>>> >>>>>> IP | GRE | reassem | frag data >>>>>> >>>>>> We could alternatively mandate the=20 >>>>>>inner IP be >>>>>> fragmented and that >>>>>> path-MTU discovery be supported. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: >>>>>> Nicolas BOUTHORS >>>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>>> ] >>>>>>Sent: >>>>>> Thursday, February 13, >>>>>> 2014 04:13 AM To: Ron Parker >>>>>> >>>>> =20 >>>>>>>; >>>>>> Dave Dolson; Joel M. Halpern >>>>>> >>>>> >; Paul Quinn >>>>>> (paulq) >>>>> > Cc: Sumandra=20 >>>>>>Majee >>>>>> ; >>>>>> sfc@ietf.org =20 >>>>>>>>>>> >; Linda Dunbar >>>>>> >>>>> > >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> If we do not enforce a fix header size=20 >>>>>>we have >>>>>> other implication. >>>>>> >>>>>> There is the question of segmentation and >>>>>> reassembly responsibility >>>>>> as well. >>>>>> >>>>>> If adding length to the service header=20 >>>>>>forces >>>>>> segmentation, then >>>>>> whose responsibility is it to=20 >>>>>>reassemble the >>>>>> payload before passing >>>>>> it to the SF. >>>>>> >>>>>> Similar question for packet re-ordering. >>>>>> >>>>>> >>>>>> =20 >>>>>>__________________________________________ From: >>>>>> Ron Parker >>>>>> [Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>>>Halpern; >>>>>> Paul Quinn >>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> Dave, >>>>>> >>>>>> Yes, that is a good point if we logically >>>>>> separate the forwarding >>>>>> function from the SFC-aware service=20 >>>>>>function, as >>>>>> we should. The >>>>>> forwarding function is concerned with=20 >>>>>>only the >>>>>> inbound transport >>>>>> header, the fixed portion of the=20 >>>>>>service header >>>>>> containing the >>>>>> chain information, and the outbound=20 >>>>>>transport >>>>>> header. The >>>>>> service function may look at the=20 >>>>>>entirety of the >>>>>> service header and >>>>>> would look at the encapsulated packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Dave=20 >>>>>>Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 5:18 PM To: Joel M. Halpern; Ron=20 >>>>>>Parker; Paul >>>>>> Quinn (paulq) Cc: >>>>>> Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: RE: >>>>>> [sfc] >>>>>> Framework >>>>>> >>>>>> The forwarding plane might not even=20 >>>>>>need to look >>>>>> at the encapsulated >>>>>> packet. >>>>>> >>>>>> For example, (if the SF Identifier is=20 >>>>>>a VLAN >>>>>> tag), an Ethernet >>>>>> switch can forward packets of the form: >>>>>>Ether | >>>>>> VLAN | BLOB. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>> Wednesday, February 12, 2014 4:30 PM To: >>>>>>Ron >>>>>> Parker; Dave Dolson; >>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>>> sfc@ietf.org ;=20 >>>>>>Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I agree as well. Yours, Joel >>>>>> >>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>> >>>>>> Hi, Dave. >>>>>> >>>>>> I Agree with your statement. And >>>>>>if the >>>>>> total length of the >>>>>> header is >>>>>> >>>>>> contained in the mandatory portion,=20 >>>>>>the hardware >>>>>> implementation can >>>>>> easily locate the encapsulated packet. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Dave Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 4:10 PM To: Ron Parker; Paul=20 >>>>>>Quinn >>>>>> (paulq) Cc: Joel M. >>>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>>> ; Linda=20 >>>>>>Dunbar >>>>>>Subject: >>>>>> RE: [sfc] Framework >>>>>> >>>>>> I think a good approach would be: >>>>>> >>>>>> The information required for=20 >>>>>>forwarding (the >>>>>> SF Identifier) should >>>>>> be in >>>>>> >>>>>> a mandatory fixed-size header. >>>>>> >>>>>> >>>>>> Optional information (if any) is=20 >>>>>>NOT to be >>>>>> used for forwarding, but >>>>>> is >>>>>> >>>>>> for consumption by one or more of the >>>>>> applications in the chain. >>>>>> >>>>>> >>>>>> Then the forwarding plane, and=20 >>>>>>even the PDP, >>>>>> can be agnostic about >>>>>> the >>>>>> >>>>>> meta-data. >>>>>> >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Ron Parker Sent: >>>>>> Wednesday, February 12, 2014 4:05=20 >>>>>>PM >>>>>>To: >>>>>> Paul Quinn (paulq) Cc: >>>>>> Joel M. Halpern; Sumandra Majee; >>>>>> sfc@ietf.org=20 >>>>>>; Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Paul, >>>>>> >>>>>> That is why I am proposing a=20 >>>>>>hybrid where >>>>>> extensions or options can >>>>>> be >>>>>> >>>>>> added but the total length is=20 >>>>>>contained in the >>>>>> fixed portion. I >>>>>> can envision certain deployments (e.g., >>>>>> Enterprise) where perhaps >>>>>> extensions are not needed and the SFC >>>>>> functionality is realized >>>>>> in hardware. And, I can envision >>>>>>certain other >>>>>> deployments >>>>>> (e.g., 3gpp) where the extension=20 >>>>>>headers add >>>>>> sufficient value to >>>>>> justify software based implementations. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Paul Quinn >>>>>> (paulq) >>>>>> [mailto:paulq@cisco.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 3:40 PM To: Ron Parker Cc:=20 >>>>>>Sumandra Majee; >>>>>> Linda Dunbar; Joel M. >>>>>> Halpern; sfc@ietf.org=20 >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Hi, >>>>>> >>>>>> We certainly need to be very=20 >>>>>>careful with >>>>>> variable length headers >>>>>> when >>>>>> >>>>>> hardware platform are in play. >>>>>> >>>>>> >>>>>> Ron, your examples of IP options=20 >>>>>>and >>>>>>v6 EH >>>>>> have both suffered from >>>>>> >>>>>> significant implementation and deployment >>>>>> hurdles due to the >>>>>> complexity and cost associated with=20 >>>>>>hardware >>>>>> support for the >>>>>> option/EH. >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> On Feb 12, 2014, at 3:10 PM, Ron=20 >>>>>>Parker >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, Sumandra. >>>>>> >>>>>> Regarding service header=20 >>>>>>flexibility, I >>>>>> completely agree. I >>>>>> might >>>>>> >>>>>> suggest a compromise between hardware >>>>>> friendliness and software >>>>>> flexibility. If the header had the >>>>>>ability to >>>>>> add extensions >>>>>> (perhaps similar to IPv6) but also had=20 >>>>>>the >>>>>> header length encoded in >>>>>> the mandatory part (like IPv4), then a=20 >>>>>>hardware >>>>>> implementation would >>>>>> be free to skip over the extensions=20 >>>>>>(in cases >>>>>> where the deployment >>>>>> justifies ignoring the extensions). >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>> Sumandra Majee >>>>>> [mailto:S.Majee@F5.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, 2014 >>>>>> 3:04 PM To: Ron Parker; Linda=20 >>>>>>Dunbar; >>>>>> Joel M. Halpern; >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> For all of those=20 >>>>>>reasons, I >>>>>> strongly support a =20 >>>>>>canonical service >>>>>> header that is=20 >>>>>>independent of >>>>>> the transport=20 >>>>>>methodology. >>>>>> >>>>>> >>>>>> >>>>>> I agree. However the format of=20 >>>>>>service >>>>>> header should be >>>>>> standardized in >>>>>> >>>>>> a way that is flexible. Some of us=20 >>>>>>would like to >>>>>> see variable length >>>>>> header that is also HW friendly. The=20 >>>>>>service >>>>>> header can be >>>>>> represented as a mandotory fixed=20 >>>>>>length header >>>>>> (like IP >>>>>> header) along with an optional=20 >>>>>>variable length >>>>>> attribute field. >>>>>> Different services can be interested in >>>>>> different metadata, for >>>>>> example subscriber ID could be of=20 >>>>>>interest in >>>>>> the mobile core >>>>>> service chain only. >>>>>> >>>>>> >>>>>> Sumandra >>>>>> >>>>>> On 2/12/14, 11:32 AM, "Ron=20 >>>>>>Parker" >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the >>>>>> architecture docs is that=20 >>>>>>the service >>>>>> function chain is built in an >>>>>> abstract manner (i.e.,=20 >>>>>>SF-A then >>>>>> SF-B >>>>>> >>>>>> then SF-C). >>>>>> >>>>>> Separately, a locator=20 >>>>>>table provides >>>>>> network location for >>>>>> each of those service=20 >>>>>>functions. >>>>>> In this way, you can >>>>>> locate the service=20 >>>>>>functions >>>>>> >>>>>> in >>>>>> >>>>>> a manner appropriate to=20 >>>>>>the type of >>>>>> transport you are >>>>>> using. If you want that to= =20 >>>>>>be >>>>>> interface+VLAN, >>>>>> gateway-IP+MPLS label=20 >>>>>>stack, IP >>>>>> >>>>>> address, >>>>>> >>>>>> GRE tunnel remote IP +=20 >>>>>>key, etc., >>>>>> you can do that. You >>>>>> can even potentially locate >>>>>> different service=20 >>>>>>functions that >>>>>> reside in the same chain with >>>>>> different flavors of >>>>>> network locators. Another >>>>>> justification to separate the >>>>>> identity of a service=20 >>>>>>function from >>>>>> its network location is >>>>>> load balancing. If, for=20 >>>>>>example, >>>>>> SF-A had 3 IP addresses, >>>>>> that would imply load=20 >>>>>>balancing to 3 >>>>>> instances using IP as a >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons,=20 >>>>>>I strongly >>>>>> support a canonical service >>>>>> header that is independent=20 >>>>>>of the >>>>>> transport >>>>>> methodology. At a=20 >>>>>>particular >>>>>> node, the decision as to >>>>>> where to go next should be=20 >>>>>>based >>>>>> solely on information=20 >>>>>>carried in >>>>>> the canonical service=20 >>>>>>header and not >>>>>> on the >>>>>> >>>>>> fields >>>>>> >>>>>> in the transport header. =20 >>>>>>That is, >>>>>> the SFC node discards >>>>>> the transport header and=20 >>>>>>extracts >>>>>> the chain ID from the >>>>>> service header. Through >>>>>> mechanisms we have not yet=20 >>>>>>begun >>>>>> to discuss, the SFC node=20 >>>>>>knows how >>>>>> to interpret the chain ID and >>>>>> ultimately how to progress =20 >>>>>>the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>>From: sfc >>>>>> =20 >>>>>>[mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org >>>>>> >>>>>>Subject: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence=20 >>>>>>below >>>>>> should be added Section=20 >>>>>>5.2 (SFC >>>>>> Classifier) to emphasize=20 >>>>>>this point. >>>>>> >>>>>> "A Service Chain=20 >>>>>>Classifier node can >>>>>> associate a unique Layer 2 >>>>>> or 3 Label (e.g. VLAN,=20 >>>>>>MPLS >>>>>>label) >>>>>> to the packets in the flow. >>>>>> Those Layer 2 or 3 Label=20 >>>>>>makes it >>>>>> easier for subsequent nodes >>>>>> along the flow path to=20 >>>>>>steer the >>>>>> flow to the service functions >>>>>> specified by the flow's =20 >>>>>>service chain." >>>>>> >>>>>> >>>>>> Linda -----Original >>>>>>Message----- >>>>>> From: sfc >>>>>> =20 >>>>>>[mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 10:20 AM To: >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the=20 >>>>>>framework >>>>>> proposal. The proposal has=20 >>>>>>a very >>>>>> specific model of the=20 >>>>>>scope of the >>>>>> transport header (that it is >>>>>> derived from, and relates=20 >>>>>>only to, >>>>>> the first service function to >>>>>> which the packet will be=20 >>>>>>directed. >>>>>> That is clearly an=20 >>>>>>operational >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to=20 >>>>>>allow other >>>>>> transport operational >>>>>> models, such as the use of=20 >>>>>>a VLAN to >>>>>> direct traffic along a >>>>>> chain. Or the use of an=20 >>>>>>MPLS label, >>>>>> or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> 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 >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 14 07:44:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2A71A02B8; Fri, 14 Feb 2014 07:44:41 -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 Ze8fqRuKzeQn; Fri, 14 Feb 2014 07:44:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 376401A028A; Fri, 14 Feb 2014 07:44: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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214154440.15318.77352.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 07:44:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/R1TnxCiLgQIZapfKeMadhXGEZ3k Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-01.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: Fri, 14 Feb 2014 15:44:42 -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 Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-01.txt Pages : 18 Date : 2014-02-14 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 07:51:41 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CAA1A02D2 for ; Fri, 14 Feb 2014 07:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpUP0wTYBAhp for ; Fri, 14 Feb 2014 07:51:32 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE21A0270 for ; Fri, 14 Feb 2014 07:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71510; q=dns/txt; s=iport; t=1392393085; x=1393602685; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0UqLShAbZurM/8RcKesH8P5thyZNlCQ6COpPVhapAAA=; b=GR3J/P6foNBbv2WHOKzAjwJqyFjjPBtSw/NvoAFUuTZ9oWWPKjFReUWf TkTOHUOwvieBcpfuWEMYid75x7z4McN+TZ7a5Ky0dSoyRvzDvO9rYeUc9 KGFIz/s7oo261C0pNIhVqpJ7/8FmkPeAsJPCDVUJ4CfklG4PSlA/s5CHi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAKs6/lKtJV2Z/2dsb2JhbABQCYMGOFeDArwwGHwWdIIlAQEBBAEBARcBCBExAgcXBAIBCA4DAQMBAQECAiMDAgICHwYLFAECBggCBAESG4dWAxENpn2ZNw2HVheBKYs2gT8oCBAiAgICgmmBSQSWQIFsgTKLLIVFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="20494924" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 14 Feb 2014 15:51:24 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1EFpOoZ012003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 15:51:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.57]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 09:51:23 -0600 From: "Jim Guichard (jguichar)" To: Jerome Moisand , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5UwnREFNrUG0aiDEicuLyqC5qyPG4AgAAqPQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYD//6Jp6oAAbhkAgAACIACAAAHIgIAAAcsAgAAEf4CAABClAIAAOgEAgAABwwCAAJG3AIAAbeMA//+vXIA= Date: Fri, 14 Feb 2014 15:51:23 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> <739c691f09f94f27ac6f96317e0b74ab@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <739c691f09f94f27ac6f96317e0b74ab@CO2PR05MB716.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.235.1] Content-Type: text/plain; charset="utf-8" Content-ID: <19E7B5BB38357A4FB81131293B811130@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hT8pnj0wPkOiVn2dfvfzXF4-1Jg Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:51:39 -0000 SGkgSmVyb21lLA0KDQpJIHRoaW5rIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcXVpbm4tc2ZjLWFyY2gvIHBvaW50cyB0aGlzDQpvdXQgcHJldHR5IHdlbGwgLSBzZWUgc2Vj dGlvbiAzLjIgYW5kIHRoZSBkZXNjcmlwdGlvbnMgZm9yIOKAnFNlcnZpY2UNCkZ1bmN0aW9uIEZv cndhcmRlcuKAnSBhbmQg4oCcU0ZDIE5ldHdvcmsgRm9yd2FyZGVy4oCdLiBXZWxjb21lIHlvdXIg Y29tbWVudHMuDQoNCk9uIDIvMTQvMTQsIDEwOjM5IEFNLCAiSmVyb21lIE1vaXNhbmQiIDxqbW9p c2FuZEBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5KaW0sIEpvZWwsIGdsYWQgdG8gaGVhciB5b3Ug Z3V5cyBleHByZXNzIHN1Y2ggdmlld3MuDQo+DQo+VGhpcyB3YXMgYSBrZXkgcG9pbnQgd2Ugd2Vy ZSB0cnlpbmcgdG8gY29udmV5IGluDQo+ZHJhZnQtcmlqc21hbi1zZmMtbWV0YWRhdGEtY29uc2lk ZXJhdGlvbnMgKHNlY3Rpb24gNC44IGFuZCBjb25jbHVzaW9uKS4NCj5TZWUgdGhlIGZpZ3VyZSBi ZWxvdzoNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgLi4uLi4uLi4uLi4uLi4uLi4NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgLiBTZXJ2aWNlIE5vZGUgIC4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgLiAgICAgICAgICAgICAgIC4NCj4gICArLS0tLS0tLS0tLS0rICAgICAgICAg LiArLS0tLS0tLS0tLS0rIC4gICArLS0tLS0tLS0tLS0rICAgXA0KPiAgIHwgU2VydmljZSAgIHwg ICAgICAgICAuIHwgVmlydHVhbCAgIHwgLiAgIHwgUGh5c2ljYWwgIHwgICB8IFNlcnZpY2UNCj4g ICB8IENsYXNzaWZpZXJ8ICAgICAgICAgLiB8IFNlcnZpY2UgICB8IC4gICB8IFNlcnZpY2UgICB8 ICAgfCBGdW5jdGlvbg0KPiAgIHwgICAgICAgICAgIHwgICAgICAgICAuIHwgRnVuY3Rpb24gIHwg LiAgIHwgRnVuY3Rpb24gIHwgICB8IExheWVyDQo+ICAgfCAgICAgICAgICAgfCAgICAgICAgIC4g Ky0tLS0tLS0tLS0tKyAuICAgKy0tLS0tLS0tLS0tKyAgIC8NCj4gICB8ICAgICAgICAgICB8ICAg ICAgICAgLiAgICB8ICAgICB8ICAgIC4gICAgICB8ICAgICB8DQo+ICAgfCAgICAgICAgICAgfCAg ICAgICAgIC4gKy0tLS0tLS0tLS0tKyAuICAgKy0tLS0tLS0tLS0tKyAgIFwNCj4gICB8ICAgICAg ICAgICB8ICAgICAgICAgLiB8IHZTd2l0Y2ggICB8IC4gICB8IFByb3h5ICAgICB8ICAgfCBTZXJ2 aWNlDQo+ICAgfCAgICAgICAgICAgfD09PT09PT09PT09fCAgIG9yICAgICAgfD09PT09fCAgIG9y ICAgICAgfD09IHwgUGF0aA0KPiAgIHwgICAgICAgICAgIHwgT3ZlcmxheSAuIHwgdlJvdXRlciAg IHwgLiAgIHwgR2F0ZXdheSAgIHwgICB8IExheWVyDQo+ICAgKy0tLS0tLS0tLS0tKyBUdW5uZWwg IC4gKy0tLS0tLS0tLS0tKyAuICAgKy0tLS0tLS0tLS0tKyAgIC8NCj4gICAgICAgICB8ICAgICAg ICAgICAgICAgLi4uLi4uLi58Li4uLi4uLi4gICAgICAgICB8DQo+ICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfA0KPiAgICstLS0tLS0tLS0tLSsgICAg ICAgICAgICstLS0tLS0tLS0tLSsgICAgICstLS0tLS0tLS0tLSsgICBcDQo+ICAgfCBVbmRlcmxh eSAgfCAgICAgICAgICAgfCBVbmRlcmxheSAgfCAgICAgfCBVbmRlcmxheSAgfCAgIHwgTmV0d29y aw0KPiAgIHwgU3dpdGNoIG9yIHwtLS0tLS0tLS0tLXwgU3dpdGNoIG9yIHwtLS0tLXwgU3dpdGNo IG9yIHwtLSB8IExheWVyDQo+ICAgfCBSb3V0ZXIgICAgfCAgICAgICAgICAgfCBSb3V0ZXIgICAg fCAgICAgfCBSb3V0ZXIgICAgfCAgIHwNCj4gICArLS0tLS0tLS0tLS0rICAgICAgICAgICArLS0t LS0tLS0tLS0rICAgICArLS0tLS0tLS0tLS0rICAgLw0KPg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDg6IExheWVycw0KPg0KPlNvIHllcywgdGhlcmUgYXJlIFRXTyBsYXll cnMgaGVyZSAodG8gbWFwIEppbSdzIHdvcmRzLCBzdGVlcmluZyBpcyBpbiB0aGUNCj5zZXJ2aWNl IHBhdGggbGF5ZXI7IGV4Y2hhbmdpbmcgY29udGV4dCBpcyBpbiB0aGUgc2VydmljZSBmdW5jdGlv biBsYXllcikuDQo+QW5kIHRoZXkgcHJvYmFibHkgc2hvdWxkIGJlIHRob3VnaHQgYWJvdXQgbW9y ZSBpbmRlcGVuZGVudGx5IHRoYXQgd2hhdA0KPndlJ3ZlIHNlZW4gc28gZmFyIGluIHZhcmlvdXMg ZW5jb2RpbmcgcHJvcG9zYWxzLg0KPg0KPkFueXdheSwgaXJyZXNwZWN0aXZlIG9mIHRoZSBzb2x1 dGlvbiwgaXQgc2VlbXMgdGhhdCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQNCj5uZWVkcyB0byBiZSBp bXByb3ZlZCBhIHRhZCB0byBiZXR0ZXIgY29udmV5IHRob3NlIHR3byBhc3BlY3RzIG1vcmUNCj5p bmRlcGVuZGVudGx5LiBMZXQgbWUgdHJ5IHRvIG1ha2UgYSByZXdvcmRpbmcgcHJvcG9zYWwgb24g dGhlDQo+Y29ycmVzcG9uZGluZyBlLW1haWwgdGhyZWFkIGxhdGVyIHRvZGF5Li4uDQo+DQo+VHgN Cj5KZXJvbWUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+KGpn dWljaGFyKQ0KPlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMTQgOTowNyBBTQ0KPlRvOiBK b2VsIE0uIEhhbHBlcm47IExpbmRhIER1bmJhcjsgc2ZjQGlldGYub3JnDQo+U3ViamVjdDogUmU6 IFtzZmNdIEZyYW1ld29yaw0KPg0KPlllcyBhZ3JlZWQgSm9lbC4gTWV0YWRhdGEgaXMgcmVhbGx5 IMKzY29udGV4dMKyIHRoYXQgaXMgY29uc3VtYWJsZSBieSBhbnkNCj5lbGVtZW50IG9mIGEgZ2l2 ZW4gU0ZDLiBXaGlsZSBvdXIgU0ZDIGVuY2Fwc3VsYXRpb24gd2lsbCBvZiBjb3Vyc2UgY2FycnkN Cj5pbmZvcm1hdGlvbiByZWxldmFudCB0byB0aGUgc3RlZXJpbmcgb2YgdHJhZmZpYyB0aHJvdWdo IHRoZSBkZXNpcmVkIHNldA0KPm9mIHNlcnZpY2UgZnVuY3Rpb25zLCBJIHdvdWxkIG5vdCBjaGFy YWN0ZXJpemUgdGhhdCBhcyBtZXRhZGF0YS4NCj4NCj5PbiAyLzEzLzE0LCA3OjI1IFBNLCAiSm9l bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+DQo+Pkkgb25seSBj b25zaWRlciB0aGUgZmlyc3Qgb2YgdGhvc2UgdG8gYmUgbWV0YWRhdGEuICBUaGUgY2hhaW4NCj4+ aWRlbnRpZmljYXRpb24gaW4gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaGVhZGVyIG9yIHRoZSB0cmFu c3BvcnQgaGVhZGVyDQo+PmFyZSBub3QgbWV0YWRhdGEuICBUcmVhdGluZyBmaWVsZHMgd2hpY2gg YXJlIG5lZWRlZCBmb3Igc3RlZXJpbmcgYXMNCj4+bWV0YWRhdGEgaW5kdWNlcyBtYXNzaXZlIGNv bmZ1c2lvbi4gIGNhbiB3ZSBwbGVhc2Uga2VlcCB0aG9zZSB0d28NCj4+Y29uY2VwdHMgc2VwYXJh dGU/IQ0KPj4NCj4+WW91cnMsDQo+PkpvZWwNCj4+DQo+Pk9uIDIvMTMvMTQsIDc6MTggUE0sIExp bmRhIER1bmJhciB3cm90ZToNCj4+Pg0KPj4+IEkgc2VlIHR3byB0eXBlcyBvZiAibWV0YWRhdGEi IGJlaW5nIGRpc2N1c3NlZCBoZXJlOg0KPj4+DQo+Pj4gICAxLiBUaGUgImZsb3cgbWV0YWRhdGEi LCBsaWtlIHRoZSB0cmFuc2FjdGlvbnMgY2FycmllZCBieSBodHRwIGZsb3dzLg0KPj4+VGhleSBh cmUgaW5zZXJ0ZWQgYnkgYXBwbGljYXRpb25zLCBvciBpbnNlcnRlZCBieSBhIHNlcnZpY2UgZnVu Y3Rpb24NCj4+PnRvIHBhc3Mgc29tZSAiY29va2llcyIgdG8gdGhlIG5leHQgb25lLiAobWFueSBw cm94eSBiYXNlZCBzZXJ2aWNlDQo+Pj5mdW5jdGlvbnMgaGF2ZSB0aG9zZSBjYXBhYmlsaXR5KQ0K Pj4+DQo+Pj4gICAyLiBUaGUgIlNlcnZpY2UgQ2hhaW4gbWV0YWRhdGEiLCB0aGF0IGFyZSBpbnNl cnRlZCBieSAiQ2hhaW4NCj4+PkNsYXNzaWZpZXIiIG9yIGNvbnRyb2wgcGxhbmUgdG8gY2Fycnkg ZXh0cmEgaW5mb3JtYXRpb24gKGluIGFkZGl0aW9uYWwNCj4+PnRvIENoYWluIElEKSBmb3IgdGhl IHB1cnBvc2Ugb2YgY29udHJvbGxpbmcgdGhlIHNlcXVlbmNlIG9mIGZ1bmN0aW9ucw0KPj4+b24g YSBjaGFpbi4NCj4+Pg0KPj4+IENvcnJlY3Q/DQo+Pj4NCj4+PiBJTUhPLCB0aGUgZmlyc3QgYnVs bGV0IGFib3ZlIGFyZSBzcGVjaWZpYyB0byBhcHBsaWNhdGlvbnMgb3Igc2VydmljZQ0KPj4+ZnVu Y3Rpb25zIGludGVybmFsIHByb2Nlc3NpbmcuIE1hbnkgb2YgdG9kYXkncyBwcm94eSBiYXNlZCBz ZXJ2aWNlDQo+Pj5mdW5jdGlvbnMgbWFrZSBjaGFuZ2VzIHRvIGRhdGEgcGFja2V0cywgc29tZSBv ZiB0aGVtIG1ha2UgdGhvc2UNCj4+PmNoYW5nZXMgZm9yIG90aGVyIHNlcnZpY2UgZnVuY3Rpb25z LiBUaG9zZSBjaGFuZ2VzIHdvbid0IGJlIGluIHRoZQ0KPj4+U2VydmljZSBDaGFpbiBIZWFkZXIg ZmllbGQuDQo+Pj4NCj4+PiBMaW5kYQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VtYW5kcmEgTWFqZWUNCj4+PiBTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMTMsIDIwMTQgMjo1MSBQTQ0KPj4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IEpl cm9tZSBNb2lzYW5kOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW3NmY10gRnJhbWV3 b3JrDQo+Pj4NCj4+PiBJIGJlbGlldmUgbW9zdCBvZiB1cyBhZ3JlZSB0aGF0IGFuIG91dCBvZiBi YWQgc2lnbmFsbGluZyB3aWxsIG5vdA0KPj4+YWRkcmVzcyB0aGUgbWFqb3JpdHkgb2YgcmVxdWly ZW1lbnQuIEFsc28gYSB0eXBpY2FsIGh0dHAgZmxvdyBjYXJyaWVzDQo+Pj5tYW55IHRyYW5zYWN0 aW9ucyBhbmQgZWFjaCBjYW4gaGF2ZSBkaWZmZXJlbnQgb3IgYWRkaXRpb25hbA0KPj4+Y2xhc3Np ZmljYXRpb24uIFNvIGEgbWV0YWRhdGEgY2FuIG5vdCBiZSBzaW1wbGUgY29ubmVjdGVkIHdpdGgg b25lDQo+Pj5mbG93IGVpdGhlci4gQ3VycmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgcHJveGllcyBh bmQgbG9hZCBiYWxhbmNlcnMgaGFzDQo+Pj5hZGRyZXNzZWQgdGhpcyBpbiBtYW55IHdheXMgaW5j bHVkaW5nIGN1c3RvbWUgaGVhZGVyIGluc2VydGlvbi4gVGhlDQo+Pj5jdXN0b20gaGVhZGVyIGlu IHRoaXMgY2FzZSBlcXVpdmFsZW50IG9mIG1ldGFkYXRhIHZlY3Rvci4NCj4+Pg0KPj4+IEkgdGhp bmsgd2UgbmVlZCBhbiBlZmZpY2llbnQgd2F5IGFubm90YXRlIGFjdHVhbCBkYXRhIHdpdGggaW5s aW5lDQo+Pj5tZXRhZGF0YS4gSSBhbHNvIHN0cm9uZ2x5IGJlbGlldmUgaW4gc29sdmluZyB0aGUg ODAlIG9mIHRoZSB1c2UgY2FzZQ0KPj4+DQo+Pj4gUmVnYXJkcw0KPj4+IFN1bWFuZHJhDQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEZyb206IHNmYyBb c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+Pltq bWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAx NCAxMTo1MSBBTQ0KPj4+IFRvOiBKZXJvbWUgTW9pc2FuZDsgc2ZjQGlldGYub3JnDQo+Pj4gU3Vi amVjdDogUmU6IFtzZmNdIEZyYW1ld29yaw0KPj4+DQo+Pj4gSSBrbm93IHZlcnkgd2VsbCB3aGF0 IEdUUCBkb2VzIGluIHRlcm1zIG9mIGNvcnJlbGF0b3JzLCBhbmQgd2h5Lg0KPj4+IElmIGFsbCB5 b3UgbmVlZCBpcyBhbiBpZGVudGlmaWVyIGZvciB0aGUgc3Vic2NyaWJlciwgY2FycnlpbmcgYSBz aG9ydA0KPj4+aWRlbnRpZmllciwgYW5kIHVzaW5nIGl0IHRvIHNlbGVjdCB0aGUgZGVzaXJlZCBi ZWhhdmlvciB0aGF0IGhhcyBiZWVuDQo+Pj5wcmUtcG9wdWxhdGVkIHdoZW4gdGhlIHN1YnNjcmli ZXJzIHNlc3Npb24gc3RhcnRzIHdvcmtzIHJlYWxseSB3ZWxsLg0KPj4+IFRoYXQgaXMgcGFydCBv ZiB3aHkgSSBhbSBub3Qgb2JqZWN0aW5nIHRvIGhhdmluZyBwcm92aXNpb24gZm9yDQo+Pj5vdXQt b2YtYmFuZCBtZXRhZGF0YS4NCj4+Pg0KPj4+IEhvd2V2ZXIsIGNsYWltaW5nIHRoYXQgYSBzaW5n bGUgc3VjaCBjb3JyZWxhdG9yIGlzIGFsbCB0aGF0IGlzIG5lZWRlZA0KPj4+Zm9yIGV2ZW4gODAl IG9mIFNGQyBjYXNlcyAoYW5kIEkgdmVyeSBtdWNoIHN1cHBvcnRpbmcgdHJ5aW5nIHRvIGZvY3Vz DQo+Pj5vbiB0aGUgODAlIGNhc2VzKSwganVzdCBkb2VzIG5vdCBzZWVtIHRvIHdvcmssIGdpdmVu IHRoZSBicm9hZCByYW5nZQ0KPj4+b2YgcmVxdWlyZW1lbnRzIHRoYXQgd2UgaGF2ZSBzZWVuLg0K Pj4+DQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+DQo+Pj4gT24gMi8xMy8xNCwgMjozNSBQTSwg SmVyb21lIE1vaXNhbmQgd3JvdGU6DQo+Pj4+IEpvZWwsDQo+Pj4+DQo+Pj4+IFByb3RvY29scyBs aWtlIEdUUCBhbmQgTDJUUCB3b3JrIGV4YWN0bHkgdGhhdCwgd2l0aCBhIGZvcm0gb2YNCj4+Pj5z ZXNzaW9uIGNvcnJlbGF0b3IgYmV0d2VlbiB0aGUgZGF0YSBwbGFuZSBhbmQgdGhlIGNvbnRyb2wg cGxhbmUuIFRoaXMNCj4+Pj5pcyB2ZXJ5IGhhbmR5IGZvciBzdWJzY3JpYmVyIGFuZCBzZXJ2aWNl IG1hbmFnZW1lbnQuIEFsc28gaWYgYQ0KPj4+PmNvcnJlbGF0b3IgaXMgZGVmaW5lZCBhcyBhbiBv cGFxdWUgYW5kIHVuaXF1ZSBudW1iZXIsIHRoZW4gb25lIGNhbg0KPj4+PmF2b2lkIHNvbWUgb2Yg dGhlIHBpdGZhbGxzIHlvdSBkZXNjcmliZWQuIExvbmctbGl2ZWQgbWV0YWRhdGEgaXMNCj4+Pj5j bGVhcmx5IHVzZWZ1bCAoYW5kIHRoYW5rcyBmb3Igc2hhcmluZywgUmVpbmFsZG8sIHdpbGwgcmVh ZCksIGFuZA0KPj4+PnRoZXJlIGlzIGNsZWFyIGFwcGxpY2FiaWxpdHkgdG8gdmFyaW91cyBzZXJ2 aWNlIGNoYWluaW5nIG5lZWRzLg0KPj4+Pg0KPj4+PiBOb3cgdGhpcyBpcyBqdXN0IG9uZSB3YXku IFRoZSBJLUQgQnJ1bm8gcmVmZXJyZWQgdG8gd2FzIGp1c3QgbGlzdGluZw0KPj4+PnRoaXMgYXBw cm9hY2ggYXMgb25lIHBvc3NpYmxlIHdheSBhbW9uZyBvdGhlcnMuIEkgdG90YWxseSBhZ3JlZSB3 aXRoDQo+Pj4+eW91IHRoYXQgb3RoZXIgZm9ybXMgb2YgbWV0YWRhdGEgKGxpa2UgYW4gb3V0Y29t ZSBvZiB0aGUNCj4+Pj5jbGFzc2lmaWNhdGlvbiBvZiBhIHBhY2tldCBvciBhIHNlcXVlbmNlIG9m IGEgZmV3IHBhY2tldHMpIG1heSBub3QgYmUNCj4+Pj5zdWl0YWJsZSBmb3Igb3V0LW9mLWJhbmQg c2lnbmFsaW5nLg0KPj4+Pg0KPj4+PiBCb3R0b21saW5lIHNlZW1zIHRvIGJlIHRoYXQgd2UgaGF2 ZSB0b28gbWFueSBvcHRpb25zIHRvIGNob29zZSBmcm9tLA0KPj4+PmFuZCBub25lIG9mIHRoZW0g c29sdmluZyBpdCBhbGwuLi4gVG91Z2guDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAx MywgMjAxNCAyOjI5IFBNDQo+Pj4+IFRvOiBzZmNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIEZyYW1ld29yaw0KPj4+Pg0KPj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSB0c3Z3 ZyAoYW5kIGFlb24pIHdvcmsgaXMgYWJvdXQgZmxvdyBtZXRhZGF0YS4NCj4+Pj4gVGhhdCBpcyBs b25nLWxpdmVkIG1ldGFkYXRhIG9mIHVzZSBhY3Jvc3MgbWFueSBwYWNrZXRzLiAgVGhhdCBkb2Vz DQo+Pj4+aW5kZWVkIHNlZW0gd2VsbC1zdWl0ZWQgdG8gb3V0LW9mLWJhbmQgY2FzZXMuDQo+Pj4+ DQo+Pj4+IE15IGNvbmNlcm4gaXMgdGhhdCBpbiBTRkMsIHRoZXJlIGFyZSBtYW55IGNhc2VzIHdo aWNoIGFyZSBhdCBiZXN0DQo+Pj4+YmFkbHktYWRkcmVzc2VkIGlmIHdlIGluc2lzdCB0aGF0IHRo ZXkgYmUgc29sdmVkIHVzaW5nIG91dC1vZi1iYW5kDQo+Pj4+bWV0YWRhdGEuDQo+Pj4+DQo+Pj4+ IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+DQo+Pj4+IE9uIDIvMTMvMTQsIDI6MjIgUE0sIFJlaW5h bGRvIFBlbm5vIChyZXBlbm5vKSB3cm90ZToNCj4+Pj4+IFRoZXJlIGlzIGRyYWZ0IGFib3V0IHRy YW5zcG9ydCBpbmRlcGVuZGVudCBtZXRhZGF0YS4NCj4+Pj4+DQo+Pj4+PiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jaG91a2lyLXRzdndnLWZsb3ctbWV0YWRhdGEtZW5jb2RpDQo+ Pj4+PiBuZw0KPj4+Pj4gLQ0KPj4+Pj4gMDENCj4+Pj4+DQo+Pj4+PiBUaGUgY29tcGxleGl0aWVz IHlvdSBtZW50aW9uIGFyZSBkaXNjdXNzZWQgdGhlcmU6DQo+Pj4+PiB2YXJpYWJsZS1lbmNvZGlu ZywgZGlyZWN0aW9uLCBzZWN1cml0eSBvZiBtZXRhZGF0YSwgZXRjLg0KPj4+Pj4NCj4+Pj4+IFRo YW5rcywNCj4+Pj4+DQo+Pj4+PiAtUlANCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gMi8xMy8xNCwg MTE6MTUgQU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToN Cj4+Pj4+DQo+Pj4+Pj4gV2hpbGUgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIG91dC1vZi1iYW5kIG1l dGFkYXRhIG1ha2VzIHNlbnNlLA0KPj4+Pj4+IFRoZXJlIGFyZSBtYW55IGNhc2VzIEkgd291bGQg bm90IHdhbnQgdG8gdHJ5IHRvIGNvdmVyIHRoYXQgd2F5Lg0KPj4+Pj4+IFRoZSBiZXN0IGV4YW1w bGVzIGFyZSBzaXR1YXRpb25zIHdoZXJlIHRoZSBtZXRhZGF0YSBjaGFuZ2VzIGZyb20NCj4+Pj4+ PiBwYWNrZXQgdG8gcGFja2V0IChzdWNoIGFzIHRoZSBkYXRhIHByb2R1Y2VkIGJ5IGEgRFBJIGVu Z2luZSBmb3INCj4+Pj4+PiBjb25zdW1wdGlvbiBieSBvdGhlciBhcHBsaWNhdGlvbnMgaW4gdGhl IGNoYWluLikNCj4+Pj4+Pg0KPj4+Pj4+IE1vcmUgaW1wb3J0YW50bHksIGlmIHlvdSBhcmUgcHV0 dGluZyBjb3JyZWxhdG9ycyBpbiB0aGUgcGFja2V0LCBpdA0KPj4+Pj4+aXMgc3RpbGwgdmVyeSBj b21wbGV4IGlmIHlvdSB3YW50IHRvIHVzZSBvbmUgY29ycmVsYXRvciB0byBoYW5kbGUNCj4+Pj4+ Pm1ldGFkYXRhIHByb2R1Y2VkIGJ5IHNldmVyYWwgZGlmZmVyZW50IGVudGl0aWVzICh0aGUgaW5p dGlhbA0KPj4+Pj4+Y2xhc3NpZmVyLCB0aGUgRFBJIGVuZ2luZSwgLi4uKSAgWW91IHF1aWNrbHkg ZW5kIHVwIGRlY2lkaW5nIHRoYXQNCj4+Pj4+PnlvdSBuZWVkIHNldmVyYWwgY29ycmVsYXRvcnMu ICBBdCB3aGljaCBwb2ludCB3ZSBhcmUgYmFjayB0bw0KPj4+Pj4+dmFyaWFibGUgYW1vdW50cyBv ZiBtZXRhZGF0YS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBhbHRlcm5hdGl2ZSBpcyB0byByZXF1aXJl IGV4Y2VlZGluZ2x5IHNwZWNpZmljIGFuZCBzdHJvbmcNCj4+Pj4+PiBjb3VwbGluZyB0byBhIG1h bmRhdGVkIG91dC1vZi1iYW5kIG1lY2hhbmlzbS4gIFRoYXQgc2VlbXMgdG8gbWUgdG8NCj4+Pj4+ PiBiZSBhIHZlcnkgYmFkIGlkZWEuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3VycywNCj4+Pj4+PiBKb2Vs DQo+Pj4+Pj4NCj4+Pj4+PiBPbiAyLzEzLzE0LCAxOjQwIFBNLCBCcnVubyBSaWpzbWFuIHdyb3Rl Og0KPj4+Pj4+PiByZXNlbmQgdG8gYXZvaWQgInRvbyBtYW55IHJlY2lwaWVudHMiIHdhcm5pbmcN Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gVGh1LCBGZWIgMTMsIDIwMTQgYXQgMTozOSBQ TSwgQnJ1bm8gUmlqc21hbg0KPj4+Pj4+PiA8YnJ1bm9yaWpzbWFuQGdtYWlsLmNvbSA8bWFpbHRv OmJydW5vcmlqc21hbkBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAg IFRoZXJlIGFyZSB3YXlzIHRvIHNpZ25hbCB2YXJpYWJsZSBsZW5ndGggYW1vdW50cyBvZg0KPj4+ Pj4+Pm1ldGFkYXRhIHdpdGhvdXQNCj4+Pj4+Pj4gICAgICAgIG5lZWRpbmcgYW4gYWRkaXRpb25h bCB2YXJpYWJsZS1sZW5ndGggaGVhZGVyIG9uIGVhY2ggZGF0YQ0KPj4+Pj4+PnBhY2tldC4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgIGRyYWZ0LXJpanNtYW4tc2ZjLW1ldGFkYXRhLWNvbnNpZGVy YXRpb25zLTAwIGRpc2N1c3Nlcw0KPj4+Pj4+PnNvbWUgb2YgdGhlDQo+Pj4+Pj4+ICAgICAgICBw b3NzaWJsZSBhcHByb2FjaGVzOiBvdXQtb2YtYmFuZCBzaWduYWxpbmcgKGNvbmdydWVudCBvcg0K Pj4+Pj4+PiAgICAgICAgbm9uLWNvbmdydWVudCkgb3IgYSBoeWJyaWQgYXBwcm9hY2ggdXNpbmcg YSBmaXgtbGVuZ3RoDQo+Pj4+Pj4+aW4tYmFuZA0KPj4+Pj4+PiAgICAgICAgY29ycmVsYXRvciBh bmQgb3V0LW9mLWJhbmQgYWRkaXRpb25hbCBtZXRhZGF0YS4gIFNlZQ0KPj4+Pj4+PnNlY3Rpb25z IDMuMywNCj4+Pj4+Pj4gICAgICAgIDMuNCBhbmQgMy41IGluIHRoZSBkcmFmdC4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgICAgIFRoZSBpc3N1ZSBvZiBmaXhlZC1sZW5ndGggZW5jb2RpbmcgdmVyc3Vz IHZhcmlhYmxlIGxlbmd0aA0KPj4+Pj4+PmVuY29kaW5nDQo+Pj4+Pj4+ICAgICAgICBpcyBkaXNj dXNzaW9uIGluIHRoZSBjaGFsbGVuZ2VzIGNoYXB0ZXIgaW4gc2VjdGlvbiA0LjMuICBJDQo+Pj4+ Pj4+c2hvdWxkDQo+Pj4+Pj4+ICAgICAgICBwcm9iYWJseSBtZW50aW9uIHRoZSBNVFUgYW5kIHNl Z21lbnRhdGlvbiBpc3N1ZXMgYXMgd2VsbA0KPj4+Pj4+PmluIHRoYXQNCj4+Pj4+Pj4gICAgICAg IHNlY3Rpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICBPbiBUaHUsIEZlYiAx MywgMjAxNCBhdCAxOjE2IFBNLCBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4+Pj4gICAgICAgIDxqbWhA am9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgIFRoZSB2YXJpYWJsZSBsZW5ndGggc2hpbSBoZWFkZXIg aXMgbmVlZGVkIGV2ZW4gaWYgZXZlcnkNCj4+Pj4+Pj4gICAgICAgICAgICBpbmRpdmlkdWFsIHBp ZWNlIG9mIG1ldGFkYXRhIGhhcyBhIGZpeGVkIGxlbmd0aC4NCj4+Pj4+Pj5EaWZmZXJlbnQNCj4+ Pj4+Pj4gICAgICAgICAgICBzZXJ2aWNlIGNoYWlucyB3aWxsIG5lZWQgZGlmZmVyZW50IGNvbWJp bmF0aW9ucyBvZg0KPj4+Pj4+Pm1ldGFkYXRhLiAgU28NCj4+Pj4+Pj4gICAgICAgICAgICB0aGUg bWV0YWRhdGEgcG9ydGlvbiBvZiB0aGUgaGVhZGVyIG5lZWRzIHRvIGJlDQo+Pj4+Pj4+dmFyaWFi bGUgbGVuZ3RoLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgIEkgdGhpbmsgdGhlIGFwcHJv YWNoIG9mIGEgZml4ZWQgbGVuZ3RoIGluaXRpYWwgcGFydCwNCj4+Pj4+Pj5hbmQgYQ0KPj4+Pj4+ PiAgICAgICAgICAgIHZhcmlhYmxlIGxlbmd0aCBleHRlbnNpb24gcGFydCwgaXMgdGhlIHJpZ2h0 IG1vZGVsLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgIFlvdXJzLA0KPj4+Pj4+PiAgICAg ICAgICAgIEpvZWwNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICBPbiAyLzEz LzE0LCAxMToxMyBBTSwgSmVyb21lIE1vaXNhbmQgd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgIFllcywgZnJhZ21lbnRhdGlvbiBhbmQgdmFyaWFibGUgaGVhZGVycyBhcmUN Cj4+Pj4+Pj51c3VhbGx5IGEgcmVhbGx5DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIGJhZCB0aGlu ZyBmb3IgZm9yd2FyZGluZyBwZXJmb3JtYW5jZS4gTGV0J3Mgbm90DQo+Pj4+Pj4+Zm9yZ2V0IHRo YXQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgd2UgbGl2ZSBpbiBhIDEwMEctaXNoIGtpbmQgb2Yg d29ybGQgbm93YWRheXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIE5vdyB0aGUg cXVlc3Rpb24gc2hvdWxkIGJlOiBXSFkgd291bGQgd2Ugd2FudCB0bw0KPj4+Pj4+PmRvIHRoYXQN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgKHZhcmlhYmxlIGhlYWRlcnMgbGVhZGluZyB0byBmcmFn bWVudGF0aW9uIGlzc3Vlcyk/DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIEZvciBl eGFtcGxlLCB0aGUgdHlwZSBvZiBtZXRhZGF0YSB0aGF0IG1heSByZXF1aXJlDQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgIHZhcmlhYmxlLWxlbmd0aCBmaWVsZHMgbWlnaHQgYmUgYSBiZXR0ZXIgY2Fu ZGlkYXRlDQo+Pj4+Pj4+Zm9yIHNvbWUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgb3V0LW9mLWJh bmQgc2lnbmFsaW5nIG1lY2hhbmlzbS4gSWYgdGhpcyBpcyBzZXJ2aWNlDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgIGF1dGhvcml6YXRpb24gZGF0YSAoZS5nLiBhIHNlcnZpY2UNCj4+Pj4+Pj5wcm9m aWxlL3BvbGljeSksIHRoaXMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgc291bmRzIGxpa2VseS4g Tm90IDEwMCUgc3VyZSB0aGlzIGlzIHRydWUgZm9yIGFsbA0KPj4+Pj4+PnVzZSBjYXNlcw0KPj4+ Pj4+PiAgICAgICAgICAgICAgICB0aG91Z2guIE9ubHkgYSBnb29kIHVuZGVyc3RhbmRpbmcgb2Yg dXNlIGNhc2VzLA0KPj4+Pj4+Pmdyb3VuZGVkIGJ5DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHJl ZmxlY3Rpbmcgb24gZXhpc3RpbmcgbmV0d29yayBhcmNoaXRlY3R1cmVzDQo+Pj4+Pj4+KG5vdGFi bHkNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgYnJvYWRiYW5kLCBmaXhlZCBvciBtb2JpbGUpLCB3 b3VsZCB0ZWxsIHVzIGlmIG9uZQ0KPj4+Pj4+PmFwcHJvYWNoDQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgIG9yIGFub3RoZXIgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgIEFueWhvbywgd2UncmUganVtcGluZyB3YXkgZGVlcCBpbiB0aGUgZGV0 YWlsZWQNCj4+Pj4+Pj5wcm90b2NvbA0KPj4+Pj4+PiAgICAgICAgICAgICAgICBkZXNpZ24gaGVy ZS4gVGhpcyBzZWVtcyBhIHRhZCBwcmVtYXR1cmUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGF2ZQ0K Pj4+Pj4+PkRvbHNvbg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMTMsIDIwMTQgMTE6MDMgQU0NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgVG86ICdqbWhA am9lbGhhbHBlcm4uY29tDQo+Pj4+Pj4+PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPic7DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICdSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuX19jb20N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPic7DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICdtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4nX187DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICdOaWNvbGFzLkJPVVRIT1JT QHFvc21vcy5jb20NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1haWx0bzpOaWNvbGFzLkJPVVRI T1JTQHFvc21vcy5jb20+JzsNCj4+Pj4+Pj4ncGF1bHFAY2lzY28uY29tDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPicNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgQ2M6ICdTLk1hamVlQEY1LmNvbSc7ICdzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj48bWFpbHRvOnNm Y0BpZXRmLm9yZz4nOw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAnbGluZGEuZHVuYmFyQGh1YXdl aS5jb20NCj4+Pj4+Pj48bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPicNCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgU3ViamVjdDogUmU6IFtzZmNdIEZyYW1ld29yaw0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICAgICAgICAgICAgICBpdCBpcyBvdmVyYWxsIG1vcmUgZWZmaWNpZW50IHRvIHN1cHBv cnQgUE1UVQ0KPj4+Pj4+PmRpc2NvdmVyeQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICByYXRoZXIg dGhhbiBmcmFnbWVudGluZyBldmVyeSBsYXJnZSBwYWNrZXQuIFRoZSBpcw0KPj4+Pj4+PndoeSBU Q1ANCj4+Pj4+Pj4gICAgICAgICAgICAgICAgYWRvcHRlZCBpdCBzbyBlYXJseSBvbi4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgVGhlIGZyYWdtZW50aW5nIGFsc28gcHV0cyBodWdl IHBlcmZvcm1hbmNlIGJ1cmRlbg0KPj4+Pj4+Pm9uIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAg ICBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgRnJhZ21lbnRpbmcg bWF5IGFsc28gYWZmZWN0IHRoZSBhYmlsaXR5IG9mIGxvYWQNCj4+Pj4+Pj5iYWxhbmNlcnMgdG8N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgZ2V0IGVhY2ggZnJhZ21lbnQgdG8gdGhlIGNvcnJlY3Qg ZGVzdGluYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIFNvIFBNVFUgZGlz Y292ZXJ5IFNIT1VMRCBiZSB1c2VkLCBpbiBteSBvcGluaW9uLg0KPj4+Pj4+PkJ5IHRoaXMgSQ0K Pj4+Pj4+PiAgICAgICAgICAgICAgICBtZWFuIHRoZSBjbGllbnQgb3Igc2VydmVyIGlzIGluZm9y bWVkIHRoYXQgaXRzDQo+Pj4+Pj4+cGFja2V0cyBhcmUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAg dG9vIGJpZyAoZm9yIElQdjYgb3IgSVB2NCB3aXRoIERGPTEpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAg ICAgICAgICAgICAgICBTb21lIG9wZXJhdG9ycyBtYXkgd2lzaCB0byBpbmN1ciB0aGUgZXh0cmEg Y29zdCB0bw0KPj4+Pj4+PmhpZGUgdGhlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIGV4aXN0ZW5j ZSBvZiB0aGUgdHVubmVsaW5nLCB3aGVuIHRoZSBlbGVtZW50cyBvZg0KPj4+Pj4+PnRoZSBjaGFp bg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBjYW4gc3VwcG9ydCBpdCwgc28gd2UgY291bGQgY29u c2lkZXIgdGhhdCBhcyBhbg0KPj4+Pj4+Pm9wdGlvbmFsDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg IG1lY2hhbmlzbS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgLURhdmUNCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIFNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAxMywgMjAxNCAxMDozMSBBTQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICBU bzogUm9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLl9fY29tDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgIDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+ Ow0KPj4+Pj4+PiAgICAgICAgICAgICAgICBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj5fXzsgRGF2ZQ0KPj4+Pj4+PkRvbHNvbjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgJ05p Y29sYXMuQk9VVEhPUlNAcW9zbW9zLmNvbQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICA8bWFpbHRv Ok5pY29sYXMuQk9VVEhPUlNAcW9zbW9zLmNvbT4nDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIDxO aWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1haWx0 bzpOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20+PjsNCj4+Pj4+Pj4ncGF1bHFAY2lzY28uY29t DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPicgPHBhdWxx QGNpc2NvLmNvbQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNv bT4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIENjOiAnUy5NYWplZUBGNS5jb20nIDxTLk1hamVl QEY1LmNvbT47ICdzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+JyA8c2ZjQGlldGYub3JnDQo+Pj4+Pj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+ PjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgJ2xpbmRhLmR1bmJhckBodWF3ZWkuY29tDQo+Pj4+ Pj4+PG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4nDQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0KPj4+Pj4+PjxtYWlsdG86bGluZGEuZHVuYmFy QGh1YXdlaS5jb20+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBTdWJqZWN0OiBSZTogW3NmY10g RnJhbWV3b3JrDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIEkgbW9zdGx5IGFncmVl IHdpdGggeW91IFJvbi4gIEkgY2FuIHByb2JhYmx5IGNvbWUNCj4+Pj4+Pj51cCB3aXRoDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgIHNvbWUgb3RoZXIgdmFyaWF0aW9ucywgYnV0IHlvdXIgc2Vjb25k IHBvaW50IGlzDQo+Pj4+Pj4+dGhhdCB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgdHJhbnNw b3J0IG11c3QgZGVhbCB3aXRoIHRoZSBpc3N1ZSBvZiBmcmFtZSBzaXplIC8NCj4+Pj4+Pj5maXQu DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIEkgd291bGQgbm90ZSB0aGF0IGlmIHdl IGFzc3VtZSB0aGF0IHRoZSBjYXJyeWluZw0KPj4+Pj4+PmVuY2Fwcw0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAoSVB2NC92NiBvdXRlcikgaXMgYmVpbmcgZnJhZ21lbnRlZCwgdGhlbiB3ZSBhcmUN Cj4+Pj4+Pj5hc3N1bWluZw0KPj4+Pj4+PiAgICAgICAgICAgICAgICB0aGF0IHRoZSBleGl0IGZy b20gc2VydmljZSBjaGFpbmluZyBjYW4gYW5kIHdpbGwNCj4+Pj4+Pj5yZWFzc2VtYmxlLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBZb3VycywNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgSm9lbA0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBPbiAyLzEzLzE0LCAxMDox OCBBTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgIEpvZWwsDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICBUaGF0IGlzIGFu IGV4Y2VsbGVudCBwb2ludCB0byBjb25zaWRlciB3aGVuDQo+Pj4+Pj4+Y2hvb3NpbmcNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgIHRyYW5zcG9ydA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgZW5jYXBzdWxhdGlvbnMuICAgSWYgdGhlIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uDQo+Pj4+ Pj4+aXMgSVB2NA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgb3IgSVB2Ng0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgYmFzZWQgKGkuZS4sIElQeC9VRFAsIElQeC9HUkUsIElQeC9VRFAv VnhMQU4sDQo+Pj4+Pj4+ZXRjLiksIHRoZW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIGZy YWdtZW50YXRpb24gYW5kIGRlZnJhZ21lbnRhdGlvbiBhcmUgbmF0dXJhbGx5DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICBzdXBwb3J0ZWQuICAgIElmIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gaXMgVkxBTiwgTVBMUywgZXRjLiwNCj4+ Pj4+Pj50aGVuIEkNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIGJlbGlldmUgb25lIG9mIHRo ZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgZm9sbG93aW5nIG11c3QgYmUgdHJ1ZToNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICogVGhlIGVuZC10by1lbmQgcGF0aCBp cyBrbm93biB0byBzdXBwb3J0IHRoZQ0KPj4+Pj4+PnJlc3VsdGluZw0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgbGFyZ2VyIGZyYW1lcw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgKiBB IHBhdGggZGlzY292ZXJ5IG1lY2hhbmlzbSBpcyBtYW5kYXRlZCBieQ0KPj4+Pj4+PlNGQyB3aGVu DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICBub24tSVAgdHJhbnNwb3J0cw0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgYXJlIHVzZWQgKiBBbiBTRkMtc3BlY2lmaWMgZnJhZ21lbnRhdGlv bg0KPj4+Pj4+PmhlYWRlciBhbmQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIG1lY2hhbmlz bXMgbXVzdCBiZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgZGVmaW5lZCAoaS5lLiwNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gU0ZDLXRyYW5zcG9ydC9TRkMtX19mcmFnbWVudGF0aW9uL1NGQy1zZXJ2 aWNlL19fb3JpZ2luYWwtcGFja2V0LW8NCj4+Pj4+Pj4gci0NCj4+Pj4+Pj4gZg0KPj4+Pj4+PiBy YW1lKQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+Pj4+Pj4+ DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLSBGcm9tOiBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg IFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0gU2VudDogVGh1cnNkYXksDQo+Pj4+Pj4+RmVi cnVhcnkNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIDEzLCAyMDE0IDEwOjEwDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICBBTSBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPjsgRGF2ZQ0KPj4+Pj4+PkRvbHNvbjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICdOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg IDxtYWlsdG86Tmljb2xhcy5CT1VUSE9SU0Bxb3Ntb3MuY29tPic7IFJvbg0KPj4+Pj4+PlBhcmtl cjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICdwYXVscUBjaXNjby5jb20gPG1haWx0bzpw YXVscUBjaXNjby5jb20+JyBDYzoNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICdTLk1hamVl QEY1LmNvbSc7ICdzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj48bWFpbHRvOnNmY0BpZXRmLm9yZz4nOw0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgJ2xpbmRhLmR1bmJhckBodWF3ZWkuY29tDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPicg U3ViamVjdDoNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIFJlOiBbc2ZjXSBGcmFtZXdvcmsN Cj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIFRoZXJlIGlzIGEgcmVsYXRlZCBj b21wbGV4aXR5LiBJIGhvcGUgdGhhdCB3ZQ0KPj4+Pj4+PmV4cGVjdCB0bw0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgc3VwcG9ydCBJUHY2Lg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg SVB2NiBleHBsaWNpdGx5IHByb2hpYml0cyBuZXR3b3JrIGVsZW1lbnRzIGZyb20NCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgIGZyYWdtZW50aW5nIGVuZCB1c2VyDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICBwYWNrZXRzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg WW91cnMsIEpvZWwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIE9uIDIvMTMv MTQsIDg6MjEgQU0sDQo+Pj4+Pj4+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICBSZS0sDQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgRldJVywgb25lIG9mIHRoZSBl eGlzdGluZyBhcmNoaXRlY3R1cmUNCj4+Pj4+Pj5kcmFmdHMNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICBpbmNsdWRlcyB0aGUgZm9sbG93aW5nDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgYmVoYXZpb3INCj4+Pj4+Pj4NCj4+Pj4+Pj4gKGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL19fZHJhZnQtYm91Y2FkYWlyLXNmYy1mcmFtZXdvcmstX18wMiMNCj4+Pj4+Pj4gc2UN Cj4+Pj4+Pj4gYw0KPj4+Pj4+PiB0aW9uLQ0KPj4+Pj4+PiA2DQo+Pj4+Pj4+DQo+Pj4+Pj4+IA0K Pj4+Pj4+PjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLWZy YW1ld29yay0wMiNzZWN0aQ0KPj4+Pj4+Pm9uLQ0KPj4+Pj4+PjY+KToNCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgIg0KPj4+Pj4+Pg0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgIDYuIEZyYWdtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICBJZiBhZGRpbmcgdGhlIFNlcnZp Y2UgQ2hhaW5pbmcgSGVhZGVyDQo+Pj4+Pj4+d291bGQgcmVzdWx0DQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgaW4gYSBmcmFnbWVudGVkDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgcGFja2V0LCB0aGUgY2xhc3NpZmllciBzaG91bGQgaW5jbHVkZSBhDQo+Pj4+Pj4+U2Vy dmljZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgIENoYWluaW5nIEhlYWRlciBpbg0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgIGVhY2ggZnJhZ21lbnQuICBEb2luZyBzbyB3 b3VsZCBwcmV2ZW50IFNGDQo+Pj4+Pj4+Tm9kZXMgdG8NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICBkZWRpY2F0ZSByZXNvdXJjZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg IHRvIGhhbmRsZSBmcmFnbWVudHMuICINCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICBDaGVlcnMsIE1lZA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBzZmMNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPl0NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgRGUgbGEg cGFydCBkZSBEYXZlIERvbHNvbiBFbnZvecOpIDoNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgamV1ZGkgMTMgZsOpdnJpZXIgMjAxNCAxMzozOSDDgCA6DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICdOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20NCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpOaWNvbGFzLkJPVVRIT1JTQHFv c21vcy5jb20+JzsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgJ1Jvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5fX2NvbQ0KPj4+Pj4+PiAgICAgICAgICAgIA0KPj4+Pj4+Pjxt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4nOw0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAnam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+Pj4+PjxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT4nOw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAncGF1bHFAY2lzY28uY29tDQo+Pj4+Pj4+PG1haWx0bzpwYXVscUBjaXNjby5jb20+JyBDYyA6 DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICdTLk1hamVlQEY1LmNvbSc7ICdz ZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+JzsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2xpbmRh LmR1bmJhckBodWF3ZWkuY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxt YWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Jw0KPj4+Pj4+Pk9iamV0DQo+Pj4+Pj4+OiBS ZToNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgW3NmY10gRnJhbWV3b3JrDQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2QgcG9pbnQgdG8g Y29uc2lkZXIgZnJhZ21lbnRhdGlvbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgV2Ugc2hvdWxkIGRlc2lnbiB0aGUgZW5jYXBzdWxhdGlvbg0KPj4+Pj4+PnN1 Y2ggdGhhdCB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yd2FyZGlu Zw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBmdW5jdGlvbnMgZG8gbm90IG5l ZWQgdG8gcmVhc3NlbWJsZS4NCj4+Pj4+Pj5FYWNoDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGZyYWdtZW50IHNob3VsZCBiZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpbmRlcGVuZGVudGx5IGZvcndhcmRhYmxlOyBzb21lIFNGcw0KPj4+Pj4+Pm1heSBj aG9vc2UNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gaWdub3JlIHRoZXNl DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhY2tldHMuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFueSBsYXllciAyLjUgcHJvdG9jb2wg bGlrZSBWTEFOIG9yDQo+Pj4+Pj4+TVBMUyB3b3VsZA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzdXBwb3J0IHRoaXMuDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE90aGVyd2lzZSwgYSByZWFzc2VtYmx5IGxheWVyIGNvdWxkIGJlDQo+Pj4+Pj4+YWRkZWQN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgYWZ0ZXIgdGhlIGZvcndhcmRpbmcN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgY29vcmRpbmF0ZXMuIFRoaW5rIG9m IHNvbWV0aGluZyBsaWtlDQo+Pj4+Pj4+dGhlDQo+Pj4+Pj4+SVB2Ng0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZWFzc2VtYmx5IG9wdGlvbg0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhZnRlciBhIEdSRSBoZWFkZXIsIGZvciBpbnN0YW5jZS4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSVAgfCBHUkUgfCByZWFzc2Vt IHwgZnJhZyBkYXRhDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IFdlIGNvdWxkIGFsdGVybmF0aXZlbHkgbWFuZGF0ZSB0aGUNCj4+Pj4+Pj5pbm5lciBJUCBiZQ0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBmcmFnbWVudGVkIGFuZCB0aGF0DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGgtTVRVIGRpc2NvdmVyeSBiZSBz dXBwb3J0ZWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gRnJv bToNCj4+Pj4+Pj4gTmljb2xhcyBCT1VUSE9SUw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbbWFpbHRvOk5pY29sYXMuQk9VVEhPUlNAX19xb3Ntb3MuY29tDQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86Tmljb2xhcy5CT1VUSE9SU0Bxb3Ntb3Mu Y29tPl0NCj4+Pj4+Pj5TZW50Og0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBU aHVyc2RheSwgRmVicnVhcnkgMTMsDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IDIwMTQgMDQ6MTMgQU0gVG86IFJvbiBQYXJrZXINCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5fX2NvbQ0KPj4+Pj4+PiAgICAg ICAgICAgIA0KPj4+Pj4+PjxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+ Ow0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZlIERvbHNvbjsgSm9lbCBN LiBIYWxwZXJuDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxqbWhAam9lbGhh bHBlcm4uY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+OyBQYXVsDQo+Pj4+Pj4+UXVpbm4NCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHBhdWxxKSA8cGF1bHFAY2lzY28uY29tDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4gQ2M6IFN1bWFu ZHJhDQo+Pj4+Pj4+TWFqZWUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPFMu TWFqZWVARjUuY29tPjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+Pj4+PjxzZmNAaWV0Zi5vcmcNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpzZmNAaWV0Zi5vcmc+PjsgTGlu ZGEgRHVuYmFyDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRv OmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3ViamVjdDogUmU6IFtzZmNdIEZyYW1ld29yaw0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJZiB3ZSBkbyBub3QgZW5mb3JjZSBhIGZpeCBoZWFkZXIg c2l6ZQ0KPj4+Pj4+PndlIGhhdmUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg b3RoZXIgaW1wbGljYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZiBzZWdtZW50YXRpb24NCj4+Pj4+Pj5hbmQN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhc3NlbWJseSByZXNwb25zaWJp bGl0eQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcyB3ZWxsLg0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiBhZGRpbmcgbGVuZ3RoIHRv IHRoZSBzZXJ2aWNlIGhlYWRlcg0KPj4+Pj4+PmZvcmNlcw0KPj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzZWdtZW50YXRpb24sIHRoZW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2hvc2UgcmVzcG9uc2liaWxpdHkgaXMgaXQgdG8NCj4+Pj4+Pj5yZWFzc2Vt YmxlIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXlsb2FkIGJlZm9y ZSBwYXNzaW5nDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0IHRvIHRoZSBT Ri4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgU2ltaWxhciBx dWVzdGlvbiBmb3IgcGFja2V0IHJlLW9yZGVyaW5nLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ PiAgICAgICAgICAgIA0KPj4+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBGcm9tOg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFy a2VyDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuX19jb20NCj4+Pj4+Pj4gICAgICAgICAgICANCj4+Pj4+Pj48bWFpbHRvOlJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+XSBTZW50Og0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLA0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAyMDE0IDExOjI1IFBNIFRvOiBEYXZlIERvbHNvbjsgSm9lbCBN Lg0KPj4+Pj4+PkhhbHBlcm47DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBh dWwgUXVpbm4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgKHBhdWxxKSBDYzog U3VtYW5kcmEgTWFqZWU7IHNmY0BpZXRmLm9yZw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bWFpbHRvOnNmY0BpZXRmLm9yZz47IExpbmRhIER1bmJhcg0KPj4+Pj4+PlN1Ympl Y3Q6DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlOiBbc2ZjXSBGcmFtZXdv cmsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgRGF2ZSwNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgWWVzLCB0aGF0IGlzIGEg Z29vZCBwb2ludCBpZiB3ZQ0KPj4+Pj4+PmxvZ2ljYWxseQ0KPj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzZXBhcmF0ZSB0aGUgZm9yd2FyZGluZw0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBmdW5jdGlvbiBmcm9tIHRoZSBTRkMtYXdhcmUgc2VydmljZQ0KPj4+ Pj4+PmZ1bmN0aW9uLCBhcw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICB3ZSBz aG91bGQuICAgVGhlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvcndhcmRp bmcgZnVuY3Rpb24gaXMgY29uY2VybmVkIHdpdGgNCj4+Pj4+Pj5vbmx5IHRoZQ0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBpbmJvdW5kIHRyYW5zcG9ydA0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBoZWFkZXIsIHRoZSBmaXhlZCAgcG9ydGlvbiBvZiB0aGUN Cj4+Pj4+Pj5zZXJ2aWNlIGhlYWRlcg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb250YWluaW5nIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGFp biBpbmZvcm1hdGlvbiwgYW5kIHRoZSBvdXRib3VuZA0KPj4+Pj4+PnRyYW5zcG9ydA0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBoZWFkZXIuICAgIFRoZQ0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzZXJ2aWNlIGZ1bmN0aW9uIG1heSBsb29rIGF0IHRoZQ0K Pj4+Pj4+PmVudGlyZXR5IG9mIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzZXJ2aWNlIGhlYWRlciBhbmQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg d291bGQgbG9vayBhdCB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy b206IERhdmUNCj4+Pj4+Pj5Eb2xzb24NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgW21haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPl0gU2VudDoNCj4+Pj4+Pj5X ZWRuZXNkYXksDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDEy LCAyMDE0DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDU6MTggUE0gVG86IEpv ZWwgTS4gSGFscGVybjsgUm9uDQo+Pj4+Pj4+UGFya2VyOyBQYXVsDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFF1aW5uIChwYXVscSkgQ2M6DQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN1bWFuZHJhIE1hamVlOyBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpzZmNAaWV0Zi5vcmc+OyBMaW5kYSBEdW5i YXINCj4+Pj4+Pj5TdWJqZWN0OiBSRToNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgW3NmY10NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbWV3b3JrDQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBmb3J3YXJkaW5n IHBsYW5lIG1pZ2h0IG5vdCBldmVuDQo+Pj4+Pj4+bmVlZCB0byBsb29rDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGF0IHRoZSBlbmNhcHN1bGF0ZWQNCj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgcGFja2V0Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgKGlmIHRoZSBTRiBJZGVudGlmaWVyIGlzDQo+ Pj4+Pj4+YSBWTEFODQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhZyksIGFu IEV0aGVybmV0DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN3aXRjaCBjYW4g Zm9yd2FyZCBwYWNrZXRzIG9mIHRoZSBmb3JtOg0KPj4+Pj4+PkV0aGVyIHwNCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgVkxBTiB8IEJMT0IuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIEZyb206IHNmYw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuIFNlbnQ6DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlZG5lc2RheSwgRmVicnVhcnkgMTIs IDIwMTQgNDozMCBQTSBUbzoNCj4+Pj4+Pj5Sb24NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgUGFya2VyOyBEYXZlIERvbHNvbjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgUGF1bCBRdWlubiAocGF1bHEpIENjOiBTdW1hbmRyYSBNYWplZTsNCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPjsNCj4+Pj4+Pj5MaW5kYSBEdW5iYXINCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3ViamVjdDogUmU6IFtzZmNdIEZyYW1ld29yaw0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJIGFncmVlIGFzIHdlbGwuIFlvdXJzLCBKb2VsDQo+Pj4+ Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIDIvMTIvMTQsIDQ6MjQg UE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBIaSwgRGF2ZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEkgIEFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQuICAgIEFuZA0KPj4+ Pj4+PmlmIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG90YWwg bGVuZ3RoIG9mIHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGVh ZGVyIGlzDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRh aW5lZCBpbiB0aGUgbWFuZGF0b3J5IHBvcnRpb24sDQo+Pj4+Pj4+dGhlIGhhcmR3YXJlDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGltcGxlbWVudGF0aW9uIGNhbg0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBlYXNpbHkgbG9jYXRlIHRoZSBlbmNhcHN1bGF0 ZWQgcGFja2V0Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOg0KPj4+Pj4+ PkRhdmUgRG9sc29uDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbbWFp bHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPl0gU2VudDoNCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlZG5lc2RheSwgRmVicnVhcnkgMTIsDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDE0IDQ6MTAgUE0gVG86IFJvbiBQ YXJrZXI7IFBhdWwNCj4+Pj4+Pj5RdWlubg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKHBhdWxxKSBDYzogSm9lbCBNLg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSGFscGVybjsgU3VtYW5kcmEgTWFqZWU7DQo+Pj4+Pj4+c2ZjQGlldGYub3Jn DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnNmY0BpZXRm Lm9yZz47IExpbmRhDQo+Pj4+Pj4+RHVuYmFyDQo+Pj4+Pj4+U3ViamVjdDoNCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJFOiBbc2ZjXSBGcmFtZXdvcmsNCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEkgdGhpbmsgYSBnb29kIGFw cHJvYWNoIHdvdWxkIGJlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIGZvcg0KPj4+Pj4+PmZvcndhcmRpbmcg KHRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0YgSWRlbnRpZmll cikgc2hvdWxkDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBpbg0K Pj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIG1hbmRhdG9yeSBm aXhlZC1zaXplIGhlYWRlci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE9wdGlvbmFsIGluZm9ybWF0aW9uIChpZiBhbnkpIGlzDQo+Pj4+ Pj4+Tk9UIHRvIGJlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2Vk IGZvciBmb3J3YXJkaW5nLCBidXQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGlzDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciBj b25zdW1wdGlvbiBieSBvbmUgb3IgbW9yZSBvZiB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgYXBwbGljYXRpb25zIGluIHRoZSBjaGFpbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZW4gdGhlIGZvcndhcmRp bmcgcGxhbmUsIGFuZA0KPj4+Pj4+PmV2ZW4gdGhlIFBEUCwNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNhbiBiZSBhZ25vc3RpYyBhYm91dA0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhlDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG1ldGEtZGF0YS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC1EYXZlDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSBGcm9tOiBzZmMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT24gQmVoYWxmIE9mIFJvbiBQYXJrZXIgU2VudDoNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlZG5lc2RheSwgRmVicnVhcnkg MTIsIDIwMTQgNDowNQ0KPj4+Pj4+PlBNDQo+Pj4+Pj4+VG86DQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQYXVsIFF1aW5uIChwYXVscSkgQ2M6DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2VsIE0uIEhhbHBlcm47IFN1bWFuZHJhIE1hamVl Ow0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ZjQGlldGYub3JnDQo+ Pj4+Pj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+OyAgTGluZGEgRHVuYmFyDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJqZWN0OiBSZTogW3NmY10gRnJhbWV3b3JrDQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQYXVsLA0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhdCBpcyB3aHkg SSBhbSBwcm9wb3NpbmcgYQ0KPj4+Pj4+Pmh5YnJpZCB3aGVyZQ0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9ucyBvciBvcHRpb25zIGNhbg0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgYWRkZWQgYnV0IHRoZSB0b3RhbCBsZW5ndGggaXMNCj4+Pj4+ Pj5jb250YWluZWQgaW4gdGhlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZp eGVkIHBvcnRpb24uICAgSQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYW4g ZW52aXNpb24gY2VydGFpbiBkZXBsb3ltZW50cyAoZS5nLiwNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgRW50ZXJwcmlzZSkgd2hlcmUgcGVyaGFwcw0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBleHRlbnNpb25zIGFyZSBub3QgbmVlZGVkIGFuZCB0aGUgU0ZD DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uYWxpdHkgaXMgcmVh bGl6ZWQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gaGFyZHdhcmUuICAg QW5kLCBJIGNhbiBlbnZpc2lvbg0KPj4+Pj4+PmNlcnRhaW4gb3RoZXINCj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgZGVwbG95bWVudHMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgKGUuZy4sIDNncHApIHdoZXJlIHRoZSBleHRlbnNpb24NCj4+Pj4+Pj5oZWFk ZXJzIGFkZA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWZmaWNpZW50IHZh bHVlIHRvDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGp1c3RpZnkgc29mdHdh cmUgYmFzZWQgaW1wbGVtZW50YXRpb25zLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSBGcm9tOg0KPj4+Pj4+PlBhdWwgUXVpbm4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChwYXVscSkNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFttYWlsdG86cGF1bHFAY2lzY28uY29tDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT5dIFNlbnQ6DQo+Pj4+Pj4+V2VkbmVzZGF5 LA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMTIsIDIw MTQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM6NDAgUE0gVG86IFJv biBQYXJrZXIgQ2M6IA0KPj4+Pj4+PlN1bWFuZHJhIE1hamVlOw0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTGluZGEgRHVuYmFyOyBKb2VsIE0uDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcgDQo+Pj4+Pj4+ PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTdWJqZWN0OiBSZTogW3NmY10gRnJhbWV3b3JrDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBIaSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdlIGNlcnRhaW5seSBuZWVkIHRvIGJlIHZlcnkgDQo+Pj4+ Pj4+Y2FyZWZ1bCB3aXRoDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2 YXJpYWJsZSBsZW5ndGggaGVhZGVycw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgd2hlbg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBo YXJkd2FyZSBwbGF0Zm9ybSBhcmUgaW4gcGxheS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbiwgeW91ciBleGFtcGxlcyBvZiBJUCBv cHRpb25zIA0KPj4+Pj4+PmFuZA0KPj4+Pj4+PnY2IEVIDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBoYXZlIGJvdGggc3VmZmVyZWQgZnJvbQ0KPj4+Pj4+Pg0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWduaWZpY2FudCBpbXBsZW1lbnRhdGlvbiBh bmQgDQo+Pj4+Pj4+ZGVwbG95bWVudA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBodXJkbGVzIGR1ZSB0byB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29tcGxleGl0eSBhbmQgY29zdCBhc3NvY2lhdGVkIHdpdGggDQo+Pj4+Pj4+aGFyZHdhcmUNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydCBmb3IgdGhlDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbi9FSC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBhdWwNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIEZlYiAxMiwgMjAxNCwgYXQg MzoxMCBQTSwgUm9uIA0KPj4+Pj4+PlBhcmtlcg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5fX2NvbQ0KPj4+Pj4+Pg0K Pj4+Pj4+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZToNCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIaSwgU3Vt YW5kcmEuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUmVnYXJkaW5nIHNlcnZpY2UgaGVhZGVyIA0KPj4+Pj4+PmZsZXhpYmlsaXR5LCBJDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGxldGVseSBhZ3JlZS4g ICBJDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWlnaHQNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VnZ2VzdCBhIGNvbXBy b21pc2UgYmV0d2VlbiBoYXJkd2FyZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmcmllbmRsaW5lc3MgYW5kIHNvZnR3YXJlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGZsZXhpYmlsaXR5LiAgICBJZiB0aGUgaGVhZGVyIGhhZCB0aGUNCj4+Pj4+Pj5hYmls aXR5IHRvDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFkZCBleHRlbnNpb25z DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwZXJoYXBzIHNpbWlsYXIgdG8g SVB2NikgYnV0IGFsc28gaGFkIA0KPj4+Pj4+PnRoZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBoZWFkZXIgbGVuZ3RoIGVuY29kZWQgaW4NCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIG1hbmRhdG9yeSBwYXJ0IChsaWtlIElQdjQpLCB0aGVuIGEgDQo+ Pj4+Pj4+aGFyZHdhcmUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGVt ZW50YXRpb24gd291bGQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgZnJl ZSB0byBza2lwIG92ZXIgdGhlIGV4dGVuc2lvbnMgDQo+Pj4+Pj4+KGluIGNhc2VzDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoZXJlIHRoZSBkZXBsb3ltZW50DQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGp1c3RpZmllcyBpZ25vcmluZyB0aGUgZXh0ZW5z aW9ucykuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbToNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdW1hbmRyYSBNYWplZQ0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFttYWlsdG86Uy5NYWpl ZUBGNS5jb20NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFp bHRvOlMuTWFqZWVARjUuY29tPl0gU2VudDoNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMzowNCBQTSBUbzogUm9uIFBhcmtlcjsgTGlu ZGEgDQo+Pj4+Pj4+RHVuYmFyOw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEpvZWwgTS4gSGFscGVybjsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzZmNAaWV0Zi5vcmcgDQo+Pj4+Pj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ViamVjdDogUmU6IFtz ZmNdIEZyYW1ld29yaw0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRm9yIGFsbCBvZiB0aG9zZSANCj4+Pj4+Pj5yZWFzb25zLCBJDQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJvbmds eSBzdXBwb3J0IGEgIA0KPj4+Pj4+PmNhbm9uaWNhbCBzZXJ2aWNlDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBoZWFkZXIgdGhhdCBpcyANCj4+Pj4+ Pj5pbmRlcGVuZGVudCBvZg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlIHRyYW5zcG9ydCANCj4+Pj4+Pj5tZXRob2RvbG9neS4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJIGFncmVlLiBIb3dldmVyIHRoZSBmb3JtYXQgb2YgDQo+Pj4+Pj4+c2VydmljZQ0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlYWRlciBzaG91bGQgYmUN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFuZGFyZGl6ZWQg aW4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgYSB3YXkgdGhh dCBpcyBmbGV4aWJsZS4gU29tZSBvZiB1cyANCj4+Pj4+Pj53b3VsZCBsaWtlIHRvDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlZSB2YXJpYWJsZSBsZW5ndGgNCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgaGVhZGVyIHRoYXQgaXMgYWxzbyBIVyBmcmllbmRs eS4gVGhlIA0KPj4+Pj4+PnNlcnZpY2UNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgaGVhZGVyIGNhbiBiZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXBy ZXNlbnRlZCBhcyBhIG1hbmRvdG9yeSBmaXhlZCANCj4+Pj4+Pj5sZW5ndGggaGVhZGVyDQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsaWtlIElQDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGhlYWRlcikgYWxvbmcgd2l0aCBhbiBvcHRpb25hbCANCj4+Pj4+ Pj52YXJpYWJsZSBsZW5ndGgNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgYXR0 cmlidXRlIGZpZWxkLg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBEaWZmZXJl bnQgc2VydmljZXMgY2FuIGJlIGludGVyZXN0ZWQgaW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgZGlmZmVyZW50IG1ldGFkYXRhLCBmb3INCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgZXhhbXBsZSBzdWJzY3JpYmVyIElEIGNvdWxkIGJlIG9mIA0KPj4+Pj4+ PmludGVyZXN0IGluDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBtb2Jp bGUgY29yZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXJ2aWNlIGNoYWlu IG9ubHkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgU3VtYW5kcmENCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPbiAyLzEyLzE0LCAxMTozMiBBTSwgIlJvbiANCj4+Pj4+Pj5QYXJr ZXIiDQo+Pj4+Pj4+DQo+Pj4+Pj4+IDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuX19jb20N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIExpbmRhLA0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBNeSBpbnRlcnByZXRhdGlvbiBvZiB0aGUNCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJjaGl0ZWN0dXJlIGRvY3MgaXMgdGhhdCAN Cj4+Pj4+Pj50aGUgIHNlcnZpY2UNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZnVuY3Rpb24gY2hhaW4gaXMgYnVpbHQgaW4gDQo+Pj4+Pj4+YW4NCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJzdHJhY3QgbWFubmVy IChpLmUuLCANCj4+Pj4+Pj5TRi1BIHRoZW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU0YtQg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0aGVuIFNGLUMpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTZXBhcmF0ZWx5LCBhIGxvY2F0b3IgDQo+Pj4+Pj4+dGFi bGUgcHJvdmlkZXMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbmV0d29yayBsb2NhdGlvbiBmb3INCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZWFjaCBvZiB0aG9zZSBzZXJ2aWNlIA0KPj4+Pj4+PmZ1bmN0aW9ucy4N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW4gdGhpcyB3 YXksIHlvdSBjYW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbG9jYXRlIHRoZSBzZXJ2aWNlIA0KPj4+Pj4+PmZ1bmN0aW9ucw0KPj4+Pj4+Pg0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIG1hbm5lciBhcHByb3ByaWF0ZSB0byAN Cj4+Pj4+Pj50aGUgdHlwZSBvZg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0cmFuc3BvcnQgeW91IGFyZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB1c2luZy4gICBJZiB5b3Ugd2FudCB0aGF0IA0KPj4+Pj4+PnRv IA0KPj4+Pj4+PmJlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGludGVyZmFjZStWTEFOLA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBnYXRld2F5LUlQK01QTFMgbGFiZWwgDQo+Pj4+Pj4+c3RhY2ssICBJUA0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzLA0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHUkUgdHVu bmVsIHJlbW90ZSBJUCArIA0KPj4+Pj4+PmtleSwgZXRjLiwNCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgeW91IGNhbiBkbyB0aGF0LiAgICBZb3UNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FuIGV2ZW4gcG90ZW50 aWFsbHkgbG9jYXRlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRpZmZlcmVudCBzZXJ2aWNlIA0KPj4+Pj4+PmZ1bmN0aW9ucyB0aGF0DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlc2lkZSBpbiB0aGUgc2FtZSBj aGFpbiANCj4+Pj4+Pj53aXRoDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGRpZmZlcmVudCBmbGF2b3JzIG9mDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG5ldHdvcmsgbG9jYXRvcnMuICAgIEFub3RoZXINCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAganVzdGlmaWNhdGlvbiB0 byBzZXBhcmF0ZSANCj4+Pj4+Pj50aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaWRlbnRpdHkgb2YgYSBzZXJ2aWNlIA0KPj4+Pj4+PmZ1bmN0aW9uIGZy b20NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXRzIG5l dHdvcmsgbG9jYXRpb24gaXMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbG9hZCBiYWxhbmNpbmcuICAgSWYsIGZvciANCj4+Pj4+Pj5leGFtcGxlLA0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTRi1BIGhhZCAzIElQ IGFkZHJlc3NlcywNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdGhhdCB3b3VsZCBpbXBseSBsb2FkIA0KPj4+Pj4+PmJhbGFuY2luZyB0byAzDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluc3RhbmNlcyB1c2luZyBJ UCBhcyBhDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRy YW5zcG9ydCBsYXllci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRm9yIGFsbCBvZiB0aG9zZSByZWFzb25zLCANCj4+Pj4+Pj5JIHN0cm9u Z2x5DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1cHBv cnQgYSBjYW5vbmljYWwgc2VydmljZQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBoZWFkZXIgdGhhdCBpcyBpbmRlcGVuZGVudCANCj4+Pj4+Pj5vZiB0aGUN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0 DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1ldGhvZG9s b2d5LiAgICBBdCBhIA0KPj4+Pj4+PnBhcnRpY3VsYXINCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbm9kZSwgdGhlIGRlY2lzaW9uIGFzIHRvDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoZXJlIHRvIGdvIG5leHQg c2hvdWxkIGJlIA0KPj4+Pj4+PmJhc2VkDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNvbGVseSBvbiBpbmZvcm1hdGlvbiANCj4+Pj4+Pj5jYXJyaWVkIGlu DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBjYW5v bmljYWwgc2VydmljZSANCj4+Pj4+Pj5oZWFkZXIgYW5kIG5vdA0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbiB0aGUNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgZmllbGRzDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIHRoZSB0cmFuc3BvcnQgaGVhZGVyLiAg IA0KPj4+Pj4+PlRoYXQgaXMsDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoZSBTRkMgbm9kZSBkaXNjYXJkcw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0aGUgdHJhbnNwb3J0IGhlYWRlciBhbmQgDQo+Pj4+Pj4+ ZXh0cmFjdHMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGhlIGNoYWluIElEIGZyb20gdGhlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNlcnZpY2UgaGVhZGVyLiAgICBUaHJvdWdoDQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lY2hhbmlzbXMgd2UgaGF2ZSBub3QgeWV0 IA0KPj4+Pj4+PmJlZ3VuDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRvIGRpc2N1c3MsIHRoZSBTRkMgbm9kZSANCj4+Pj4+Pj5rbm93cyBob3cNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gaW50ZXJwcmV0IHRo ZSBjaGFpbiBJRCANCj4+Pj4+Pj5hbmQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdWx0aW1hdGVseSBob3cgdG8gcHJvZ3Jlc3MgIA0KPj4+Pj4+PnRoZSBw YWNrZXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PkZy b206IHNmYw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj5bbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+PjxtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBCZWhhbGYgT2YgTGluZGEgRHVuYmFyDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgDQo+Pj4+Pj4+MTIs IDIwMTQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTI6 MDEgUE0gVG86IEpvZWwgTS4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSGFscGVybjsgc2ZjQGlldGYub3JnDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+Pj4+PlN1Ympl Y3Q6IFJlOg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb c2ZjXSBGcmFtZXdvcmsNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQWdyZWUgd2l0aCBKb2VsJ3Mgc3RhdGVtZW50Lg0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIGEgc2lt cGxlIHNlbnRlbmNlIA0KPj4+Pj4+PmJlbG93DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBhZGRlZCBTZWN0aW9uIA0KPj4+Pj4+PjUuMiAo U0ZDDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENsYXNz aWZpZXIpIHRvIGVtcGhhc2l6ZSANCj4+Pj4+Pj50aGlzIHBvaW50Lg0KPj4+Pj4+Pg0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQSBTZXJ2aWNlIENoYWlu IA0KPj4+Pj4+PkNsYXNzaWZpZXIgbm9kZSBjYW4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYXNzb2NpYXRlIGEgdW5pcXVlIExheWVyIDINCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3IgMyBMYWJlbCAoZS5nLiBW TEFOLCANCj4+Pj4+Pj5NUExTDQo+Pj4+Pj4+bGFiZWwpDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBwYWNrZXRzIGluIHRoZSBmbG93Lg0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaG9zZSBMYXllciAy IG9yIDMgTGFiZWwgDQo+Pj4+Pj4+bWFrZXMgaXQNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZWFzaWVyIGZvciBzdWJzZXF1ZW50IG5vZGVzDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsb25nIHRoZSBmbG93IHBh dGggdG8gDQo+Pj4+Pj4+c3RlZXIgdGhlDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGZsb3cgdG8gdGhlIHNlcnZpY2UgDQo+Pj4+Pj4+ZnVuY3Rpb25zDQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmllZCBi eSB0aGUgZmxvdydzICANCj4+Pj4+Pj5zZXJ2aWNlIGNoYWluLiINCj4+Pj4+Pj4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGluZGEgLS0t LS1PcmlnaW5hbA0KPj4+Pj4+Pk1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGcm9tOiBzZmMNCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+W21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+ Pj4+Pj48bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gT24NCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IA0KPj4+Pj4+PjEyLCAyMDE0DQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDEwOjIwIEFNIFRvOg0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZmNAaWV0Zi5vcmcgDQo+Pj4+Pj4+PG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFN1YmplY3Q6IFtzZmNdIEZyYW1ld29yaw0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHdhcyBsb29raW5nIGF0IHRoZSANCj4+ Pj4+Pj5mcmFtZXdvcmsNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgcHJvcG9zYWwuIFRoZSBwcm9wb3NhbCBoYXMgDQo+Pj4+Pj4+YSB2ZXJ5DQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljIG1vZGVsIG9m IHRoZSANCj4+Pj4+Pj5zY29wZSBvZiB0aGUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0IGhlYWRlciAodGhhdCBpdCBpcw0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXJpdmVkIGZyb20sIGFuZCBy ZWxhdGVzIA0KPj4+Pj4+Pm9ubHkgdG8sDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSBmaXJzdCBzZXJ2aWNlIGZ1bmN0aW9uIA0KPj4+Pj4+PnRvDQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIHRoZSBw YWNrZXQgd2lsbCBiZSANCj4+Pj4+Pj5kaXJlY3RlZC4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVGhhdCBpcyBjbGVhcmx5IGFuIA0KPj4+Pj4+Pm9wZXJh dGlvbmFsDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1v ZGVsIHdlIG5lZWQgdG8gc3VwcG9ydC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSG93ZXZlciwgSSB3b3VsZCBsaWtlIHRvIA0KPj4+Pj4+ PmFsbG93IG90aGVyDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRyYW5zcG9ydCBvcGVyYXRpb25hbA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtb2RlbHMsIHN1Y2ggYXMgdGhlIHVzZSBvZiANCj4+Pj4+Pj5hIFZM QU4gdG8NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGly ZWN0IHRyYWZmaWMgYWxvbmcgYQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjaGFpbi4gIE9yIHRoZSB1c2Ugb2YgYW4gDQo+Pj4+Pj4+TVBMUyBsYWJlbCwN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3IgYW4gTVBM UyBsYWJlbCBzdGFjay4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgWW91cnMsIEpvZWwgTS4gSGFscGVybg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNmYyBtYWls aW5nIGxpc3QNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c2ZjQGlldGYub3JnIA0KPj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9fX2xpc3RpbmZvL3NmYw0KPj4+Pj4+ Pg0KPj4+Pj4+PiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzZmNAaWV0Zi5vcmcgDQo+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4+Pj4+Pg0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL19fbGlz dGluZm8vc2ZjDQo+Pj4+Pj4+DQo+Pj4+Pj4+IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYz4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNmY0BpZXRmLm9yZyANCj4+Pj4+Pj4g PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vX19saXN0aW5mby9zZmMNCj4+Pj4+Pj4NCj4+Pj4+Pj4gPGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ZjIG1haWxp bmcgbGlzdA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNmY0Bp ZXRmLm9yZyANCj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9zZmMNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9zZmMNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCj4+Pj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL19fbGlzdGlu Zm8vc2ZjDQo+Pj4+Pj4+DQo+Pj4+Pj4+IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYz4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9fX2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pg0KPj4+Pj4+PiA8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gc2ZjDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1haWxpbmcgbGlzdA0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9zZmMNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgIHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+Pj4+PiAgICAgICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL19fbGlzdGluZm8vc2ZjDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAg ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+ICAgICAgICAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiAgICAgICAgICAgIHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pj4+Pj4gICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL19fbGlzdGluZm8vc2ZjDQo+Pj4+Pj4+ICAgICAgICAg ICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPg0KPj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4g c2ZjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+IHNmY0Bp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2Zj QGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5z ZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Fri Feb 14 07:59:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1851A02CD for ; Fri, 14 Feb 2014 07:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Ofo1hZYWtOlK for ; Fri, 14 Feb 2014 07:59:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3F21A02D0 for ; Fri, 14 Feb 2014 07:59:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD33210; Fri, 14 Feb 2014 15:59:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:56:35 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 15:57:39 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 07:57:33 -0800 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5erGoSE8UFskudetbNVt6AL5qx1MWAgACzbQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYCAAAZ/AIAAAGIAgAAJoQCAAAIgAIAAAciAgAABywCAAAR/gIAAEKUA//+tGDCAAI6sAIAA5Y0A//+XdAA= Date: Fri, 14 Feb 2014 15:57:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C80043@dfweml701-chm.china.huawei.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cvX5Pu53wOoNy-EbnHK9202aTqU Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:59:35 -0000 Jim,=20 Just to clarify, if you agree with what Joel said, then the "context is con= sumable by SF", instead of "SFC" correct? In that case, should this "metadata that are consumable by SF" be out of th= e scope of SFC?=20 Those metadata are inserted/consumed by applications or SFs, they are reall= y the internal processing within applications & related service functions.= =20 Linda -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Friday, February 14, 2014 8:07 AM To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework Yes agreed Joel. Metadata is really =B3context=B2 that is consumable by any= element of a given SFC. While our SFC encapsulation will of course carry i= nformation relevant to the steering of traffic through the desired set of s= ervice functions, I would not characterize that as metadata. On 2/13/14, 7:25 PM, "Joel M. Halpern" wrote: >I only consider the first of those to be metadata. The chain=20 >identification in the service chaining header or the transport header=20 >are not metadata. Treating fields which are needed for steering as=20 >metadata induces massive confusion. can we please keep those two=20 >concepts separate?! > >Yours, >Joel > >On 2/13/14, 7:18 PM, Linda Dunbar wrote: >> >> I see two types of "metadata" being discussed here: >> >> 1. The "flow metadata", like the transactions carried by http flows. >>They are inserted by applications, or inserted by a service function=20 >>to pass some "cookies" to the next one. (many proxy based service=20 >>functions have those capability) >> >> 2. The "Service Chain metadata", that are inserted by "Chain=20 >>Classifier" or control plane to carry extra information (in additional=20 >>to Chain ID) for the purpose of controlling the sequence of functions=20 >>on a chain. >> >> Correct? >> >> IMHO, the first bullet above are specific to applications or service=20 >>functions internal processing. Many of today's proxy based service=20 >>functions make changes to data packets, some of them make those=20 >>changes for other service functions. Those changes won't be in the=20 >>Service Chain Header field. >> >> Linda >> >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee >> Sent: Thursday, February 13, 2014 2:51 PM >> To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I believe most of us agree that an out of bad signalling will not=20 >>address the majority of requirement. Also a typical http flow carries=20 >>many transactions and each can have different or additional=20 >>classification. So a metadata can not be simple connected with one=20 >>flow either. Current implementations of proxies and load balancers has=20 >>addressed this in many ways including custome header insertion. The=20 >>custom header in this case equivalent of metadata vector. >> >> I think we need an efficient way annotate actual data with inline=20 >>metadata. I also strongly believe in solving the 80% of the use case >> >> Regards >> Sumandra >> ________________________________________ >> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 >>[jmh@joelhalpern.com] >> Sent: Thursday, February 13, 2014 11:51 AM >> To: Jerome Moisand; sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> I know very well what GTP does in terms of correlators, and why. >> If all you need is an identifier for the subscriber, carrying a short=20 >>identifier, and using it to select the desired behavior that has been=20 >>pre-populated when the subscribers session starts works really well. >> That is part of why I am not objecting to having provision for=20 >>out-of-band metadata. >> >> However, claiming that a single such correlator is all that is needed=20 >>for even 80% of SFC cases (and I very much supporting trying to focus=20 >>on the 80% cases), just does not seem to work, given the broad range=20 >>of requirements that we have seen. >> >> Yours, >> Joel >> >> On 2/13/14, 2:35 PM, Jerome Moisand wrote: >>> Joel, >>> >>> Protocols like GTP and L2TP work exactly that, with a form of=20 >>>session correlator between the data plane and the control plane. This=20 >>>is very handy for subscriber and service management. Also if a=20 >>>correlator is defined as an opaque and unique number, then one can=20 >>>avoid some of the pitfalls you described. Long-lived metadata is=20 >>>clearly useful (and thanks for sharing, Reinaldo, will read), and=20 >>>there is clear applicability to various service chaining needs. >>> >>> Now this is just one way. The I-D Bruno referred to was just listing=20 >>>this approach as one possible way among others. I totally agree with=20 >>>you that other forms of metadata (like an outcome of the=20 >>>classification of a packet or a sequence of a few packets) may not be=20 >>>suitable for out-of-band signaling. >>> >>> Bottomline seems to be that we have too many options to choose from,=20 >>>and none of them solving it all... Tough. >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 13, 2014 2:29 PM >>> To: sfc@ietf.org >>> Subject: Re: [sfc] Framework >>> >>> As I understand it, the tsvwg (and aeon) work is about flow metadata. >>> That is long-lived metadata of use across many packets. That does=20 >>>indeed seem well-suited to out-of-band cases. >>> >>> My concern is that in SFC, there are many cases which are at best=20 >>>badly-addressed if we insist that they be solved using out-of-band=20 >>>metadata. >>> >>> Yours, >>> Joel >>> >>> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>>> There is draft about transport independent metadata. >>>> >>>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi >>>> ng >>>> - >>>> 01 >>>> >>>> The complexities you mention are discussed there:=20 >>>> variable-encoding, direction, security of metadata, etc. >>>> >>>> Thanks, >>>> >>>> -RP >>>> >>>> >>>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>>> >>>>> While there are cases where out-of-band metadata makes sense,=20 >>>>> There are many cases I would not want to try to cover that way. =20 >>>>> The best examples are situations where the metadata changes from=20 >>>>> packet to packet (such as the data produced by a DPI engine for=20 >>>>> consumption by other applications in the chain.) >>>>> >>>>> More importantly, if you are putting correlators in the packet, it =20 >>>>>is still very complex if you want to use one correlator to handle =20 >>>>>metadata produced by several different entities (the initial =20 >>>>>classifer, the DPI engine, ...) You quickly end up deciding that =20 >>>>>you need several correlators. At which point we are back to=20 >>>>>variable amounts of metadata. >>>>> >>>>> The alternative is to require exceedingly specific and strong=20 >>>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>>> be a very bad idea. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>>> resend to avoid "too many recipients" warning >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>>> > wrote: >>>>>> >>>>>> There are ways to signal variable length amounts of=20 >>>>>>metadata without >>>>>> needing an additional variable-length header on each data=20 >>>>>>packet. >>>>>> >>>>>> draft-rijsman-sfc-metadata-considerations-00 discusses=20 >>>>>>some of the >>>>>> possible approaches: out-of-band signaling (congruent or >>>>>> non-congruent) or a hybrid approach using a fix-length=20 >>>>>>in-band >>>>>> correlator and out-of-band additional metadata. See=20 >>>>>>sections 3.3, >>>>>> 3.4 and 3.5 in the draft. >>>>>> >>>>>> The issue of fixed-length encoding versus variable length=20 >>>>>>encoding >>>>>> is discussion in the challenges chapter in section 4.3. I=20 >>>>>>should >>>>>> probably mention the MTU and segmentation issues as well=20 >>>>>>in that >>>>>> section. >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>>> > wrote: >>>>>> >>>>>> The variable length shim header is needed even if every >>>>>> individual piece of metadata has a fixed length. >>>>>>Different >>>>>> service chains will need different combinations of=20 >>>>>>metadata. So >>>>>> the metadata portion of the header needs to be=20 >>>>>>variable length. >>>>>> >>>>>> I think the approach of a fixed length initial part,=20 >>>>>>and a >>>>>> variable length extension part, is the right model. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>>> >>>>>> Yes, fragmentation and variable headers are=20 >>>>>>usually a really >>>>>> bad thing for forwarding performance. Let's not=20 >>>>>>forget that >>>>>> we live in a 100G-ish kind of world nowadays. >>>>>> >>>>>> Now the question should be: WHY would we want to=20 >>>>>>do that >>>>>> (variable headers leading to fragmentation issues)? >>>>>> >>>>>> For example, the type of metadata that may require >>>>>> variable-length fields might be a better candidate=20 >>>>>>for some >>>>>> out-of-band signaling mechanism. If this is service >>>>>> authorization data (e.g. a service=20 >>>>>>profile/policy), this >>>>>> sounds likely. Not 100% sure this is true for all=20 >>>>>>use cases >>>>>> though. Only a good understanding of use cases,=20 >>>>>>grounded by >>>>>> reflecting on existing network architectures (notably >>>>>> broadband, fixed or mobile), would tell us if one=20 >>>>>>approach >>>>>> or another is the most appropriate. >>>>>> >>>>>> Anyhoo, we're jumping way deep in the detailed=20 >>>>>>protocol >>>>>> design here. This seems a tad premature. >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>>> ] On Behalf Of Dave=20 >>>>>>Dolson >>>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>>> To: 'jmh@joelhalpern.com=20 >>>>>>'; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> '; >>>>>> 'mohamed.boucadair@orange.com >>>>>> '__; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>>'paulq@cisco.com >>>>>> ' >>>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>'; >>>>>> 'linda.dunbar@huawei.com=20 >>>>>>' >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> it is overall more efficient to support PMTU=20 >>>>>>discovery >>>>>> rather than fragmenting every large packet. The is=20 >>>>>>why TCP >>>>>> adopted it so early on. >>>>>> >>>>>> The fragmenting also puts huge performance burden=20 >>>>>>on the >>>>>> service functions. >>>>>> Fragmenting may also affect the ability of load=20 >>>>>>balancers to >>>>>> get each fragment to the correct destination. >>>>>> >>>>>> So PMTU discovery SHOULD be used, in my opinion.=20 >>>>>>By this I >>>>>> mean the client or server is informed that its=20 >>>>>>packets are >>>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>>> >>>>>> Some operators may wish to incur the extra cost to=20 >>>>>>hide the >>>>>> existence of the tunneling, when the elements of=20 >>>>>>the chain >>>>>> can support it, so we could consider that as an=20 >>>>>>optional >>>>>> mechanism. >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>>> ] >>>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>>> To: Ron Parker >>>>> >; >>>>>> mohamed.boucadair@orange.com >>>>>> >>>>>> >>>>> >__; Dave=20 >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> ' >>>>>> >>>>> >; >>>>>>'paulq@cisco.com >>>>>> ' >>>>> > >>>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>>> ' >>>>>>; >>>>>> 'linda.dunbar@huawei.com=20 >>>>>>' >>>>>> >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I mostly agree with you Ron. I can probably come=20 >>>>>>up with >>>>>> some other variations, but your second point is=20 >>>>>>that the >>>>>> transport must deal with the issue of frame size /=20 >>>>>>fit. >>>>>> >>>>>> I would note that if we assume that the carrying=20 >>>>>>encaps >>>>>> (IPv4/v6 outer) is being fragmented, then we are=20 >>>>>>assuming >>>>>> that the exit from service chaining can and will=20 >>>>>>reassemble. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>>> >>>>>> Joel, >>>>>> >>>>>> That is an excellent point to consider when=20 >>>>>>choosing >>>>>> transport >>>>>> encapsulations. If the transport encapsulation >>>>>>is IPv4 >>>>>> or IPv6 >>>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, =20 >>>>>>etc.), then >>>>>> fragmentation and defragmentation are naturally >>>>>> supported. If the >>>>>> transport encapsulation is VLAN, MPLS, etc.,=20 >>>>>>then I >>>>>> believe one of the >>>>>> following must be true: >>>>>> >>>>>> * The end-to-end path is known to support the=20 >>>>>>resulting >>>>>> larger frames >>>>>> * A path discovery mechanism is mandated by=20 >>>>>>SFC when >>>>>> non-IP transports >>>>>> are used * An SFC-specific fragmentation=20 >>>>>>header and >>>>>> mechanisms must be >>>>>> defined (i.e., >>>>>> >>>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o >>>>>> r- >>>>>> f >>>>>> rame) >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com >>>>>> ] Sent: Thursday,=20 >>>>>>February >>>>>> 13, 2014 10:10 >>>>>> AM To: mohamed.boucadair@orange.com >>>>>> ; Dave=20 >>>>>>Dolson; >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; Ron=20 >>>>>>Parker; >>>>>> 'paulq@cisco.com ' Cc: >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>'; >>>>>> 'linda.dunbar@huawei.com >>>>>> ' Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> There is a related complexity. I hope that we=20 >>>>>>expect to >>>>>> support IPv6. >>>>>> IPv6 explicitly prohibits network elements from >>>>>> fragmenting end user >>>>>> packets. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>>> wrote: >>>>>> >>>>>> Re-, >>>>>> >>>>>> FWIW, one of the existing architecture drafts >>>>>> includes the following >>>>>> behavior >>>>>> >>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02# >>>>>> se >>>>>> c >>>>>> tion- >>>>>> 6 >>>>>> >>>>>>=20 >>>>>>>>>>>on- >>>>>>6>): >>>>>> >>>>>> >>>>>> >>>>>> " >>>>>> >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> If adding the Service Chaining Header=20 >>>>>>would result >>>>>> in a fragmented >>>>>> packet, the classifier should include a=20 >>>>>>Service >>>>>> Chaining Header in >>>>>> each fragment. Doing so would prevent SF=20 >>>>>>Nodes to >>>>>> dedicate resource >>>>>> to handle fragments. " >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>> >>>>>> -----Message d'origine----- De : sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>> '; >>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>'; >>>>>> 'jmh@joelhalpern.com =20 >>>>>>'; >>>>>> 'paulq@cisco.com=20 >>>>>>' Cc : >>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>> '; >>>>>> 'linda.dunbar@huawei.com >>>>>> '=20 >>>>>>Objet >>>>>>: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Good point to consider fragmentation. >>>>>> >>>>>> We should design the encapsulation=20 >>>>>>such that the >>>>>> forwarding >>>>>> functions do not need to reassemble. Each >>>>>> fragment should be >>>>>> independently forwardable; some SFs=20 >>>>>>may choose >>>>>> to ignore these >>>>>> packets. >>>>>> >>>>>> Any layer 2.5 protocol like VLAN or=20 >>>>>>MPLS would >>>>>> support this. >>>>>> Otherwise, a reassembly layer could be=20 >>>>>>added >>>>>> after the forwarding >>>>>> coordinates. Think of something like=20 >>>>>>the >>>>>>IPv6 >>>>>> reassembly option >>>>>> after a GRE header, for instance. >>>>>> >>>>>> IP | GRE | reassem | frag data >>>>>> >>>>>> We could alternatively mandate the=20 >>>>>>inner IP be >>>>>> fragmented and that >>>>>> path-MTU discovery be supported. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- From: >>>>>> Nicolas BOUTHORS >>>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>>> ] >>>>>>Sent: >>>>>> Thursday, February 13, >>>>>> 2014 04:13 AM To: Ron Parker >>>>>> >>>>> =20 >>>>>>>; >>>>>> Dave Dolson; Joel M. Halpern >>>>>> >>>>> >; Paul Quinn >>>>>> (paulq) >>>>> > Cc: Sumandra=20 >>>>>>Majee >>>>>> ; >>>>>> sfc@ietf.org =20 >>>>>>>>>>> >; Linda Dunbar >>>>>> >>>>> > >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> If we do not enforce a fix header size=20 >>>>>>we have >>>>>> other implication. >>>>>> >>>>>> There is the question of segmentation and >>>>>> reassembly responsibility >>>>>> as well. >>>>>> >>>>>> If adding length to the service header=20 >>>>>>forces >>>>>> segmentation, then >>>>>> whose responsibility is it to=20 >>>>>>reassemble the >>>>>> payload before passing >>>>>> it to the SF. >>>>>> >>>>>> Similar question for packet re-ordering. >>>>>> >>>>>> >>>>>> =20 >>>>>>__________________________________________ From: >>>>>> Ron Parker >>>>>> [Ron_Parker@affirmednetworks.__com >>>>>> =20 >>>>>>] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>>>Halpern; >>>>>> Paul Quinn >>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: >>>>>> Re: [sfc] Framework >>>>>> >>>>>> Dave, >>>>>> >>>>>> Yes, that is a good point if we logically >>>>>> separate the forwarding >>>>>> function from the SFC-aware service=20 >>>>>>function, as >>>>>> we should. The >>>>>> forwarding function is concerned with=20 >>>>>>only the >>>>>> inbound transport >>>>>> header, the fixed portion of the=20 >>>>>>service header >>>>>> containing the >>>>>> chain information, and the outbound=20 >>>>>>transport >>>>>> header. The >>>>>> service function may look at the=20 >>>>>>entirety of the >>>>>> service header and >>>>>> would look at the encapsulated packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Dave=20 >>>>>>Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 5:18 PM To: Joel M. Halpern; Ron=20 >>>>>>Parker; Paul >>>>>> Quinn (paulq) Cc: >>>>>> Sumandra Majee; sfc@ietf.org >>>>>> ; Linda Dunbar >>>>>>Subject: RE: >>>>>> [sfc] >>>>>> Framework >>>>>> >>>>>> The forwarding plane might not even=20 >>>>>>need to look >>>>>> at the encapsulated >>>>>> packet. >>>>>> >>>>>> For example, (if the SF Identifier is=20 >>>>>>a VLAN >>>>>> tag), an Ethernet >>>>>> switch can forward packets of the form: >>>>>>Ether | >>>>>> VLAN | BLOB. >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>> Wednesday, February 12, 2014 4:30 PM To: >>>>>>Ron >>>>>> Parker; Dave Dolson; >>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>>> sfc@ietf.org ;=20 >>>>>>Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> I agree as well. Yours, Joel >>>>>> >>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>> >>>>>> Hi, Dave. >>>>>> >>>>>> I Agree with your statement. And >>>>>>if the >>>>>> total length of the >>>>>> header is >>>>>> >>>>>> contained in the mandatory portion,=20 >>>>>>the hardware >>>>>> implementation can >>>>>> easily locate the encapsulated packet. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Dave Dolson >>>>>> [mailto:ddolson@sandvine.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, >>>>>> 2014 4:10 PM To: Ron Parker; Paul=20 >>>>>>Quinn >>>>>> (paulq) Cc: Joel M. >>>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>>> ; Linda=20 >>>>>>Dunbar >>>>>>Subject: >>>>>> RE: [sfc] Framework >>>>>> >>>>>> I think a good approach would be: >>>>>> >>>>>> The information required for=20 >>>>>>forwarding (the >>>>>> SF Identifier) should >>>>>> be in >>>>>> >>>>>> a mandatory fixed-size header. >>>>>> >>>>>> >>>>>> Optional information (if any) is=20 >>>>>>NOT to be >>>>>> used for forwarding, but >>>>>> is >>>>>> >>>>>> for consumption by one or more of the >>>>>> applications in the chain. >>>>>> >>>>>> >>>>>> Then the forwarding plane, and=20 >>>>>>even the PDP, >>>>>> can be agnostic about >>>>>> the >>>>>> >>>>>> meta-data. >>>>>> >>>>>> >>>>>> -Dave >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org >>>>>> ] >>>>>> On Behalf Of Ron Parker Sent: >>>>>> Wednesday, February 12, 2014 4:05=20 >>>>>>PM >>>>>>To: >>>>>> Paul Quinn (paulq) Cc: >>>>>> Joel M. Halpern; Sumandra Majee; >>>>>> sfc@ietf.org=20 >>>>>>; Linda Dunbar >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Paul, >>>>>> >>>>>> That is why I am proposing a=20 >>>>>>hybrid where >>>>>> extensions or options can >>>>>> be >>>>>> >>>>>> added but the total length is=20 >>>>>>contained in the >>>>>> fixed portion. I >>>>>> can envision certain deployments (e.g., >>>>>> Enterprise) where perhaps >>>>>> extensions are not needed and the SFC >>>>>> functionality is realized >>>>>> in hardware. And, I can envision >>>>>>certain other >>>>>> deployments >>>>>> (e.g., 3gpp) where the extension=20 >>>>>>headers add >>>>>> sufficient value to >>>>>> justify software based implementations. >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>>Paul Quinn >>>>>> (paulq) >>>>>> [mailto:paulq@cisco.com >>>>>> ] Sent: >>>>>>Wednesday, >>>>>> February 12, 2014 >>>>>> 3:40 PM To: Ron Parker Cc:=20 >>>>>>Sumandra Majee; >>>>>> Linda Dunbar; Joel M. >>>>>> Halpern; sfc@ietf.org=20 >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> Hi, >>>>>> >>>>>> We certainly need to be very=20 >>>>>>careful with >>>>>> variable length headers >>>>>> when >>>>>> >>>>>> hardware platform are in play. >>>>>> >>>>>> >>>>>> Ron, your examples of IP options=20 >>>>>>and >>>>>>v6 EH >>>>>> have both suffered from >>>>>> >>>>>> significant implementation and deployment >>>>>> hurdles due to the >>>>>> complexity and cost associated with=20 >>>>>>hardware >>>>>> support for the >>>>>> option/EH. >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> On Feb 12, 2014, at 3:10 PM, Ron=20 >>>>>>Parker >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, Sumandra. >>>>>> >>>>>> Regarding service header=20 >>>>>>flexibility, I >>>>>> completely agree. I >>>>>> might >>>>>> >>>>>> suggest a compromise between hardware >>>>>> friendliness and software >>>>>> flexibility. If the header had the >>>>>>ability to >>>>>> add extensions >>>>>> (perhaps similar to IPv6) but also had=20 >>>>>>the >>>>>> header length encoded in >>>>>> the mandatory part (like IPv4), then a=20 >>>>>>hardware >>>>>> implementation would >>>>>> be free to skip over the extensions=20 >>>>>>(in cases >>>>>> where the deployment >>>>>> justifies ignoring the extensions). >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: >>>>>> Sumandra Majee >>>>>> [mailto:S.Majee@F5.com >>>>>> ] Sent: >>>>>> Wednesday, February 12, 2014 >>>>>> 3:04 PM To: Ron Parker; Linda=20 >>>>>>Dunbar; >>>>>> Joel M. Halpern; >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: Re: [sfc] Framework >>>>>> >>>>>> For all of those=20 >>>>>>reasons, I >>>>>> strongly support a =20 >>>>>>canonical service >>>>>> header that is=20 >>>>>>independent of >>>>>> the transport=20 >>>>>>methodology. >>>>>> >>>>>> >>>>>> >>>>>> I agree. However the format of=20 >>>>>>service >>>>>> header should be >>>>>> standardized in >>>>>> >>>>>> a way that is flexible. Some of us=20 >>>>>>would like to >>>>>> see variable length >>>>>> header that is also HW friendly. The=20 >>>>>>service >>>>>> header can be >>>>>> represented as a mandotory fixed=20 >>>>>>length header >>>>>> (like IP >>>>>> header) along with an optional=20 >>>>>>variable length >>>>>> attribute field. >>>>>> Different services can be interested in >>>>>> different metadata, for >>>>>> example subscriber ID could be of=20 >>>>>>interest in >>>>>> the mobile core >>>>>> service chain only. >>>>>> >>>>>> >>>>>> Sumandra >>>>>> >>>>>> On 2/12/14, 11:32 AM, "Ron=20 >>>>>>Parker" >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Linda, >>>>>> >>>>>> My interpretation of the >>>>>> architecture docs is that=20 >>>>>>the service >>>>>> function chain is built in an >>>>>> abstract manner (i.e.,=20 >>>>>>SF-A then >>>>>> SF-B >>>>>> >>>>>> then SF-C). >>>>>> >>>>>> Separately, a locator=20 >>>>>>table provides >>>>>> network location for >>>>>> each of those service=20 >>>>>>functions. >>>>>> In this way, you can >>>>>> locate the service=20 >>>>>>functions >>>>>> >>>>>> in >>>>>> >>>>>> a manner appropriate to=20 >>>>>>the type of >>>>>> transport you are >>>>>> using. If you want that to= =20 >>>>>>be >>>>>> interface+VLAN, >>>>>> gateway-IP+MPLS label=20 >>>>>>stack, IP >>>>>> >>>>>> address, >>>>>> >>>>>> GRE tunnel remote IP +=20 >>>>>>key, etc., >>>>>> you can do that. You >>>>>> can even potentially locate >>>>>> different service=20 >>>>>>functions that >>>>>> reside in the same chain with >>>>>> different flavors of >>>>>> network locators. Another >>>>>> justification to separate the >>>>>> identity of a service=20 >>>>>>function from >>>>>> its network location is >>>>>> load balancing. If, for=20 >>>>>>example, >>>>>> SF-A had 3 IP addresses, >>>>>> that would imply load=20 >>>>>>balancing to 3 >>>>>> instances using IP as a >>>>>> transport layer. >>>>>> >>>>>> For all of those reasons,=20 >>>>>>I strongly >>>>>> support a canonical service >>>>>> header that is independent=20 >>>>>>of the >>>>>> transport >>>>>> methodology. At a=20 >>>>>>particular >>>>>> node, the decision as to >>>>>> where to go next should be=20 >>>>>>based >>>>>> solely on information=20 >>>>>>carried in >>>>>> the canonical service=20 >>>>>>header and not >>>>>> on the >>>>>> >>>>>> fields >>>>>> >>>>>> in the transport header. =20 >>>>>>That is, >>>>>> the SFC node discards >>>>>> the transport header and=20 >>>>>>extracts >>>>>> the chain ID from the >>>>>> service header. Through >>>>>> mechanisms we have not yet=20 >>>>>>begun >>>>>> to discuss, the SFC node=20 >>>>>>knows how >>>>>> to interpret the chain ID and >>>>>> ultimately how to progress =20 >>>>>>the packet. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>>From: sfc >>>>>> =20 >>>>>>[mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Linda Dunbar >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 12:01 PM To: Joel M. >>>>>> Halpern; sfc@ietf.org >>>>>> >>>>>>Subject: Re: >>>>>> [sfc] Framework >>>>>> >>>>>> Agree with Joel's statement. >>>>>> >>>>>> I think a simple sentence=20 >>>>>>below >>>>>> should be added Section=20 >>>>>>5.2 (SFC >>>>>> Classifier) to emphasize=20 >>>>>>this point. >>>>>> >>>>>> "A Service Chain=20 >>>>>>Classifier node can >>>>>> associate a unique Layer 2 >>>>>> or 3 Label (e.g. VLAN,=20 >>>>>>MPLS >>>>>>label) >>>>>> to the packets in the flow. >>>>>> Those Layer 2 or 3 Label=20 >>>>>>makes it >>>>>> easier for subsequent nodes >>>>>> along the flow path to=20 >>>>>>steer the >>>>>> flow to the service functions >>>>>> specified by the flow's =20 >>>>>>service chain." >>>>>> >>>>>> >>>>>> Linda -----Original >>>>>>Message----- >>>>>> From: sfc >>>>>> =20 >>>>>>[mailto:sfc-bounces@ietf.org >>>>>> =20 >>>>>>] On >>>>>> Behalf Of Joel M. Halpern >>>>>> Sent: Wednesday, February=20 >>>>>>12, 2014 >>>>>> 10:20 AM To: >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> Subject: [sfc] Framework >>>>>> >>>>>> I was looking at the=20 >>>>>>framework >>>>>> proposal. The proposal has=20 >>>>>>a very >>>>>> specific model of the=20 >>>>>>scope of the >>>>>> transport header (that it is >>>>>> derived from, and relates=20 >>>>>>only to, >>>>>> the first service function to >>>>>> which the packet will be=20 >>>>>>directed. >>>>>> That is clearly an=20 >>>>>>operational >>>>>> model we need to support. >>>>>> >>>>>> However, I would like to=20 >>>>>>allow other >>>>>> transport operational >>>>>> models, such as the use of=20 >>>>>>a VLAN to >>>>>> direct traffic along a >>>>>> chain. Or the use of an=20 >>>>>>MPLS label, >>>>>> or an MPLS label stack. >>>>>> >>>>>> Yours, Joel M. Halpern >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org=20 >>>>>> >>>>>> >>>>>> 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 >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>https://www.ietf.org/mailman/__listinfo/sfc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________ sfc >>>>>> mailing list >>>>>> sfc@ietf.org >>>>>> =20 >>>>>>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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 Fri Feb 14 08:00:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DA01A02CC for ; Fri, 14 Feb 2014 08:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyJKnpyF66ML for ; Fri, 14 Feb 2014 08:00:15 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 46F991A029C for ; Fri, 14 Feb 2014 08:00:13 -0800 (PST) Received: from mail61-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 16:00:11 +0000 Received: from mail61-ch1 (localhost [127.0.0.1]) by mail61-ch1-R.bigfish.com (Postfix) with ESMTP id 8655B20037F; Fri, 14 Feb 2014 16:00:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz9371Ic85fh103dKe0eah1418Ic25dL4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail61-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(497574002)(51444003)(189002)(199002)(377454003)(164054003)(41574002)(87936001)(85306002)(80976001)(15202345003)(4396001)(2656002)(19300405004)(87266001)(49866001)(83322001)(74316001)(19580405001)(19580395003)(56816005)(90146001)(74366001)(50986001)(81342001)(47736001)(81542001)(85852003)(76576001)(69226001)(76786001)(18717965001)(74706001)(56776001)(83072002)(59766001)(74876001)(63696002)(80022001)(76796001)(66066001)(65816001)(76482001)(79102001)(51856001)(54316002)(81686001)(81816001)(15975445006)(54356001)(47976001)(19609705001)(95416001)(93516002)(46102001)(94316002)(94946001)(95666001)(31966008)(47446002)(33646001)(86362001)(92566001)(16236675002)(77982001)(53806001)(93136001)(74502001)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:EBBFF0A5.AFC9E3E9.22C1BF43.82E0FB7D.203C1; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail61-ch1 (localhost.localdomain [127.0.0.1]) by mail61-ch1 (MessageSwitch) id 1392393608500456_30041; Fri, 14 Feb 2014 16:00:08 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail61-ch1.bigfish.com (Postfix) with ESMTP id 6B0D1260238; Fri, 14 Feb 2014 16:00:08 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 16:00:08 +0000 Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 16:00:06 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.868.8; Fri, 14 Feb 2014 16:00:05 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0868.013; Fri, 14 Feb 2014 16:00:05 +0000 From: Ross Callon To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG Agenda: London Thread-Index: AQHPH3JY7vfIB63+W06bsptZEKAjcZq0/IHA Date: Fri, 14 Feb 2014 16:00:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 01221E3973 Content-Type: multipart/alternative; boundary="_000_eea0896cad7c487283f578436d0bbb37CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pbBd5_7MXzePfzJgiBstjH0EBY4 Cc: Ross Callon , Bruno Rijsman Subject: Re: [sfc] SFC WG Agenda: London X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:00:24 -0000 --_000_eea0896cad7c487283f578436d0bbb37CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We would like to request a slot to present draft-rijsman-sfc-metadata-consi= derations. Since Bruno will not be in London, the intent is that Bruno and = I will create slides and then I will present them. Regarding your specific questions: 1) Let us know now: Done (this email) 2) Indicate which WG deliverable the draft relates to; and The intent of the draft is to clearly articulate the use-ca= ses, implementation options, and challenges related to metadata (what is it= , what is it used for, what options are there for conveying metadata,...). = As such, the issue raised in this draft are important inputs to the various= chartered work items for the working group. 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Whether this draft would end up being published on its own,= or would be folded into other drafts, is TBD by the WG. In terms of the amount of time to present the draft: I think that 10 minute= s would be sufficient, more time would be great if available and would allo= w more discussion of details. Thanks, Ross From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, February 01, 2014 12:24 PM To: sfc@ietf.org Subject: [sfc] SFC WG Agenda: London Greetings, It's time to start putting together an agenda for the SFC meeting in London= . We've requested one 2.5 hour slot . Because face-to-face time is precious= , we intend to focus on: - WG chartered items for which we have WG-adopted IDs, or IDs that appear h= eaded for WG adoption. - Specific topics where feedback is needed, and mailing list discussions ha= ve not converged. We also do not intend to give agenda time to everyone who has a draft - the= WG sessions do not have time for that, nor is it necessarily an effective = use of time. We also do not intend to give agenda time for drafts for which= little or no mailing list interest has been generated. For the upcoming session, we expect to focus on: 1) Problem satement (hopefully not much time needed -- are there any actual= open issues?). 2) Use cases. 3) Architecture. If you have a draft (or plan to submit one) and would like to present (or m= ore specifically, would like the working group to do something with your dr= aft), please: 1) Let us know now (even if the draft is not published yet), so we can star= t planning; 2) Indicate which WG deliverable the draft relates to; and 3) Indicate what you want the WG to do with your draft. E.g., do you want t= his to become "THE" WG document for a particular deliverable? Or, is there = content in the document you believe should be added to another document? et= c. Please do not just respond "I want it to become a WG document". It would= be better to explain in what context, and how your draft relates to other = drafts that have been submitted. Thanks! Thomas & Jim --_000_eea0896cad7c487283f578436d0bbb37CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We would like to request = a slot to present draft-rijsman-sfc-metadata-considerations. Since Bruno wi= ll not be in London, the intent is that Bruno and I will create slides and then I will present them.

 <= /p>

Regarding your specific q= uestions:

 <= /p>

1) Let us know now:

 <= /p>

    &= nbsp;           Done (thi= s email)

 <= /p>

2) Indicate which WG deli= verable the draft relates to; and

 <= /p>

    &= nbsp;           The inten= t of the draft is to clearly articulate the use-cases, implementation optio= ns, and challenges related to metadata (what is it, what is it used for, what options are there for conveying metadata,…). As= such, the issue raised in this draft are important inputs to the various c= hartered work items for the working group.

 <= /p>

3) Indicate what you want= the WG to do with your draft. E.g., do you want this to become "THE&q= uot; WG document for a particular deliverable? Or, is there content in the document you believe should be added to another document? etc. Plea= se do not just respond "I want it to become a WG document". It wo= uld be better to explain in what context, and how your draft relates to oth= er drafts that have been submitted.

 <= /p>

    &= nbsp;           Whether t= his draft would end up being published on its own, or would be folded into = other drafts, is TBD by the WG.

 <= /p>

In terms of the amount of= time to present the draft: I think that 10 minutes would be sufficient, mo= re time would be great if available and would allow more discussion of details.

 <= /p>

Thanks, Ross

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, February 01, 2014 12:24 PM
To: sfc@ietf.org
Subject: [sfc] SFC WG Agenda: London

 

Greetings,

 

It's time to start putting = together an agenda for the SFC meeting in London. We've requested one = 2.5 hour slot . Because face-to-face time is precious, we intend to focus on:

&n= bsp;

- WG ch= artered items for which we have WG-adopted IDs, or IDs that appear headed f= or WG adoption.

&n= bsp;

- Speci= fic topics where feedback is needed, and mailing list discussions have not = converged.

&n= bsp;

We also= do not intend to give agenda time to everyone who has a draft - the WG ses= sions do not have time for that, nor is it necessarily an effective use of = time. We also do not intend to give agenda time for drafts for which little or no mailing list interest has be= en generated.

&n= bsp;

For the= upcoming session, we expect to focus on:

&n= bsp;

1) Prob= lem satement (hopefully not much time needed -- are there any actual open i= ssues?).

&n= bsp;

2) Use = cases.

&n= bsp;

3) Arch= itecture.

&n= bsp;

If you = have a draft (or plan to submit one) and would like to present (or more spe= cifically, would like the working group to do something with your draft), p= lease:

&n= bsp;

1) Let = us know now (even if the draft is not published yet), so we can start plann= ing;

&n= bsp;

2) Indi= cate which WG deliverable the draft relates to; and

&n= bsp;

3) Indi= cate what you want the WG to do with your draft. E.g., do you want this to = become "THE" WG document for a particular deliverable? Or, is the= re content in the document you believe should be added to another document? etc. Please do not just respond "I want= it to become a WG document". It would be better to explain in what co= ntext, and how your draft relates to other drafts that have been submitted.=

&n= bsp;

Thanks!=

&n= bsp;

Thomas = & Jim

--_000_eea0896cad7c487283f578436d0bbb37CO2PR05MB636namprd05pro_-- From nobody Fri Feb 14 08:04:58 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927EB1A0284 for ; Fri, 14 Feb 2014 08:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vs2XdcjIi6QL for ; Fri, 14 Feb 2014 08:04:48 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 964F91A025A for ; Fri, 14 Feb 2014 08:04:48 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-0f-52fe3e9fa024 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FE.45.11484.F9E3EF25; Fri, 14 Feb 2014 17:04:47 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 11:04:44 -0500 From: David Allan I To: "Joel M. Halpern" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5bHPGxPUurDkOz4h81Orzj3pqyK6sAgAAqPACAAAjrgIAAAfCAgAAIFgCAAAcXAIAAAViAgAAECgCAAAGugIAADUiAgAACHACAALUQgIAAOXoAgAALywCAAB5PgIAAAmQAgAADlQCAAAjLAIAAAu8AgAAiSYD//7MvyoAAXVMAgAACIACAAAHJgIAAAcsAgAAEfoCAABCmAIAAOgAAgAABwwCAALKqoA== Date: Fri, 14 Feb 2014 16:04:43 +0000 Message-ID: References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com>, <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> In-Reply-To: <52FD6262.1040605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyuXRPrO58u39BBkdXmVt8PPWGyeJuy0Qm iycPtrI7MHu0HHnL6rFkyU8mj3NTvjMGMEdx2aSk5mSWpRbp2yVwZby6tYCx4M4LporfGyIb GH+eZexi5OSQEDCR2L7lOxuELSZx4d56IJuLQ0jgCKPE4xVboJzljBKX73Uzg1SxCRhI7Pn/ BaxbRKBEYv3BdnYQW1hARqLzzh1miLisxM6Tk5lBmkUEvjFKTNh0B2wFi4CqxJTrh8CaeQV8 Jebv6maF2PCPSeLv5tOsIAlOAX2JYx+Og01iBLrp+6k1TCA2s4C4xK0n85kgbhWQWLLnPDOE LSrx8vE/VghbSeLj7/nsEPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2z kLQsYGRZxchRWpxalptuZLiJERgpxyTYHHcwLvhkeYhRmoNFSZz3y1vnICGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MrL5TLhxUOzpHJOH/3tl3EkRUVFh/3E29PjHLp1H2mdn+yFMl6+Me tx2pecLc/tVvUQf7Fa/v4aJb3//2MfFbcvfEnbsmVsEz1bd0h6W9avNXY5v1Oqti896rrSFM M7awnpt/bqVG4JXHHN0133c9/VNgH7M94embRlWGW+vkjYyPbb6pPPPaDSWW4oxEQy3mouJE AKuBadJiAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WRJZIIMXuqC5L6X2s9FbizAn2rw Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:04:56 -0000 Wild agreement! D -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 13, 2014 4:25 PM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Framework I only consider the first of those to be metadata. The chain identificatio= n in the service chaining header or the transport header are not metadata. = Treating fields which are needed for steering as metadata induces massive = confusion. can we please keep those two concepts separate?! Yours, Joel On 2/13/14, 7:18 PM, Linda Dunbar wrote: > > I see two types of "metadata" being discussed here: > > 1. The "flow metadata", like the transactions carried by http flows.=20 > They are inserted by applications, or inserted by a service function=20 > to pass some "cookies" to the next one. (many proxy based service=20 > functions have those capability) > > 2. The "Service Chain metadata", that are inserted by "Chain Classifier= " or control plane to carry extra information (in additional to Chain ID) f= or the purpose of controlling the sequence of functions on a chain. > > Correct? > > IMHO, the first bullet above are specific to applications or service func= tions internal processing. Many of today's proxy based service functions ma= ke changes to data packets, some of them make those changes for other servi= ce functions. Those changes won't be in the Service Chain Header field. > > Linda > > > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee > Sent: Thursday, February 13, 2014 2:51 PM > To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I believe most of us agree that an out of bad signalling will not address= the majority of requirement. Also a typical http flow carries many transac= tions and each can have different or additional classification. So a metada= ta can not be simple connected with one flow either. Current implementation= s of proxies and load balancers has addressed this in many ways including c= ustome header insertion. The custom header in this case equivalent of metad= ata vector. > > I think we need an efficient way annotate actual data with inline=20 > metadata. I also strongly believe in solving the 80% of the use case > > Regards > Sumandra > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 > [jmh@joelhalpern.com] > Sent: Thursday, February 13, 2014 11:51 AM > To: Jerome Moisand; sfc@ietf.org > Subject: Re: [sfc] Framework > > I know very well what GTP does in terms of correlators, and why. > If all you need is an identifier for the subscriber, carrying a short ide= ntifier, and using it to select the desired behavior that has been pre-popu= lated when the subscribers session starts works really well. > That is part of why I am not objecting to having provision for out-of-ban= d metadata. > > However, claiming that a single such correlator is all that is needed for= even 80% of SFC cases (and I very much supporting trying to focus on the 8= 0% cases), just does not seem to work, given the broad range of requirement= s that we have seen. > > Yours, > Joel > > On 2/13/14, 2:35 PM, Jerome Moisand wrote: >> Joel, >> >> Protocols like GTP and L2TP work exactly that, with a form of session co= rrelator between the data plane and the control plane. This is very handy f= or subscriber and service management. Also if a correlator is defined as an= opaque and unique number, then one can avoid some of the pitfalls you desc= ribed. Long-lived metadata is clearly useful (and thanks for sharing, Reina= ldo, will read), and there is clear applicability to various service chaini= ng needs. >> >> Now this is just one way. The I-D Bruno referred to was just listing thi= s approach as one possible way among others. I totally agree with you that = other forms of metadata (like an outcome of the classification of a packet = or a sequence of a few packets) may not be suitable for out-of-band signali= ng. >> >> Bottomline seems to be that we have too many options to choose from, and= none of them solving it all... Tough. >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 13, 2014 2:29 PM >> To: sfc@ietf.org >> Subject: Re: [sfc] Framework >> >> As I understand it, the tsvwg (and aeon) work is about flow metadata. >> That is long-lived metadata of use across many packets. That does indee= d seem well-suited to out-of-band cases. >> >> My concern is that in SFC, there are many cases which are at best badly-= addressed if we insist that they be solved using out-of-band metadata. >> >> Yours, >> Joel >> >> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>> There is draft about transport independent metadata. >>> >>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodin >>> g >>> - >>> 01 >>> >>> The complexities you mention are discussed there: variable-encoding,=20 >>> direction, security of metadata, etc. >>> >>> Thanks, >>> >>> -RP >>> >>> >>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>> >>>> While there are cases where out-of-band metadata makes sense, There=20 >>>> are many cases I would not want to try to cover that way. The best=20 >>>> examples are situations where the metadata changes from packet to=20 >>>> packet (such as the data produced by a DPI engine for consumption=20 >>>> by other applications in the chain.) >>>> >>>> More importantly, if you are putting correlators in the packet, it=20 >>>> is still very complex if you want to use one correlator to handle=20 >>>> metadata produced by several different entities (the initial=20 >>>> classifer, the DPI engine, ...) You quickly end up deciding that=20 >>>> you need several correlators. At which point we are back to variable = amounts of metadata. >>>> >>>> The alternative is to require exceedingly specific and strong=20 >>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>> be a very bad idea. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>> resend to avoid "too many recipients" warning >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>> > wrote: >>>>> >>>>> There are ways to signal variable length amounts of metadata w= ithout >>>>> needing an additional variable-length header on each data pack= et. >>>>> >>>>> draft-rijsman-sfc-metadata-considerations-00 discusses some of= the >>>>> possible approaches: out-of-band signaling (congruent or >>>>> non-congruent) or a hybrid approach using a fix-length in-band >>>>> correlator and out-of-band additional metadata. See sections = 3.3, >>>>> 3.4 and 3.5 in the draft. >>>>> >>>>> The issue of fixed-length encoding versus variable length enco= ding >>>>> is discussion in the challenges chapter in section 4.3. I sho= uld >>>>> probably mention the MTU and segmentation issues as well in th= at >>>>> section. >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>> > wrote: >>>>> >>>>> The variable length shim header is needed even if every >>>>> individual piece of metadata has a fixed length. Differen= t >>>>> service chains will need different combinations of metadat= a. So >>>>> the metadata portion of the header needs to be variable le= ngth. >>>>> >>>>> I think the approach of a fixed length initial part, and a >>>>> variable length extension part, is the right model. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>> >>>>> Yes, fragmentation and variable headers are usually a = really >>>>> bad thing for forwarding performance. Let's not forget= that >>>>> we live in a 100G-ish kind of world nowadays. >>>>> >>>>> Now the question should be: WHY would we want to do th= at >>>>> (variable headers leading to fragmentation issues)? >>>>> >>>>> For example, the type of metadata that may require >>>>> variable-length fields might be a better candidate for= some >>>>> out-of-band signaling mechanism. If this is service >>>>> authorization data (e.g. a service profile/policy), th= is >>>>> sounds likely. Not 100% sure this is true for all use = cases >>>>> though. Only a good understanding of use cases, ground= ed by >>>>> reflecting on existing network architectures (notably >>>>> broadband, fixed or mobile), would tell us if one appr= oach >>>>> or another is the most appropriate. >>>>> >>>>> Anyhoo, we're jumping way deep in the detailed protoco= l >>>>> design here. This seems a tad premature. >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>> ] On Behalf Of Dave Dolso= n >>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>> To: 'jmh@joelhalpern.com '= ; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'mohamed.boucadair@orange.com >>>>> '__; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; 'paulq@cisco.co= m >>>>> ' >>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com ' >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> it is overall more efficient to support PMTU discovery >>>>> rather than fragmenting every large packet. The is why= TCP >>>>> adopted it so early on. >>>>> >>>>> The fragmenting also puts huge performance burden on t= he >>>>> service functions. >>>>> Fragmenting may also affect the ability of load balanc= ers to >>>>> get each fragment to the correct destination. >>>>> >>>>> So PMTU discovery SHOULD be used, in my opinion. By th= is I >>>>> mean the client or server is informed that its packets= are >>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>> >>>>> Some operators may wish to incur the extra cost to hid= e the >>>>> existence of the tunneling, when the elements of the c= hain >>>>> can support it, so we could consider that as an option= al >>>>> mechanism. >>>>> >>>>> -Dave >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>> ] >>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>> To: Ron Parker >>>> >; >>>>> mohamed.boucadair@orange.com >>>>> >>>>> >>>> >__; Dave Dolson; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> ' >>>>> >>>> >; 'paulq@cisco.co= m >>>>> ' >>>> > >>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>> ' >; >>>>> 'linda.dunbar@huawei.com ' >>>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I mostly agree with you Ron. I can probably come up w= ith >>>>> some other variations, but your second point is that t= he >>>>> transport must deal with the issue of frame size / fit= . >>>>> >>>>> I would note that if we assume that the carrying encap= s >>>>> (IPv4/v6 outer) is being fragmented, then we are assum= ing >>>>> that the exit from service chaining can and will reass= emble. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>> >>>>> Joel, >>>>> >>>>> That is an excellent point to consider when choosi= ng >>>>> transport >>>>> encapsulations. If the transport encapsulation i= s IPv4 >>>>> or IPv6 >>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN,=20 >>>>> etc.), then >>>>> fragmentation and defragmentation are naturally >>>>> supported. If the >>>>> transport encapsulation is VLAN, MPLS, etc., then = I >>>>> believe one of the >>>>> following must be true: >>>>> >>>>> * The end-to-end path is known to support the resu= lting >>>>> larger frames >>>>> * A path discovery mechanism is mandated by SFC wh= en >>>>> non-IP transports >>>>> are used * An SFC-specific fragmentation header an= d >>>>> mechanisms must be >>>>> defined (i.e., >>>>> >>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or >>>>> - >>>>> f >>>>> rame) >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Joel M. Halpern >>>>> [mailto:jmh@joelhalpern.com >>>>> ] Sent: Thursday, Febr= uary >>>>> 13, 2014 10:10 >>>>> AM To: mohamed.boucadair@orange.com >>>>> ; Dave Dolson= ; >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; Ron Parker; >>>>> 'paulq@cisco.com ' Cc: >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Subject: >>>>> Re: [sfc] Framework >>>>> >>>>> There is a related complexity. I hope that we expe= ct to >>>>> support IPv6. >>>>> IPv6 explicitly prohibits network elements from >>>>> fragmenting end user >>>>> packets. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>> wrote: >>>>> >>>>> Re-, >>>>> >>>>> FWIW, one of the existing architecture drafts >>>>> includes the following >>>>> behavior >>>>> >>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#s >>>>> e >>>>> c >>>>> tion- >>>>> 6 >>>>> >>>>> ): >>>>> >>>>> >>>>> >>>>> " >>>>> >>>>> 6. Fragmentation Considerations >>>>> >>>>> If adding the Service Chaining Header would re= sult >>>>> in a fragmented >>>>> packet, the classifier should include a Servic= e >>>>> Chaining Header in >>>>> each fragment. Doing so would prevent SF Node= s to >>>>> dedicate resource >>>>> to handle fragments. " >>>>> >>>>> Cheers, Med >>>>> >>>>> >>>>> -----Message d'origine----- De : sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> De la part de Dave Dolson Envoy=E9 : >>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>> '; >>>>> 'Ron_Parker@affirmednetworks.__com >>>>> '; >>>>> 'jmh@joelhalpern.com=20 >>>>> '; >>>>> 'paulq@cisco.com '= Cc : >>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>> '; >>>>> 'linda.dunbar@huawei.com >>>>> ' Objet : = Re: >>>>> [sfc] Framework >>>>> >>>>> Good point to consider fragmentation. >>>>> >>>>> We should design the encapsulation such th= at the >>>>> forwarding >>>>> functions do not need to reassemble. Each >>>>> fragment should be >>>>> independently forwardable; some SFs may ch= oose >>>>> to ignore these >>>>> packets. >>>>> >>>>> Any layer 2.5 protocol like VLAN or MPLS w= ould >>>>> support this. >>>>> Otherwise, a reassembly layer could be add= ed >>>>> after the forwarding >>>>> coordinates. Think of something like the I= Pv6 >>>>> reassembly option >>>>> after a GRE header, for instance. >>>>> >>>>> IP | GRE | reassem | frag data >>>>> >>>>> We could alternatively mandate the inner I= P be >>>>> fragmented and that >>>>> path-MTU discovery be supported. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- From: >>>>> Nicolas BOUTHORS >>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>> ] Sent= : >>>>> Thursday, February 13, >>>>> 2014 04:13 AM To: Ron Parker >>>>> >>>> >; >>>>> Dave Dolson; Joel M. Halpern >>>>> >>>> >; Paul Quinn >>>>> (paulq) >>>> > Cc: Sumandra Maj= ee >>>>> ; >>>>> sfc@ietf.org >>>> >; Linda Dunbar >>>>> >>>> > >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> If we do not enforce a fix header size we = have >>>>> other implication. >>>>> >>>>> There is the question of segmentation and >>>>> reassembly responsibility >>>>> as well. >>>>> >>>>> If adding length to the service header for= ces >>>>> segmentation, then >>>>> whose responsibility is it to reassemble t= he >>>>> payload before passing >>>>> it to the SF. >>>>> >>>>> Similar question for packet re-ordering. >>>>> >>>>> >>>>> __________________________________________= From: >>>>> Ron Parker >>>>> [Ron_Parker@affirmednetworks.__com >>>>> ] = Sent: >>>>> Wednesday, February 12, >>>>> 2014 11:25 PM To: Dave Dolson; Joel M. Hal= pern; >>>>> Paul Quinn >>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: >>>>> Re: [sfc] Framework >>>>> >>>>> Dave, >>>>> >>>>> Yes, that is a good point if we logically >>>>> separate the forwarding >>>>> function from the SFC-aware service functi= on, as >>>>> we should. The >>>>> forwarding function is concerned with only= the >>>>> inbound transport >>>>> header, the fixed portion of the service = header >>>>> containing the >>>>> chain information, and the outbound transp= ort >>>>> header. The >>>>> service function may look at the entirety = of the >>>>> service header and >>>>> would look at the encapsulated packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave Dols= on >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: Wedne= sday, >>>>> February 12, 2014 >>>>> 5:18 PM To: Joel M. Halpern; Ron Parker; P= aul >>>>> Quinn (paulq) Cc: >>>>> Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Subjec= t: RE: >>>>> [sfc] >>>>> Framework >>>>> >>>>> The forwarding plane might not even need t= o look >>>>> at the encapsulated >>>>> packet. >>>>> >>>>> For example, (if the SF Identifier is a VL= AN >>>>> tag), an Ethernet >>>>> switch can forward packets of the form: E= ther | >>>>> VLAN | BLOB. >>>>> >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Joel M. Halpern Sent: >>>>> Wednesday, February 12, 2014 4:30 PM To: R= on >>>>> Parker; Dave Dolson; >>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>> sfc@ietf.org ; Linda = Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> I agree as well. Yours, Joel >>>>> >>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>> >>>>> Hi, Dave. >>>>> >>>>> I Agree with your statement. And i= f the >>>>> total length of the >>>>> header is >>>>> >>>>> contained in the mandatory portion, the ha= rdware >>>>> implementation can >>>>> easily locate the encapsulated packet. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Dave = Dolson >>>>> [mailto:ddolson@sandvine.com >>>>> ] Sent: >>>>> Wednesday, February 12, >>>>> 2014 4:10 PM To: Ron Parker; Paul Quin= n >>>>> (paulq) Cc: Joel M. >>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>> ; Linda Dunbar Su= bject: >>>>> RE: [sfc] Framework >>>>> >>>>> I think a good approach would be: >>>>> >>>>> The information required for forwardin= g (the >>>>> SF Identifier) should >>>>> be in >>>>> >>>>> a mandatory fixed-size header. >>>>> >>>>> >>>>> Optional information (if any) is NOT t= o be >>>>> used for forwarding, but >>>>> is >>>>> >>>>> for consumption by one or more of the >>>>> applications in the chain. >>>>> >>>>> >>>>> Then the forwarding plane, and even th= e PDP, >>>>> can be agnostic about >>>>> the >>>>> >>>>> meta-data. >>>>> >>>>> >>>>> -Dave >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ] >>>>> On Behalf Of Ron Parker Sent: >>>>> Wednesday, February 12, 2014 4:05 PM T= o: >>>>> Paul Quinn (paulq) Cc: >>>>> Joel M. Halpern; Sumandra Majee; >>>>> sfc@ietf.org ;=20 >>>>> Linda Dunbar >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Paul, >>>>> >>>>> That is why I am proposing a hybrid wh= ere >>>>> extensions or options can >>>>> be >>>>> >>>>> added but the total length is contained in= the >>>>> fixed portion. I >>>>> can envision certain deployments (e.g., >>>>> Enterprise) where perhaps >>>>> extensions are not needed and the SFC >>>>> functionality is realized >>>>> in hardware. And, I can envision certain= other >>>>> deployments >>>>> (e.g., 3gpp) where the extension headers a= dd >>>>> sufficient value to >>>>> justify software based implementations. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Paul = Quinn >>>>> (paulq) >>>>> [mailto:paulq@cisco.com >>>>> ] Sent: Wednes= day, >>>>> February 12, 2014 >>>>> 3:40 PM To: Ron Parker Cc: Sumandra Ma= jee; >>>>> Linda Dunbar; Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> Hi, >>>>> >>>>> We certainly need to be very careful w= ith >>>>> variable length headers >>>>> when >>>>> >>>>> hardware platform are in play. >>>>> >>>>> >>>>> Ron, your examples of IP options and v= 6 EH >>>>> have both suffered from >>>>> >>>>> significant implementation and deployment >>>>> hurdles due to the >>>>> complexity and cost associated with hardwa= re >>>>> support for the >>>>> option/EH. >>>>> >>>>> >>>>> Paul >>>>> >>>>> On Feb 12, 2014, at 3:10 PM, Ron Parke= r >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Hi, Sumandra. >>>>> >>>>> Regarding service header flexibili= ty, I >>>>> completely agree. I >>>>> might >>>>> >>>>> suggest a compromise between hardware >>>>> friendliness and software >>>>> flexibility. If the header had the abil= ity to >>>>> add extensions >>>>> (perhaps similar to IPv6) but also had the >>>>> header length encoded in >>>>> the mandatory part (like IPv4), then a har= dware >>>>> implementation would >>>>> be free to skip over the extensions (in ca= ses >>>>> where the deployment >>>>> justifies ignoring the extensions). >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: >>>>> Sumandra Majee >>>>> [mailto:S.Majee@F5.com >>>>> ] Sent: >>>>> Wednesday, February 12, 2014 >>>>> 3:04 PM To: Ron Parker; Linda Dunb= ar; >>>>> Joel M. Halpern; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Framework >>>>> >>>>> For all of those reasons, = I >>>>> strongly support a=20 >>>>> canonical service >>>>> header that is independent= of >>>>> the transport methodology. >>>>> >>>>> >>>>> >>>>> I agree. However the format of ser= vice >>>>> header should be >>>>> standardized in >>>>> >>>>> a way that is flexible. Some of us would l= ike to >>>>> see variable length >>>>> header that is also HW friendly. The servi= ce >>>>> header can be >>>>> represented as a mandotory fixed length he= ader >>>>> (like IP >>>>> header) along with an optional variable le= ngth >>>>> attribute field. >>>>> Different services can be interested in >>>>> different metadata, for >>>>> example subscriber ID could be of interest= in >>>>> the mobile core >>>>> service chain only. >>>>> >>>>> >>>>> Sumandra >>>>> >>>>> On 2/12/14, 11:32 AM, "Ron Parker" >>>>> >>>>> >>>> >>>>> > >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Linda, >>>>> >>>>> My interpretation of the >>>>> architecture docs is that=20 >>>>> the service >>>>> function chain is built in an >>>>> abstract manner (i.e., SF-A th= en >>>>> SF-B >>>>> >>>>> then SF-C). >>>>> >>>>> Separately, a locator table pr= ovides >>>>> network location for >>>>> each of those service function= s. >>>>> In this way, you can >>>>> locate the service=20 >>>>> functions >>>>> >>>>> in >>>>> >>>>> a manner appropriate to the ty= pe of >>>>> transport you are >>>>> using. If you want that to b= e >>>>> interface+VLAN, >>>>> gateway-IP+MPLS label=20 >>>>> stack, IP >>>>> >>>>> address, >>>>> >>>>> GRE tunnel remote IP + key, et= c., >>>>> you can do that. You >>>>> can even potentially locate >>>>> different service functions th= at >>>>> reside in the same chain with >>>>> different flavors of >>>>> network locators. Another >>>>> justification to separate the >>>>> identity of a service function= from >>>>> its network location is >>>>> load balancing. If, for exam= ple, >>>>> SF-A had 3 IP addresses, >>>>> that would imply load balancin= g to 3 >>>>> instances using IP as a >>>>> transport layer. >>>>> >>>>> For all of those reasons, I st= rongly >>>>> support a canonical service >>>>> header that is independent of = the >>>>> transport >>>>> methodology. At a particula= r >>>>> node, the decision as to >>>>> where to go next should be bas= ed >>>>> solely on information carried = in >>>>> the canonical service header a= nd not >>>>> on the >>>>> >>>>> fields >>>>> >>>>> in the transport header. Tha= t is, >>>>> the SFC node discards >>>>> the transport header and extra= cts >>>>> the chain ID from the >>>>> service header. Through >>>>> mechanisms we have not yet beg= un >>>>> to discuss, the SFC node knows= how >>>>> to interpret the chain ID and >>>>> ultimately how to progress=20 >>>>> the packet. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- Fro= m: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Linda Dunbar >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 12:01 PM To: Joel M. >>>>> Halpern; sfc@ietf.org >>>>> Subject:= Re: >>>>> [sfc] Framework >>>>> >>>>> Agree with Joel's statement. >>>>> >>>>> I think a simple sentence belo= w >>>>> should be added Section 5.2 (S= FC >>>>> Classifier) to emphasize this = point. >>>>> >>>>> "A Service Chain Classifier no= de can >>>>> associate a unique Layer 2 >>>>> or 3 Label (e.g. VLAN, MPLS la= bel) >>>>> to the packets in the flow. >>>>> Those Layer 2 or 3 Label makes= it >>>>> easier for subsequent nodes >>>>> along the flow path to steer t= he >>>>> flow to the service functions >>>>> specified by the flow's=20 >>>>> service chain." >>>>> >>>>> >>>>> Linda -----Original Message---= -- >>>>> From: sfc >>>>> [mailto:sfc-bounces@ietf.org >>>>> ]= On >>>>> Behalf Of Joel M. Halpern >>>>> Sent: Wednesday, February 12, = 2014 >>>>> 10:20 AM To: >>>>> sfc@ietf.org >>>>> Subject: [sfc] Framework >>>>> >>>>> I was looking at the framework >>>>> proposal. The proposal has a v= ery >>>>> specific model of the scope of= the >>>>> transport header (that it is >>>>> derived from, and relates only= to, >>>>> the first service function to >>>>> which the packet will be direc= ted. >>>>> That is clearly an operational >>>>> model we need to support. >>>>> >>>>> However, I would like to allow= other >>>>> transport operational >>>>> models, such as the use of a V= LAN to >>>>> direct traffic along a >>>>> chain. Or the use of an MPLS = label, >>>>> or an MPLS label stack. >>>>> >>>>> Yours, Joel M. Halpern >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org=20 >>>>> >>>>> >>>>> 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 >>>>> =20 >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ sfc >>>>> mailing list >>>>> sfc@ietf.org >>>>> =20 >>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ sfc >>>>> mailing list >>>>> sfc@ietf.org >>>>> =20 >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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 Fri Feb 14 08:13:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C81A02F0 for ; Fri, 14 Feb 2014 08:13:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQrORDinTqk for ; Fri, 14 Feb 2014 08:13:06 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id AFF8B1A02ED for ; Fri, 14 Feb 2014 08:13:06 -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.0158.001; Fri, 14 Feb 2014 08:13:05 -0800 From: Ron Parker To: Linda Dunbar Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5Ug2Ayd84yH0WUHw67lVJO2JqyPG4AgAAqPQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYD//6Jp6oAAbhkAgAACIACAAAHIgIAAAcsAgAAEf4CAABClAIAAOgEAgAABwwCAAJG3AIAAlFQA//9+O58= Date: Fri, 14 Feb 2014 16:13:04 +0000 Message-ID: <480D4D53-E3D3-49D8-A23D-C9E8C05BABC3@affirmednetworks.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> , <4A95BA014132FF49AE685FAB4B9F17F645C80043@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C80043@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lhtsnK3SUgZWS9gXLeKujBU4ZfI Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:13:13 -0000 Linda=20 I would agree that SFC metadata is created and consumed by SFs, but not by = explicitly addressed applications, which are out of scope for SFC, IMO. S= FC provides the delivery mechanism for this metadata.=20 Ron > On Feb 14, 2014, at 10:59 AM, "Linda Dunbar" wr= ote: >=20 > Jim,=20 >=20 > Just to clarify, if you agree with what Joel said, then the "context is c= onsumable by SF", instead of "SFC" correct? >=20 > In that case, should this "metadata that are consumable by SF" be out of = the scope of SFC?=20 >=20 > Those metadata are inserted/consumed by applications or SFs, they are rea= lly the internal processing within applications & related service functions= .=20 >=20 > Linda >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Friday, February 14, 2014 8:07 AM > To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 > Yes agreed Joel. Metadata is really =B3context=B2 that is consumable by a= ny element of a given SFC. While our SFC encapsulation will of course carry= information relevant to the steering of traffic through the desired set of= service functions, I would not characterize that as metadata. >=20 >> On 2/13/14, 7:25 PM, "Joel M. Halpern" wrote: >>=20 >> I only consider the first of those to be metadata. The chain=20 >> identification in the service chaining header or the transport header=20 >> are not metadata. Treating fields which are needed for steering as=20 >> metadata induces massive confusion. can we please keep those two=20 >> concepts separate?! >>=20 >> Yours, >> Joel >>=20 >>> On 2/13/14, 7:18 PM, Linda Dunbar wrote: >>>=20 >>> I see two types of "metadata" being discussed here: >>>=20 >>> 1. The "flow metadata", like the transactions carried by http flows. >>> They are inserted by applications, or inserted by a service function=20 >>> to pass some "cookies" to the next one. (many proxy based service=20 >>> functions have those capability) >>>=20 >>> 2. The "Service Chain metadata", that are inserted by "Chain=20 >>> Classifier" or control plane to carry extra information (in additional= =20 >>> to Chain ID) for the purpose of controlling the sequence of functions=20 >>> on a chain. >>>=20 >>> Correct? >>>=20 >>> IMHO, the first bullet above are specific to applications or service=20 >>> functions internal processing. Many of today's proxy based service=20 >>> functions make changes to data packets, some of them make those=20 >>> changes for other service functions. Those changes won't be in the=20 >>> Service Chain Header field. >>>=20 >>> Linda >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee >>> Sent: Thursday, February 13, 2014 2:51 PM >>> To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>>=20 >>> I believe most of us agree that an out of bad signalling will not=20 >>> address the majority of requirement. Also a typical http flow carries=20 >>> many transactions and each can have different or additional=20 >>> classification. So a metadata can not be simple connected with one=20 >>> flow either. Current implementations of proxies and load balancers has= =20 >>> addressed this in many ways including custome header insertion. The=20 >>> custom header in this case equivalent of metadata vector. >>>=20 >>> I think we need an efficient way annotate actual data with inline=20 >>> metadata. I also strongly believe in solving the 80% of the use case >>>=20 >>> Regards >>> Sumandra >>> ________________________________________ >>> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 >>> [jmh@joelhalpern.com] >>> Sent: Thursday, February 13, 2014 11:51 AM >>> To: Jerome Moisand; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>>=20 >>> I know very well what GTP does in terms of correlators, and why. >>> If all you need is an identifier for the subscriber, carrying a short=20 >>> identifier, and using it to select the desired behavior that has been=20 >>> pre-populated when the subscribers session starts works really well. >>> That is part of why I am not objecting to having provision for=20 >>> out-of-band metadata. >>>=20 >>> However, claiming that a single such correlator is all that is needed=20 >>> for even 80% of SFC cases (and I very much supporting trying to focus=20 >>> on the 80% cases), just does not seem to work, given the broad range=20 >>> of requirements that we have seen. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/13/14, 2:35 PM, Jerome Moisand wrote: >>>> Joel, >>>>=20 >>>> Protocols like GTP and L2TP work exactly that, with a form of=20 >>>> session correlator between the data plane and the control plane. This= =20 >>>> is very handy for subscriber and service management. Also if a=20 >>>> correlator is defined as an opaque and unique number, then one can=20 >>>> avoid some of the pitfalls you described. Long-lived metadata is=20 >>>> clearly useful (and thanks for sharing, Reinaldo, will read), and=20 >>>> there is clear applicability to various service chaining needs. >>>>=20 >>>> Now this is just one way. The I-D Bruno referred to was just listing=20 >>>> this approach as one possible way among others. I totally agree with=20 >>>> you that other forms of metadata (like an outcome of the=20 >>>> classification of a packet or a sequence of a few packets) may not be= =20 >>>> suitable for out-of-band signaling. >>>>=20 >>>> Bottomline seems to be that we have too many options to choose from,=20 >>>> and none of them solving it all... Tough. >>>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 13, 2014 2:29 PM >>>> To: sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>>=20 >>>> As I understand it, the tsvwg (and aeon) work is about flow metadata. >>>> That is long-lived metadata of use across many packets. That does=20 >>>> indeed seem well-suited to out-of-band cases. >>>>=20 >>>> My concern is that in SFC, there are many cases which are at best=20 >>>> badly-addressed if we insist that they be solved using out-of-band=20 >>>> metadata. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>>>> There is draft about transport independent metadata. >>>>>=20 >>>>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi >>>>> ng >>>>> - >>>>> 01 >>>>>=20 >>>>> The complexities you mention are discussed there:=20 >>>>> variable-encoding, direction, security of metadata, etc. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> -RP >>>>>=20 >>>>>=20 >>>>>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>>>>>=20 >>>>>> While there are cases where out-of-band metadata makes sense,=20 >>>>>> There are many cases I would not want to try to cover that way. =20 >>>>>> The best examples are situations where the metadata changes from=20 >>>>>> packet to packet (such as the data produced by a DPI engine for=20 >>>>>> consumption by other applications in the chain.) >>>>>>=20 >>>>>> More importantly, if you are putting correlators in the packet, it = =20 >>>>>> is still very complex if you want to use one correlator to handle =20 >>>>>> metadata produced by several different entities (the initial =20 >>>>>> classifer, the DPI engine, ...) You quickly end up deciding that =20 >>>>>> you need several correlators. At which point we are back to=20 >>>>>> variable amounts of metadata. >>>>>>=20 >>>>>> The alternative is to require exceedingly specific and strong=20 >>>>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>>>> be a very bad idea. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>>>> resend to avoid "too many recipients" warning >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>>>> > wrote: >>>>>>>=20 >>>>>>> There are ways to signal variable length amounts of=20 >>>>>>> metadata without >>>>>>> needing an additional variable-length header on each data=20 >>>>>>> packet. >>>>>>>=20 >>>>>>> draft-rijsman-sfc-metadata-considerations-00 discusses=20 >>>>>>> some of the >>>>>>> possible approaches: out-of-band signaling (congruent or >>>>>>> non-congruent) or a hybrid approach using a fix-length=20 >>>>>>> in-band >>>>>>> correlator and out-of-band additional metadata. See=20 >>>>>>> sections 3.3, >>>>>>> 3.4 and 3.5 in the draft. >>>>>>>=20 >>>>>>> The issue of fixed-length encoding versus variable length=20 >>>>>>> encoding >>>>>>> is discussion in the challenges chapter in section 4.3. I=20 >>>>>>> should >>>>>>> probably mention the MTU and segmentation issues as well=20 >>>>>>> in that >>>>>>> section. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>>>> > wrote: >>>>>>>=20 >>>>>>> The variable length shim header is needed even if every >>>>>>> individual piece of metadata has a fixed length. >>>>>>> Different >>>>>>> service chains will need different combinations of=20 >>>>>>> metadata. So >>>>>>> the metadata portion of the header needs to be=20 >>>>>>> variable length. >>>>>>>=20 >>>>>>> I think the approach of a fixed length initial part,=20 >>>>>>> and a >>>>>>> variable length extension part, is the right model. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>>>>=20 >>>>>>> Yes, fragmentation and variable headers are=20 >>>>>>> usually a really >>>>>>> bad thing for forwarding performance. Let's not=20 >>>>>>> forget that >>>>>>> we live in a 100G-ish kind of world nowadays. >>>>>>>=20 >>>>>>> Now the question should be: WHY would we want to=20 >>>>>>> do that >>>>>>> (variable headers leading to fragmentation issues)? >>>>>>>=20 >>>>>>> For example, the type of metadata that may require >>>>>>> variable-length fields might be a better candidate=20 >>>>>>> for some >>>>>>> out-of-band signaling mechanism. If this is service >>>>>>> authorization data (e.g. a service=20 >>>>>>> profile/policy), this >>>>>>> sounds likely. Not 100% sure this is true for all=20 >>>>>>> use cases >>>>>>> though. Only a good understanding of use cases,=20 >>>>>>> grounded by >>>>>>> reflecting on existing network architectures (notably >>>>>>> broadband, fixed or mobile), would tell us if one=20 >>>>>>> approach >>>>>>> or another is the most appropriate. >>>>>>>=20 >>>>>>> Anyhoo, we're jumping way deep in the detailed=20 >>>>>>> protocol >>>>>>> design here. This seems a tad premature. >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>>>> ] On Behalf Of Dave=20 >>>>>>> Dolson >>>>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>>>> To: 'jmh@joelhalpern.com=20 >>>>>>> '; >>>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>>> '; >>>>>>> 'mohamed.boucadair@orange.com >>>>>>> '__; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; >>>>>>> 'paulq@cisco.com >>>>>>> ' >>>>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com=20 >>>>>>> ' >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> it is overall more efficient to support PMTU=20 >>>>>>> discovery >>>>>>> rather than fragmenting every large packet. The is=20 >>>>>>> why TCP >>>>>>> adopted it so early on. >>>>>>>=20 >>>>>>> The fragmenting also puts huge performance burden=20 >>>>>>> on the >>>>>>> service functions. >>>>>>> Fragmenting may also affect the ability of load=20 >>>>>>> balancers to >>>>>>> get each fragment to the correct destination. >>>>>>>=20 >>>>>>> So PMTU discovery SHOULD be used, in my opinion.=20 >>>>>>> By this I >>>>>>> mean the client or server is informed that its=20 >>>>>>> packets are >>>>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>>>>=20 >>>>>>> Some operators may wish to incur the extra cost to=20 >>>>>>> hide the >>>>>>> existence of the tunneling, when the elements of=20 >>>>>>> the chain >>>>>>> can support it, so we could consider that as an=20 >>>>>>> optional >>>>>>> mechanism. >>>>>>>=20 >>>>>>> -Dave >>>>>>>=20 >>>>>>>=20 >>>>>>> ----- Original Message ----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>>>> ] >>>>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>>>> To: Ron Parker >>>>>> >; >>>>>>> mohamed.boucadair@orange.com >>>>>>> >>>>>>> >>>>>> >__; Dave=20 >>>>>>> Dolson; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> ' >>>>>>> >>>>>> >; >>>>>>> 'paulq@cisco.com >>>>>>> ' >>>>>> > >>>>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>>>> ' >>>>>> >; >>>>>>> 'linda.dunbar@huawei.com=20 >>>>>>> ' >>>>>>> >>>>>> > >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> I mostly agree with you Ron. I can probably come=20 >>>>>>> up with >>>>>>> some other variations, but your second point is=20 >>>>>>> that the >>>>>>> transport must deal with the issue of frame size /=20 >>>>>>> fit. >>>>>>>=20 >>>>>>> I would note that if we assume that the carrying=20 >>>>>>> encaps >>>>>>> (IPv4/v6 outer) is being fragmented, then we are=20 >>>>>>> assuming >>>>>>> that the exit from service chaining can and will=20 >>>>>>> reassemble. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>>>>=20 >>>>>>> Joel, >>>>>>>=20 >>>>>>> That is an excellent point to consider when=20 >>>>>>> choosing >>>>>>> transport >>>>>>> encapsulations. If the transport encapsulation >>>>>>> is IPv4 >>>>>>> or IPv6 >>>>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, =20 >>>>>>> etc.), then >>>>>>> fragmentation and defragmentation are naturally >>>>>>> supported. If the >>>>>>> transport encapsulation is VLAN, MPLS, etc.,=20 >>>>>>> then I >>>>>>> believe one of the >>>>>>> following must be true: >>>>>>>=20 >>>>>>> * The end-to-end path is known to support the=20 >>>>>>> resulting >>>>>>> larger frames >>>>>>> * A path discovery mechanism is mandated by=20 >>>>>>> SFC when >>>>>>> non-IP transports >>>>>>> are used * An SFC-specific fragmentation=20 >>>>>>> header and >>>>>>> mechanisms must be >>>>>>> defined (i.e., >>>>>>>=20 >>>>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o >>>>>>> r- >>>>>>> f >>>>>>> rame) >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>> [mailto:jmh@joelhalpern.com >>>>>>> ] Sent: Thursday,=20 >>>>>>> February >>>>>>> 13, 2014 10:10 >>>>>>> AM To: mohamed.boucadair@orange.com >>>>>>> ; Dave=20 >>>>>>> Dolson; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; Ron=20 >>>>>>> Parker; >>>>>>> 'paulq@cisco.com ' Cc: >>>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com >>>>>>> ' Subject: >>>>>>> Re: [sfc] Framework >>>>>>>=20 >>>>>>> There is a related complexity. I hope that we=20 >>>>>>> expect to >>>>>>> support IPv6. >>>>>>> IPv6 explicitly prohibits network elements from >>>>>>> fragmenting end user >>>>>>> packets. >>>>>>>=20 >>>>>>> Yours, Joel >>>>>>>=20 >>>>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>>>> wrote: >>>>>>>=20 >>>>>>> Re-, >>>>>>>=20 >>>>>>> FWIW, one of the existing architecture drafts >>>>>>> includes the following >>>>>>> behavior >>>>>>>=20 >>>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02# >>>>>>> se >>>>>>> c >>>>>>> tion- >>>>>>> 6 >>>>>>>=20 >>>>>>>=20 >>>>>>> >>>>>> on- >>>>>>> 6>): >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> " >>>>>>>=20 >>>>>>> 6. Fragmentation Considerations >>>>>>>=20 >>>>>>> If adding the Service Chaining Header=20 >>>>>>> would result >>>>>>> in a fragmented >>>>>>> packet, the classifier should include a=20 >>>>>>> Service >>>>>>> Chaining Header in >>>>>>> each fragment. Doing so would prevent SF=20 >>>>>>> Nodes to >>>>>>> dedicate resource >>>>>>> to handle fragments. " >>>>>>>=20 >>>>>>> Cheers, Med >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- De : sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; >>>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>>>=20 >>>>>>> '; >>>>>>> 'jmh@joelhalpern.com =20 >>>>>>> '; >>>>>>> 'paulq@cisco.com=20 >>>>>>> ' Cc : >>>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com >>>>>>> '=20 >>>>>>> Objet >>>>>>> : Re: >>>>>>> [sfc] Framework >>>>>>>=20 >>>>>>> Good point to consider fragmentation. >>>>>>>=20 >>>>>>> We should design the encapsulation=20 >>>>>>> such that the >>>>>>> forwarding >>>>>>> functions do not need to reassemble. Each >>>>>>> fragment should be >>>>>>> independently forwardable; some SFs=20 >>>>>>> may choose >>>>>>> to ignore these >>>>>>> packets. >>>>>>>=20 >>>>>>> Any layer 2.5 protocol like VLAN or=20 >>>>>>> MPLS would >>>>>>> support this. >>>>>>> Otherwise, a reassembly layer could be=20 >>>>>>> added >>>>>>> after the forwarding >>>>>>> coordinates. Think of something like=20 >>>>>>> the >>>>>>> IPv6 >>>>>>> reassembly option >>>>>>> after a GRE header, for instance. >>>>>>>=20 >>>>>>> IP | GRE | reassem | frag data >>>>>>>=20 >>>>>>> We could alternatively mandate the=20 >>>>>>> inner IP be >>>>>>> fragmented and that >>>>>>> path-MTU discovery be supported. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ----- Original Message ----- From: >>>>>>> Nicolas BOUTHORS >>>>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>>>> ] >>>>>>> Sent: >>>>>>> Thursday, February 13, >>>>>>> 2014 04:13 AM To: Ron Parker >>>>>>> >>>>>>=20 >>>>>>> >; >>>>>>> Dave Dolson; Joel M. Halpern >>>>>>> >>>>>> >; Paul Quinn >>>>>>> (paulq) >>>>>> > Cc: Sumandra=20 >>>>>>> Majee >>>>>>> ; >>>>>>> sfc@ietf.org =20 >>>>>>> >>>>>> >; Linda Dunbar >>>>>>> >>>>>> > >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> If we do not enforce a fix header size=20 >>>>>>> we have >>>>>>> other implication. >>>>>>>=20 >>>>>>> There is the question of segmentation and >>>>>>> reassembly responsibility >>>>>>> as well. >>>>>>>=20 >>>>>>> If adding length to the service header=20 >>>>>>> forces >>>>>>> segmentation, then >>>>>>> whose responsibility is it to=20 >>>>>>> reassemble the >>>>>>> payload before passing >>>>>>> it to the SF. >>>>>>>=20 >>>>>>> Similar question for packet re-ordering. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> __________________________________________ From: >>>>>>> Ron Parker >>>>>>> [Ron_Parker@affirmednetworks.__com >>>>>>>=20 >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, >>>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>>>> Halpern; >>>>>>> Paul Quinn >>>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda Dunbar >>>>>>> Subject: >>>>>>> Re: [sfc] Framework >>>>>>>=20 >>>>>>> Dave, >>>>>>>=20 >>>>>>> Yes, that is a good point if we logically >>>>>>> separate the forwarding >>>>>>> function from the SFC-aware service=20 >>>>>>> function, as >>>>>>> we should. The >>>>>>> forwarding function is concerned with=20 >>>>>>> only the >>>>>>> inbound transport >>>>>>> header, the fixed portion of the=20 >>>>>>> service header >>>>>>> containing the >>>>>>> chain information, and the outbound=20 >>>>>>> transport >>>>>>> header. The >>>>>>> service function may look at the=20 >>>>>>> entirety of the >>>>>>> service header and >>>>>>> would look at the encapsulated packet. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: Dave=20 >>>>>>> Dolson >>>>>>> [mailto:ddolson@sandvine.com >>>>>>> ] Sent: >>>>>>> Wednesday, >>>>>>> February 12, 2014 >>>>>>> 5:18 PM To: Joel M. Halpern; Ron=20 >>>>>>> Parker; Paul >>>>>>> Quinn (paulq) Cc: >>>>>>> Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda Dunbar >>>>>>> Subject: RE: >>>>>>> [sfc] >>>>>>> Framework >>>>>>>=20 >>>>>>> The forwarding plane might not even=20 >>>>>>> need to look >>>>>>> at the encapsulated >>>>>>> packet. >>>>>>>=20 >>>>>>> For example, (if the SF Identifier is=20 >>>>>>> a VLAN >>>>>>> tag), an Ethernet >>>>>>> switch can forward packets of the form: >>>>>>> Ether | >>>>>>> VLAN | BLOB. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>>> Wednesday, February 12, 2014 4:30 PM To: >>>>>>> Ron >>>>>>> Parker; Dave Dolson; >>>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>>>> sfc@ietf.org ;=20 >>>>>>> Linda Dunbar >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> I agree as well. Yours, Joel >>>>>>>=20 >>>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>>>=20 >>>>>>> Hi, Dave. >>>>>>>=20 >>>>>>> I Agree with your statement. And >>>>>>> if the >>>>>>> total length of the >>>>>>> header is >>>>>>>=20 >>>>>>> contained in the mandatory portion,=20 >>>>>>> the hardware >>>>>>> implementation can >>>>>>> easily locate the encapsulated packet. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Dave Dolson >>>>>>> [mailto:ddolson@sandvine.com >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, >>>>>>> 2014 4:10 PM To: Ron Parker; Paul=20 >>>>>>> Quinn >>>>>>> (paulq) Cc: Joel M. >>>>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda=20 >>>>>>> Dunbar >>>>>>> Subject: >>>>>>> RE: [sfc] Framework >>>>>>>=20 >>>>>>> I think a good approach would be: >>>>>>>=20 >>>>>>> The information required for=20 >>>>>>> forwarding (the >>>>>>> SF Identifier) should >>>>>>> be in >>>>>>>=20 >>>>>>> a mandatory fixed-size header. >>>>>>>=20 >>>>>>>=20 >>>>>>> Optional information (if any) is=20 >>>>>>> NOT to be >>>>>>> used for forwarding, but >>>>>>> is >>>>>>>=20 >>>>>>> for consumption by one or more of the >>>>>>> applications in the chain. >>>>>>>=20 >>>>>>>=20 >>>>>>> Then the forwarding plane, and=20 >>>>>>> even the PDP, >>>>>>> can be agnostic about >>>>>>> the >>>>>>>=20 >>>>>>> meta-data. >>>>>>>=20 >>>>>>>=20 >>>>>>> -Dave >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> On Behalf Of Ron Parker Sent: >>>>>>> Wednesday, February 12, 2014 4:05=20 >>>>>>> PM >>>>>>> To: >>>>>>> Paul Quinn (paulq) Cc: >>>>>>> Joel M. Halpern; Sumandra Majee; >>>>>>> sfc@ietf.org=20 >>>>>>> ; Linda Dunbar >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> Paul, >>>>>>>=20 >>>>>>> That is why I am proposing a=20 >>>>>>> hybrid where >>>>>>> extensions or options can >>>>>>> be >>>>>>>=20 >>>>>>> added but the total length is=20 >>>>>>> contained in the >>>>>>> fixed portion. I >>>>>>> can envision certain deployments (e.g., >>>>>>> Enterprise) where perhaps >>>>>>> extensions are not needed and the SFC >>>>>>> functionality is realized >>>>>>> in hardware. And, I can envision >>>>>>> certain other >>>>>>> deployments >>>>>>> (e.g., 3gpp) where the extension=20 >>>>>>> headers add >>>>>>> sufficient value to >>>>>>> justify software based implementations. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Paul Quinn >>>>>>> (paulq) >>>>>>> [mailto:paulq@cisco.com >>>>>>> ] Sent: >>>>>>> Wednesday, >>>>>>> February 12, 2014 >>>>>>> 3:40 PM To: Ron Parker Cc:=20 >>>>>>> Sumandra Majee; >>>>>>> Linda Dunbar; Joel M. >>>>>>> Halpern; sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We certainly need to be very=20 >>>>>>> careful with >>>>>>> variable length headers >>>>>>> when >>>>>>>=20 >>>>>>> hardware platform are in play. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron, your examples of IP options=20 >>>>>>> and >>>>>>> v6 EH >>>>>>> have both suffered from >>>>>>>=20 >>>>>>> significant implementation and deployment >>>>>>> hurdles due to the >>>>>>> complexity and cost associated with=20 >>>>>>> hardware >>>>>>> support for the >>>>>>> option/EH. >>>>>>>=20 >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>> On Feb 12, 2014, at 3:10 PM, Ron=20 >>>>>>> Parker >>>>>>> >>>>>>=20 >>>>>>> > >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi, Sumandra. >>>>>>>=20 >>>>>>> Regarding service header=20 >>>>>>> flexibility, I >>>>>>> completely agree. I >>>>>>> might >>>>>>>=20 >>>>>>> suggest a compromise between hardware >>>>>>> friendliness and software >>>>>>> flexibility. If the header had the >>>>>>> ability to >>>>>>> add extensions >>>>>>> (perhaps similar to IPv6) but also had=20 >>>>>>> the >>>>>>> header length encoded in >>>>>>> the mandatory part (like IPv4), then a=20 >>>>>>> hardware >>>>>>> implementation would >>>>>>> be free to skip over the extensions=20 >>>>>>> (in cases >>>>>>> where the deployment >>>>>>> justifies ignoring the extensions). >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Sumandra Majee >>>>>>> [mailto:S.Majee@F5.com >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, 2014 >>>>>>> 3:04 PM To: Ron Parker; Linda=20 >>>>>>> Dunbar; >>>>>>> Joel M. Halpern; >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> For all of those=20 >>>>>>> reasons, I >>>>>>> strongly support a =20 >>>>>>> canonical service >>>>>>> header that is=20 >>>>>>> independent of >>>>>>> the transport=20 >>>>>>> methodology. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I agree. However the format of=20 >>>>>>> service >>>>>>> header should be >>>>>>> standardized in >>>>>>>=20 >>>>>>> a way that is flexible. Some of us=20 >>>>>>> would like to >>>>>>> see variable length >>>>>>> header that is also HW friendly. The=20 >>>>>>> service >>>>>>> header can be >>>>>>> represented as a mandotory fixed=20 >>>>>>> length header >>>>>>> (like IP >>>>>>> header) along with an optional=20 >>>>>>> variable length >>>>>>> attribute field. >>>>>>> Different services can be interested in >>>>>>> different metadata, for >>>>>>> example subscriber ID could be of=20 >>>>>>> interest in >>>>>>> the mobile core >>>>>>> service chain only. >>>>>>>=20 >>>>>>>=20 >>>>>>> Sumandra >>>>>>>=20 >>>>>>> On 2/12/14, 11:32 AM, "Ron=20 >>>>>>> Parker" >>>>>>>=20 >>>>>>> >>>>>>=20 >>>>>>> > >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Linda, >>>>>>>=20 >>>>>>> My interpretation of the >>>>>>> architecture docs is that=20 >>>>>>> the service >>>>>>> function chain is built in an >>>>>>> abstract manner (i.e.,=20 >>>>>>> SF-A then >>>>>>> SF-B >>>>>>>=20 >>>>>>> then SF-C). >>>>>>>=20 >>>>>>> Separately, a locator=20 >>>>>>> table provides >>>>>>> network location for >>>>>>> each of those service=20 >>>>>>> functions. >>>>>>> In this way, you can >>>>>>> locate the service=20 >>>>>>> functions >>>>>>>=20 >>>>>>> in >>>>>>>=20 >>>>>>> a manner appropriate to=20 >>>>>>> the type of >>>>>>> transport you are >>>>>>> using. If you want that to= =20 >>>>>>> be >>>>>>> interface+VLAN, >>>>>>> gateway-IP+MPLS label=20 >>>>>>> stack, IP >>>>>>>=20 >>>>>>> address, >>>>>>>=20 >>>>>>> GRE tunnel remote IP +=20 >>>>>>> key, etc., >>>>>>> you can do that. You >>>>>>> can even potentially locate >>>>>>> different service=20 >>>>>>> functions that >>>>>>> reside in the same chain with >>>>>>> different flavors of >>>>>>> network locators. Another >>>>>>> justification to separate the >>>>>>> identity of a service=20 >>>>>>> function from >>>>>>> its network location is >>>>>>> load balancing. If, for=20 >>>>>>> example, >>>>>>> SF-A had 3 IP addresses, >>>>>>> that would imply load=20 >>>>>>> balancing to 3 >>>>>>> instances using IP as a >>>>>>> transport layer. >>>>>>>=20 >>>>>>> For all of those reasons,=20 >>>>>>> I strongly >>>>>>> support a canonical service >>>>>>> header that is independent=20 >>>>>>> of the >>>>>>> transport >>>>>>> methodology. At a=20 >>>>>>> particular >>>>>>> node, the decision as to >>>>>>> where to go next should be=20 >>>>>>> based >>>>>>> solely on information=20 >>>>>>> carried in >>>>>>> the canonical service=20 >>>>>>> header and not >>>>>>> on the >>>>>>>=20 >>>>>>> fields >>>>>>>=20 >>>>>>> in the transport header. =20 >>>>>>> That is, >>>>>>> the SFC node discards >>>>>>> the transport header and=20 >>>>>>> extracts >>>>>>> the chain ID from the >>>>>>> service header. Through >>>>>>> mechanisms we have not yet=20 >>>>>>> begun >>>>>>> to discuss, the SFC node=20 >>>>>>> knows how >>>>>>> to interpret the chain ID and >>>>>>> ultimately how to progress =20 >>>>>>> the packet. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc >>>>>>>=20 >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>>=20 >>>>>>> ] On >>>>>>> Behalf Of Linda Dunbar >>>>>>> Sent: Wednesday, February=20 >>>>>>> 12, 2014 >>>>>>> 12:01 PM To: Joel M. >>>>>>> Halpern; sfc@ietf.org >>>>>>> >>>>>>> Subject: Re: >>>>>>> [sfc] Framework >>>>>>>=20 >>>>>>> Agree with Joel's statement. >>>>>>>=20 >>>>>>> I think a simple sentence=20 >>>>>>> below >>>>>>> should be added Section=20 >>>>>>> 5.2 (SFC >>>>>>> Classifier) to emphasize=20 >>>>>>> this point. >>>>>>>=20 >>>>>>> "A Service Chain=20 >>>>>>> Classifier node can >>>>>>> associate a unique Layer 2 >>>>>>> or 3 Label (e.g. VLAN,=20 >>>>>>> MPLS >>>>>>> label) >>>>>>> to the packets in the flow. >>>>>>> Those Layer 2 or 3 Label=20 >>>>>>> makes it >>>>>>> easier for subsequent nodes >>>>>>> along the flow path to=20 >>>>>>> steer the >>>>>>> flow to the service functions >>>>>>> specified by the flow's =20 >>>>>>> service chain." >>>>>>>=20 >>>>>>>=20 >>>>>>> Linda -----Original >>>>>>> Message----- >>>>>>> From: sfc >>>>>>>=20 >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>>=20 >>>>>>> ] On >>>>>>> Behalf Of Joel M. Halpern >>>>>>> Sent: Wednesday, February=20 >>>>>>> 12, 2014 >>>>>>> 10:20 AM To: >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: [sfc] Framework >>>>>>>=20 >>>>>>> I was looking at the=20 >>>>>>> framework >>>>>>> proposal. The proposal has=20 >>>>>>> a very >>>>>>> specific model of the=20 >>>>>>> scope of the >>>>>>> transport header (that it is >>>>>>> derived from, and relates=20 >>>>>>> only to, >>>>>>> the first service function to >>>>>>> which the packet will be=20 >>>>>>> directed. >>>>>>> That is clearly an=20 >>>>>>> operational >>>>>>> model we need to support. >>>>>>>=20 >>>>>>> However, I would like to=20 >>>>>>> allow other >>>>>>> transport operational >>>>>>> models, such as the use of=20 >>>>>>> a VLAN to >>>>>>> direct traffic along a >>>>>>> chain. Or the use of an=20 >>>>>>> MPLS label, >>>>>>> or an MPLS label stack. >>>>>>>=20 >>>>>>> Yours, Joel M. Halpern >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=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 >>>=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 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 14 08:16:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA21A02D9 for ; Fri, 14 Feb 2014 08:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yru2TTmh3NtC for ; Fri, 14 Feb 2014 08:16:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 801F71A02CE for ; Fri, 14 Feb 2014 08:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15829; q=dns/txt; s=iport; t=1392394604; x=1393604204; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=onO1CYu8kaVbY/pbPQ5YXv6hfZEx7EVnFv/C+Zq+Vfw=; b=DS7dw34bCCUtzuWa4Ze8UPl4VXJj1EHJSSw5EEzcgudPD9Kexh0tudpe g+W0JtTW1XMXlo+CT+5pYMhG8TUnlBhIxmrCpZLkb3fNW1olKbPKAwcsv J9e06BlYsBilIT4b4BksUOU8j5sZLDdvTAcKJPlsV/+FqGY3vU1xUZa0v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFADdB/lKtJV2a/2dsb2JhbABZgkJEOFe/MoEUFnSCJgEBBAEBAWQHCxACAQg/BycLFBEBAQQOBYgFDcgQEwSOJVAEBwKDIoEUBIkQjxySI4MtgWgiIA X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208,217";a="304141652" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 14 Feb 2014 16:16:22 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1EGGMaK028861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 16:16:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 10:16:22 -0600 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [sfc] comments on draft-quinn-nsh Thread-Index: Ac8pjlJAii6JsZ8NQ9uMaAqBcjV9pgARA1MA Date: Fri, 14 Feb 2014 16:16:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_B34F45E2473E489EA2340BBEE4E5E07Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0eHePZ3ttXNrcGvo6xAzwA_mh_o Cc: "sfc@ietf.org" Subject: Re: [sfc] comments on draft-quinn-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:16:49 -0000 --_000_B34F45E2473E489EA2340BBEE4E5E07Cciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ron, As always, thanks for your comments. See you in London? On Feb 14, 2014, at 9:23 AM, Ron Parker > wrote: Hello authors of draft-quinn-nsh. Thanks for posting the update. I ha= ve concerns on the metadata portion of the proposal. I think there are s= ome requirements that the group should work through, first, before we can p= in down the actual bits and bytes. For example, a very partial list of re= quirements that come to mind: NSH provides an envelop, it doesn't describe or preclude your scenarios bel= ow. Certainly, any new encap will require balancing several sets of requir= ements. * Registered metadata types o Like the official IPv4 options or the official IPv6 extension headers * Vendor specific metadata types o Using an OUI of some sort Both of these types can be carried via NSH if required. The broad applica= bility of context data is going to make it hard to have a widespread regis= ter. For instance, the metadata requirements for mobility are vastly diffe= rent than those for data center. Assignment of semantics can be handled = via a common control plane. Having said that, I suspect we'll see de-facto types of metadata per vertic= al/use cases. For example, as the mobility use case draft evolve, I hope t= he reach consensus on the information exchanged for that use case. * Flexible length metadata o For example, a 64-bit subscriber ID Although very seductive, variable length headers have profound implication = on a wide range of platforms. Don't think of the fixed size of header of= carrying all context explicitly, rather, think of the context, when needed= , as providing a reference to richer data. Using a fixed sized header to p= oint to richer context information provides a middle road. * Support for both long lived (for the duration of the flow or unti= l changed or revoked) and temporal (packet by packet) inband metadata o Acknowledgement scheme that long lived data no longer needs to be inser= ted To me, this is addressed under the envelop category: a signaling mechanism = that will be implemented via the SFC encap, there's nothing in NSH that pre= cludes this. There was an example in Vancouver where 2 non-adjacent coordinated service = functions shared a priority discard eligibility between them. In draft-ma= -sfc, there is the need to insert private correlation handles. All of th= is can be happening at the same time. The metadata capabilities need to s= upport these types of models, and more, if SFC is really going to enable in= novation in the networks. Thanks. Ron _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_B34F45E2473E489EA2340BBEE4E5E07Cciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ron,

As always, thanks for your comments.

See you in London?



On Feb 14, 2014, at 9:23 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:
Hello authors of draft-quinn-nsh.   Thanks for posting the update= .     I have concerns on the metadata portion of the pr= oposal.    I think there are some requirements that the grou= p should work through, first, before we can pin down the actual bits and by= tes.   For example, a very partial list of requirements that come to mind:

NSH provides an envelop, it doesn't describe or preclude your scenario= s below.  Certainly, any new encap will require balancing several sets= of requirements.   


 
=B7     = ;    Registered metadata types
o   Like the official IPv4 options or the official IPv6 extension headers
=B7     = ;    Vendor specific metadata types
o   Using an OUI of some sort

Both of these types can be carried via NSH if required.   The bro= ad applicability of context data  is going to make it hard to have a w= idespread register.  For instance, the metadata requirements for mobil= ity are vastly different than those for data center.   Assignment of  semantics can be handled via a common control pl= ane.

Having said that, I suspect we'll see de-facto types of metadata = per vertical/use cases.  For example, as the mobility use case draft e= volve, I hope the reach consensus on the information exchanged for that use= case.



=B7     = ;    Flexible length metadata
o   For example, a 64-bit subscriber ID

Although very seductive, variable length headers have profound implica= tion on a wide range of platforms.    Don't think of the fixed si= ze of header of carrying all context explicitly, rather, think of the conte= xt, when needed, as providing a reference to richer data.  Using a fixed sized header to point to richer contex= t information provides a middle road.


=B7     = ;    Support for both long lived (for the duration of the flow or until changed or revo= ked) and temporal (packet by packet) inband metadata
o   Acknowledgemen= t scheme that long lived data no longer needs to be inserted

To me, this is addressed under the envelop category: a signaling mecha= nism that will be implemented via the SFC encap, there's nothing in NSH tha= t precludes this. 


 
There was an example in Vancouver where 2 non-adjacent coordinated service = functions shared a priority discard eligibility between them.   I= n draft-ma-sfc, there is the need to insert private correlation handles.&nb= sp;   All of this can be happening at the same time.   The metadata capabilities need to support these types of= models, and more, if SFC is really going to enable innovation in the netwo= rks.
 
Thanks.
 
    Ron
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/li= stinfo/sfc

--_000_B34F45E2473E489EA2340BBEE4E5E07Cciscocom_-- From nobody Fri Feb 14 10:02:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6191A0370; Fri, 14 Feb 2014 10:01:54 -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 6Ww910WtqCXF; Fri, 14 Feb 2014 10:01:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 243661A02E8; Fri, 14 Feb 2014 10:01:51 -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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214180151.25720.52214.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:01:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/audIb02S-6BSmki4CA24YRNfgE8 Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-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: Fri, 14 Feb 2014 18:01:54 -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 Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-02.txt Pages : 18 Date : 2014-02-14 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-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 Fri Feb 14 11:40:16 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A671A0401 for ; Fri, 14 Feb 2014 11:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 V7JlAZkmIuWH for ; Fri, 14 Feb 2014 11:40:08 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id C57741A0397 for ; Fri, 14 Feb 2014 11:39:19 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Fri, 14 Feb 2014 14:39:17 -0500 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-vlan-00.txt Thread-Index: AQHPKbtPKdOcCli6/kyVOz+kPxQ2Q5q1JKyQ Date: Fri, 14 Feb 2014 19:39:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.7.137.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3W3IgFxWMxOM2w8Qhy7PKgS1VI0 Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-vlan-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:40:12 -0000 QXMgcmVxdWVzdGVkIGJ5IHNvbWUgb2YgeW91LCB0aGlzIGRyYWZ0IGRldGFpbHMgU2FuZHZpbmUn cyBleHBlcmllbmNlIHdpdGggc2VydmljZSBjaGFpbmluZyB1c2luZyBWTEFOcy4NCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkg MTQsIDIwMTQgMjozMSBQTQ0KVG86IERhdmUgRG9sc29uOyBEYXZlIERvbHNvbg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kb2xzb24tc2ZjLXZsYW4tMDAudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbHNvbi1zZmMtdmxhbi0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGF2aWQgRG9sc29uIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kb2xzb24tc2ZjLXZs YW4NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlWTEFOIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcN CkRvY3VtZW50IGRhdGU6CTIwMTQtMDItMTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kb2xzb24tc2ZjLXZsYW4tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9sc29uLXNmYy12bGFuLw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbHNvbi1zZmMt dmxhbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gaW1w bGVtZW50YXRpb24gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMNCiAgIChTRkMpIHV0aWxpemlu ZyBzdGFuZGFyZCBWTEFOIHN3aXRjaGluZywgYXBwcm9wcmlhdGUgZm9yIGJ1bXAtaW4tdGhlLQ0K ICAgd2lyZSBTZXJ2aWNlIEZ1bmN0aW9uIG5vZGVzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Fri Feb 14 12:18:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8660B1A0309 for ; Fri, 14 Feb 2014 12:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz5TRdDcPtBX for ; Fri, 14 Feb 2014 12:18:36 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id CD9331A023F for ; Fri, 14 Feb 2014 12:18:35 -0800 (PST) Received: from mail4-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 20:18:34 +0000 Received: from mail4-ch1 (localhost [127.0.0.1]) by mail4-ch1-R.bigfish.com (Postfix) with ESMTP id E89236020C for ; Fri, 14 Feb 2014 20:18:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I936eI148cI542I1521Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail4-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(54094003)(199002)(13464003)(189002)(52604005)(377424004)(377454003)(53806001)(80022001)(85306002)(65816001)(54316002)(54356001)(56776001)(19580395003)(77982001)(93516002)(80976001)(50986001)(74662001)(76482001)(66066001)(51856001)(46102001)(94316002)(47446002)(86362001)(74502001)(81816001)(63696002)(31966008)(47736001)(33646001)(93136001)(83322001)(94946001)(15975445006)(47976001)(69226001)(81686001)(49866001)(85852003)(4396001)(15202345003)(76796001)(90146001)(74876001)(74316001)(2656002)(87266001)(87936001)(74366001)(81342001)(81542001)(74706001)(76576001)(76786001)(95666001)(92566001)(56816005)(59766001)(19580405001)(95416001)(79102001)(83072002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB714; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:BCFCFD9D.ADF22FCA.35F03DCF.48E41B60.2033F; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail4-ch1 (localhost.localdomain [127.0.0.1]) by mail4-ch1 (MessageSwitch) id 1392409111776503_26753; Fri, 14 Feb 2014 20:18:31 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail4-ch1.bigfish.com (Postfix) with ESMTP id B8E992005E for ; Fri, 14 Feb 2014 20:18:31 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 20:18:31 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 20:18:30 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 20:18:29 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 20:18:29 +0000 From: Jerome Moisand To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-vlan-00.txt Thread-Index: AQHPKbtPKdOcCli6/kyVOz+kPxQ2Q5q1JKyQgAAH+sA= Date: Fri, 14 Feb 2014 20:18:28 +0000 Message-ID: <60c63abb74c34d88b9f1e04aafa07ef6@CO2PR05MB716.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 01221E3973 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jbjbp0j5pCE18OXaKkc3G0CZ4Zk Subject: Re: [sfc] New Version Notification for draft-dolson-sfc-vlan-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:18:38 -0000 Dave, Thanks for sharing. So in essence, this is using preconfigured VLANs to assemble a service over= lay. And a service classifier of sorts is used to steer traffic to the prop= er VLAN.=20 Generalizing a bit, one can that with various forms of preconfigured tunnel= s (IP, MPLS, VLAN, etc) as long as the SFs can use them as input and output= 'logical' interfaces.=20 Yup, agreed, this has been deployed in various shapes or forms in the past = decade. Nothing wrong with it as long as the use case stays simple. And we = should not underestimate the fact that such simple use cases are rather com= monplace, while more complex use cases are less common. I wonder if we should not extend the scope of this draft to 'existing pract= ices'? Tx Jerome -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Friday, February 14, 2014 2:39 PM To: sfc@ietf.org Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-vlan-00.tx= t As requested by some of you, this draft details Sandvine's experience with = service chaining using VLANs. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, February 14, 2014 2:31 PM To: Dave Dolson; Dave Dolson Subject: New Version Notification for draft-dolson-sfc-vlan-00.txt A new version of I-D, draft-dolson-sfc-vlan-00.txt has been successfully submitted by David Dolson and posted to the IETF repository. Name: draft-dolson-sfc-vlan Revision: 00 Title: VLAN Service Function Chaining Document date: 2014-02-14 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-dolson-sfc-vlan-0= 0.txt Status: https://datatracker.ietf.org/doc/draft-dolson-sfc-vlan/ Htmlized: http://tools.ietf.org/html/draft-dolson-sfc-vlan-00 Abstract: This document describes an implementation of Service Function Chains (SFC) utilizing standard VLAN switching, appropriate for bump-in-the- wire Service Function nodes. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 14 14:17:44 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8071A01C4 for ; Fri, 14 Feb 2014 14:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 plc8z5_qd9nY for ; Fri, 14 Feb 2014 14:17:37 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 284F71A00FA for ; Fri, 14 Feb 2014 14:17:37 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Fri, 14 Feb 2014 17:17:35 -0500 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAHllm6A= Date: Fri, 14 Feb 2014 22:17:34 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.7.137.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CIkZNe3BRu1naN7zmO4PCvVqFmk Subject: Re: [sfc] I-D Action: draft-boucadair-sfc-requirements-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: Fri, 14 Feb 2014 22:17:40 -0000 Reading through this... I wondering about the Discovery requirements, and wondering if they should = be separated from the forwarding requirements. I.e., can we accept a standard on the forwarding plane without addressing t= hese discovery elements (yet) ? Just as routing can be accomplished with manual configuration, couldn't the= same be said of SFC? And I suspect some operators would want to have a highly-controlled orchest= ration approach, not an auto-discovery approach. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Wednesday, February 12, 2014 4:49 AM To: sfc@ietf.org Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Dear all, This new version integrates inputs from NTT representatives.=20 The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=3Ddraft-bouc= adair-sfc-requirements-01&difftype=3D--html&submit=3DGo!&url2=3Ddraft-bouca= dair-sfc-requirements-03=20 Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 12 f=E9vrier 2014 10:46 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-requirements-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining Authors : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Kengo Naito Filename : draft-boucadair-sfc-requirements-03.txt Pages : 14 Date : 2014-02-12 Abstract: This document identifies the requirements for the Service Function Chaining (SFC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 14 19:44:57 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873C21A001A for ; Fri, 14 Feb 2014 19:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 5Cb4DE5tmUl3 for ; Fri, 14 Feb 2014 19:44:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70A1A000E for ; Fri, 14 Feb 2014 19:44:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD64620; Sat, 15 Feb 2014 03:44:51 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:44:26 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:44:48 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.204]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 11:44:40 +0800 From: Jiangyuanlong To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-jiang-sfc-arch-01.txt Thread-Index: AQHPKYBgAL0/KvVdxEKZ9lyVGppwr5q1idrw Date: Sat, 15 Feb 2014 03:44:39 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6D55F1@szxema506-mbs.china.huawei.com> References: <20140214122909.16237.70770.idtracker@ietfa.amsl.com> In-Reply-To: <20140214122909.16237.70770.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Whu_VbaxDb-PatM-iO7pLH0Py-E Cc: "Hongyu Li \(Julio\)" Subject: [sfc] FW: New Version Notification for draft-jiang-sfc-arch-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: Sat, 15 Feb 2014 03:44:56 -0000 RGVhciBTRkNlcnMsDQoNCldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1q aWFuZy1zZmMtYXJjaCwgd2l0aCBtb3JlIGRlc2NyaXB0aW9ucyBvbiB0aGUgU0ZDIHN0YWNrLCBT RkMgY29udHJvbGxlciBhbmQgYWxpZ25lZCB3aXRoIHNvbWUgdGVybWlub2xvZ2llcyBpbiB0aGUg UFMgZHJhZnQuDQpZb3VyIGNvbW1lbnRzIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQpCZXN0 IHJlZ2FyZHMsDQpZdWFubG9uZyAmIEhvbmd5dQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA4OjI5IFBNDQpU bzogSG9uZ3l1IExpIChKdWxpbyk7IEppYW5neXVhbmxvbmc7IEhvbmd5dSBMaSAoSnVsaW8pOyBK aWFuZ3l1YW5sb25nDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWppYW5nLXNmYy1hcmNoLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1q aWFuZy1zZmMtYXJjaC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg WXVhbmxvbmcgSmlhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LWppYW5nLXNmYy1hcmNoDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJQW4gQXJjaGl0 ZWN0dXJlIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCkRvY3VtZW50IGRhdGU6CTIwMTQt MDItMTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEyDQpVUkw6ICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmct c2ZjLWFyY2gtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtamlhbmctc2ZjLWFyY2gvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctc2ZjLWFyY2gtMDENCkRpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy1zZmMtYXJjaC0w MQ0KDQpBYnN0cmFjdDoNCiAgIEFzIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gaXMgb3BlbmluZyB0 aGUgZ2F0ZSB0byBtdWNoIG1vcmUgaW5ub3ZhdGl2ZQ0KICAgc2VydmljZXMgZm9yIHNlcnZpY2Ug cHJvdmlkZXJzLCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpDQogICBwcm92aWRlcyBh IGZsZXhpYmxlIHdheSBvZiBzZXJ2aWNlIHByb3Zpc2lvbmluZyBhbmQgZmFjaWxpdGF0ZXMgdGhl aXINCiAgIGRlcGxveW1lbnRzLg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZ2VuZXJh bCBhYnN0cmFjdCBhcmNoaXRlY3R1cmUgZm9yIHNlcnZpY2UNCiAgIGNoYWluaW5nLiBJdCBpcyBh IGZsZXhpYmxlIGFuZCBzY2FsYWJsZSBhcmNoaXRlY3R1cmUgd2hpY2ggY2FuDQogICBmdWxmaWxs IHJlcXVpcmVtZW50cyBvZiBTRkMuIFNvbWUgc29sdXRpb25zIGJhc2VkIG9uIHRoaXMNCiAgIGFy Y2hpdGVjdHVyZSBhcmUgYWxzbyBkaXNjdXNzZWQgYW5kIGNvbXBhcmVkLiBUaGlzIGFyY2hpdGVj dHVyZSBjYW4NCiAgIGJlIHVzZWQgYXMgYSBndWlkZWxpbmUgYW5kIGFsc28gYSBjcml0ZXJpb24g Zm9yIHRoZSBkZXNpZ24gb2YgU0ZDLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Mon Feb 17 06:15:42 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D741A01FE for ; Mon, 17 Feb 2014 06:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AzHog7a_VhE6 for ; Mon, 17 Feb 2014 06:15:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EBE421A015B for ; Mon, 17 Feb 2014 06:15:38 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 3EF5D2DC110; Mon, 17 Feb 2014 15:15:35 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1CECE2380AC; Mon, 17 Feb 2014 15:15:35 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 17 Feb 2014 15:15:35 +0100 From: To: Dave Dolson , "sfc@ietf.org" Date: Mon, 17 Feb 2014 15:15:22 +0100 Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAHllm6AAiuaqsA== Message-ID: <94C682931C08B048B7A8645303FDC9F36F4D253011@PUEXCB1B.nanterre.francetelecom.fr> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.17.104815 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aVqKwQNq6aTZRGvlsLq7XFwCTeI Subject: Re: [sfc] I-D Action: draft-boucadair-sfc-requirements-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, 17 Feb 2014 14:15:41 -0000 Dear Dave,=20 Thank you for the comment and for raising this point.=20 As you can notice in Section 3, SF discovery is a SHOULD not a MUST. The de= tailed discovery required applied ** only ** when such a solution is to be = deployed. An SFC solution can be deployed without such feature. FWIW, the SFC archite= cture defined in http://tools.ietf.org/html/draft-boucadair-sfc-framework-0= 2 says the following: o For the sake of efficiency, policy enforcement is automated (but policies can be statically enforced, for example). BTW, one could even argue that a basic SFC solution must work without requi= ring any control plane at all. Just like Diffserv architecture! We didn't added an explicit requirement for the static/manual config becaus= e we thought the "SHOULD" language is an implicit indication. Do you think this should be explicated in the requirement list? Cheers, Med >-----Message d'origine----- >De=A0: Dave Dolson [mailto:ddolson@sandvine.com] >Envoy=E9=A0: vendredi 14 f=E9vrier 2014 23:18 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: RE: I-D Action: draft-boucadair-sfc-requirements-03.txt > >Reading through this... > >I wondering about the Discovery requirements, and wondering if they should >be separated from the forwarding requirements. >I.e., can we accept a standard on the forwarding plane without addressing >these discovery elements (yet) ? > > >Just as routing can be accomplished with manual configuration, couldn't th= e >same be said of SFC? > > >And I suspect some operators would want to have a highly-controlled >orchestration approach, not an auto-discovery approach. > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >mohamed.boucadair@orange.com >Sent: Wednesday, February 12, 2014 4:49 AM >To: sfc@ietf.org >Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > >Dear all, > >This new version integrates inputs from NTT representatives. > >The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=3Ddraft- >boucadair-sfc-requirements-01&difftype=3D--html&submit=3DGo!&url2=3Ddraft- >boucadair-sfc-requirements-03 > >Cheers, >Med > >-----Message d'origine----- >De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: mercredi 12 f=E9vrier 2014 10:46 >=C0=A0: i-d-announce@ietf.org >Objet=A0: I-D Action: draft-boucadair-sfc-requirements-03.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Requirements for Service Function Chaining > Authors : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Ron Parker > Carlos Pignataro > Kengo Naito > Filename : draft-boucadair-sfc-requirements-03.txt > Pages : 14 > Date : 2014-02-12 > >Abstract: > This document identifies the requirements for the Service Function > Chaining (SFC). > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-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/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 17 16:28:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E731A00CB for ; Mon, 17 Feb 2014 16:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbvsQYIZ8Rih for ; Mon, 17 Feb 2014 16:27:56 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 84C551A0291 for ; Mon, 17 Feb 2014 16:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50951; q=dns/txt; s=iport; t=1392683273; x=1393892873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z3s8TlfllQ9WM4ikp4D34nHftM/wIoZiaYyA869Nymc=; b=cnnBC4r/XiWgxoOhmeCiKfrk0luKLzwtfDs4oK9I6OAy5dZM/31wJCip 9bs5Kz3+qaua5Rxy5ppfzfQQ8zyNerdwGyiflVtBCAF0PR4m4bAJXTU7L PDXBhv2WnQD6PE9XhshZNgGGzvpTkDbP8gBekXvAQBIJYhYgA07CGJjce A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAI+oAlOtJV2Y/2dsb2JhbABQCYMGOMAigRYWdIIeBwEBAQMBAQEBFwFKAgcLBQcEAgEIEQEDAQEBJwchBgsUAwYIAgQOBYVJB4IhAwkIDcJWDYgPF4xngT8oCCsHAgSDHoEUBIkQjTCBbIEyiyyFRYMt X-IronPort-AV: E=Sophos;i="4.95,864,1384300800"; d="scan'208";a="304502986" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 18 Feb 2014 00:27:51 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I0Rpc7031312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 00:27:51 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.212]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 18:27:51 -0600 From: "Jim Guichard (jguichar)" To: Linda Dunbar Thread-Topic: [sfc] Framework Thread-Index: AQHPKA5UwnREFNrUG0aiDEicuLyqC5qyPG4AgAAqPQCAAAjqgIAAAfCAgAAIFwCAAAcWAIAAAVmAgAAECQCAAAGvgIAADUiAgAACHACAALUQgIAAOXoAgAALygCAAB5QgIAAAmMAgAADlgCAAAjLAIAAAu8AgAAiSYD//6Jp6oAAbhkAgAACIACAAAHIgIAAAcsAgAAEf4CAABClAIAAOgEAgAABwwCAAJG3AIAAcs0AgATg/r8= Date: Tue, 18 Feb 2014 00:27:51 +0000 Message-ID: <9579F014-0833-436E-8FD6-F078E753F06E@cisco.com> References: <52FD1D03.9030905@joelhalpern.com> <245f4cf6d3824c1f8758ddeefdc7c16b@CO2PR05MB716.namprd05.prod.outlook.com> <52FD2249.9020802@joelhalpern.com> <0BF7E0211CA62B42AE3FD4020E41609884A079D0@SEAEMBX01.olympus.F5Net.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FC87@dfweml701-chm.china.huawei.com> <52FD6262.1040605@joelhalpern.com> , <4A95BA014132FF49AE685FAB4B9F17F645C80043@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C80043@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xiOUomK7GSA-_hiHXTynT5WnlD8 Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:28:01 -0000 Hi Linda, Apologies for my late response. Inline. Sent from my iPhone > On Feb 14, 2014, at 10:57 AM, "Linda Dunbar" wr= ote: >=20 > Jim,=20 >=20 > Just to clarify, if you agree with what Joel said, then the "context is c= onsumable by SF", instead of "SFC" correct? Jim> could be either and SFC should support both. >=20 > In that case, should this "metadata that are consumable by SF" be out of = the scope of SFC?=20 Jim> definition of the metadata structure probably; carrying it in SFC abso= lutely not. >=20 > Those metadata are inserted/consumed by applications or SFs, they are rea= lly the internal processing within applications & related service functions= .=20 Jim> yes but the SFC encap needs to carry it. >=20 > Linda >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Friday, February 14, 2014 8:07 AM > To: Joel M. Halpern; Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] Framework >=20 > Yes agreed Joel. Metadata is really =B3context=B2 that is consumable by a= ny element of a given SFC. While our SFC encapsulation will of course carry= information relevant to the steering of traffic through the desired set of= service functions, I would not characterize that as metadata. >=20 >> On 2/13/14, 7:25 PM, "Joel M. Halpern" wrote: >>=20 >> I only consider the first of those to be metadata. The chain=20 >> identification in the service chaining header or the transport header=20 >> are not metadata. Treating fields which are needed for steering as=20 >> metadata induces massive confusion. can we please keep those two=20 >> concepts separate?! >>=20 >> Yours, >> Joel >>=20 >>> On 2/13/14, 7:18 PM, Linda Dunbar wrote: >>>=20 >>> I see two types of "metadata" being discussed here: >>>=20 >>> 1. The "flow metadata", like the transactions carried by http flows. >>> They are inserted by applications, or inserted by a service function=20 >>> to pass some "cookies" to the next one. (many proxy based service=20 >>> functions have those capability) >>>=20 >>> 2. The "Service Chain metadata", that are inserted by "Chain=20 >>> Classifier" or control plane to carry extra information (in additional= =20 >>> to Chain ID) for the purpose of controlling the sequence of functions=20 >>> on a chain. >>>=20 >>> Correct? >>>=20 >>> IMHO, the first bullet above are specific to applications or service=20 >>> functions internal processing. Many of today's proxy based service=20 >>> functions make changes to data packets, some of them make those=20 >>> changes for other service functions. Those changes won't be in the=20 >>> Service Chain Header field. >>>=20 >>> Linda >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee >>> Sent: Thursday, February 13, 2014 2:51 PM >>> To: Joel M. Halpern; Jerome Moisand; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>>=20 >>> I believe most of us agree that an out of bad signalling will not=20 >>> address the majority of requirement. Also a typical http flow carries=20 >>> many transactions and each can have different or additional=20 >>> classification. So a metadata can not be simple connected with one=20 >>> flow either. Current implementations of proxies and load balancers has= =20 >>> addressed this in many ways including custome header insertion. The=20 >>> custom header in this case equivalent of metadata vector. >>>=20 >>> I think we need an efficient way annotate actual data with inline=20 >>> metadata. I also strongly believe in solving the 80% of the use case >>>=20 >>> Regards >>> Sumandra >>> ________________________________________ >>> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=20 >>> [jmh@joelhalpern.com] >>> Sent: Thursday, February 13, 2014 11:51 AM >>> To: Jerome Moisand; sfc@ietf.org >>> Subject: Re: [sfc] Framework >>>=20 >>> I know very well what GTP does in terms of correlators, and why. >>> If all you need is an identifier for the subscriber, carrying a short=20 >>> identifier, and using it to select the desired behavior that has been=20 >>> pre-populated when the subscribers session starts works really well. >>> That is part of why I am not objecting to having provision for=20 >>> out-of-band metadata. >>>=20 >>> However, claiming that a single such correlator is all that is needed=20 >>> for even 80% of SFC cases (and I very much supporting trying to focus=20 >>> on the 80% cases), just does not seem to work, given the broad range=20 >>> of requirements that we have seen. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/13/14, 2:35 PM, Jerome Moisand wrote: >>>> Joel, >>>>=20 >>>> Protocols like GTP and L2TP work exactly that, with a form of=20 >>>> session correlator between the data plane and the control plane. This= =20 >>>> is very handy for subscriber and service management. Also if a=20 >>>> correlator is defined as an opaque and unique number, then one can=20 >>>> avoid some of the pitfalls you described. Long-lived metadata is=20 >>>> clearly useful (and thanks for sharing, Reinaldo, will read), and=20 >>>> there is clear applicability to various service chaining needs. >>>>=20 >>>> Now this is just one way. The I-D Bruno referred to was just listing=20 >>>> this approach as one possible way among others. I totally agree with=20 >>>> you that other forms of metadata (like an outcome of the=20 >>>> classification of a packet or a sequence of a few packets) may not be= =20 >>>> suitable for out-of-band signaling. >>>>=20 >>>> Bottomline seems to be that we have too many options to choose from,=20 >>>> and none of them solving it all... Tough. >>>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 13, 2014 2:29 PM >>>> To: sfc@ietf.org >>>> Subject: Re: [sfc] Framework >>>>=20 >>>> As I understand it, the tsvwg (and aeon) work is about flow metadata. >>>> That is long-lived metadata of use across many packets. That does=20 >>>> indeed seem well-suited to out-of-band cases. >>>>=20 >>>> My concern is that in SFC, there are many cases which are at best=20 >>>> badly-addressed if we insist that they be solved using out-of-band=20 >>>> metadata. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote: >>>>> There is draft about transport independent metadata. >>>>>=20 >>>>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encodi >>>>> ng >>>>> - >>>>> 01 >>>>>=20 >>>>> The complexities you mention are discussed there:=20 >>>>> variable-encoding, direction, security of metadata, etc. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> -RP >>>>>=20 >>>>>=20 >>>>>> On 2/13/14, 11:15 AM, "Joel M. Halpern" wrote: >>>>>>=20 >>>>>> While there are cases where out-of-band metadata makes sense,=20 >>>>>> There are many cases I would not want to try to cover that way. =20 >>>>>> The best examples are situations where the metadata changes from=20 >>>>>> packet to packet (such as the data produced by a DPI engine for=20 >>>>>> consumption by other applications in the chain.) >>>>>>=20 >>>>>> More importantly, if you are putting correlators in the packet, it = =20 >>>>>> is still very complex if you want to use one correlator to handle =20 >>>>>> metadata produced by several different entities (the initial =20 >>>>>> classifer, the DPI engine, ...) You quickly end up deciding that =20 >>>>>> you need several correlators. At which point we are back to=20 >>>>>> variable amounts of metadata. >>>>>>=20 >>>>>> The alternative is to require exceedingly specific and strong=20 >>>>>> coupling to a mandated out-of-band mechanism. That seems to me to=20 >>>>>> be a very bad idea. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote: >>>>>>> resend to avoid "too many recipients" warning >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman=20 >>>>>>> > wrote: >>>>>>>=20 >>>>>>> There are ways to signal variable length amounts of=20 >>>>>>> metadata without >>>>>>> needing an additional variable-length header on each data=20 >>>>>>> packet. >>>>>>>=20 >>>>>>> draft-rijsman-sfc-metadata-considerations-00 discusses=20 >>>>>>> some of the >>>>>>> possible approaches: out-of-band signaling (congruent or >>>>>>> non-congruent) or a hybrid approach using a fix-length=20 >>>>>>> in-band >>>>>>> correlator and out-of-band additional metadata. See=20 >>>>>>> sections 3.3, >>>>>>> 3.4 and 3.5 in the draft. >>>>>>>=20 >>>>>>> The issue of fixed-length encoding versus variable length=20 >>>>>>> encoding >>>>>>> is discussion in the challenges chapter in section 4.3. I=20 >>>>>>> should >>>>>>> probably mention the MTU and segmentation issues as well=20 >>>>>>> in that >>>>>>> section. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern >>>>>>> > wrote: >>>>>>>=20 >>>>>>> The variable length shim header is needed even if every >>>>>>> individual piece of metadata has a fixed length. >>>>>>> Different >>>>>>> service chains will need different combinations of=20 >>>>>>> metadata. So >>>>>>> the metadata portion of the header needs to be=20 >>>>>>> variable length. >>>>>>>=20 >>>>>>> I think the approach of a fixed length initial part,=20 >>>>>>> and a >>>>>>> variable length extension part, is the right model. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2/13/14, 11:13 AM, Jerome Moisand wrote: >>>>>>>=20 >>>>>>> Yes, fragmentation and variable headers are=20 >>>>>>> usually a really >>>>>>> bad thing for forwarding performance. Let's not=20 >>>>>>> forget that >>>>>>> we live in a 100G-ish kind of world nowadays. >>>>>>>=20 >>>>>>> Now the question should be: WHY would we want to=20 >>>>>>> do that >>>>>>> (variable headers leading to fragmentation issues)? >>>>>>>=20 >>>>>>> For example, the type of metadata that may require >>>>>>> variable-length fields might be a better candidate=20 >>>>>>> for some >>>>>>> out-of-band signaling mechanism. If this is service >>>>>>> authorization data (e.g. a service=20 >>>>>>> profile/policy), this >>>>>>> sounds likely. Not 100% sure this is true for all=20 >>>>>>> use cases >>>>>>> though. Only a good understanding of use cases,=20 >>>>>>> grounded by >>>>>>> reflecting on existing network architectures (notably >>>>>>> broadband, fixed or mobile), would tell us if one=20 >>>>>>> approach >>>>>>> or another is the most appropriate. >>>>>>>=20 >>>>>>> Anyhoo, we're jumping way deep in the detailed=20 >>>>>>> protocol >>>>>>> design here. This seems a tad premature. >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>>>>>> ] On Behalf Of Dave=20 >>>>>>> Dolson >>>>>>> Sent: Thursday, February 13, 2014 11:03 AM >>>>>>> To: 'jmh@joelhalpern.com=20 >>>>>>> '; >>>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>>> '; >>>>>>> 'mohamed.boucadair@orange.com >>>>>>> '__; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; >>>>>>> 'paulq@cisco.com >>>>>>> ' >>>>>>> Cc: 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com=20 >>>>>>> ' >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> it is overall more efficient to support PMTU=20 >>>>>>> discovery >>>>>>> rather than fragmenting every large packet. The is=20 >>>>>>> why TCP >>>>>>> adopted it so early on. >>>>>>>=20 >>>>>>> The fragmenting also puts huge performance burden=20 >>>>>>> on the >>>>>>> service functions. >>>>>>> Fragmenting may also affect the ability of load=20 >>>>>>> balancers to >>>>>>> get each fragment to the correct destination. >>>>>>>=20 >>>>>>> So PMTU discovery SHOULD be used, in my opinion.=20 >>>>>>> By this I >>>>>>> mean the client or server is informed that its=20 >>>>>>> packets are >>>>>>> too big (for IPv6 or IPv4 with DF=3D1). >>>>>>>=20 >>>>>>> Some operators may wish to incur the extra cost to=20 >>>>>>> hide the >>>>>>> existence of the tunneling, when the elements of=20 >>>>>>> the chain >>>>>>> can support it, so we could consider that as an=20 >>>>>>> optional >>>>>>> mechanism. >>>>>>>=20 >>>>>>> -Dave >>>>>>>=20 >>>>>>>=20 >>>>>>> ----- Original Message ----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >>>>>>> ] >>>>>>> Sent: Thursday, February 13, 2014 10:31 AM >>>>>>> To: Ron Parker >>>>>> >; >>>>>>> mohamed.boucadair@orange.com >>>>>>> >>>>>>> >>>>>> >__; Dave=20 >>>>>>> Dolson; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> ' >>>>>>> >>>>>> >; >>>>>>> 'paulq@cisco.com >>>>>>> ' >>>>>> > >>>>>>> Cc: 'S.Majee@F5.com' ; 'sfc@ietf.org >>>>>>> ' >>>>>> >; >>>>>>> 'linda.dunbar@huawei.com=20 >>>>>>> ' >>>>>>> >>>>>> > >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> I mostly agree with you Ron. I can probably come=20 >>>>>>> up with >>>>>>> some other variations, but your second point is=20 >>>>>>> that the >>>>>>> transport must deal with the issue of frame size /=20 >>>>>>> fit. >>>>>>>=20 >>>>>>> I would note that if we assume that the carrying=20 >>>>>>> encaps >>>>>>> (IPv4/v6 outer) is being fragmented, then we are=20 >>>>>>> assuming >>>>>>> that the exit from service chaining can and will=20 >>>>>>> reassemble. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 2/13/14, 10:18 AM, Ron Parker wrote: >>>>>>>=20 >>>>>>> Joel, >>>>>>>=20 >>>>>>> That is an excellent point to consider when=20 >>>>>>> choosing >>>>>>> transport >>>>>>> encapsulations. If the transport encapsulation >>>>>>> is IPv4 >>>>>>> or IPv6 >>>>>>> based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, =20 >>>>>>> etc.), then >>>>>>> fragmentation and defragmentation are naturally >>>>>>> supported. If the >>>>>>> transport encapsulation is VLAN, MPLS, etc.,=20 >>>>>>> then I >>>>>>> believe one of the >>>>>>> following must be true: >>>>>>>=20 >>>>>>> * The end-to-end path is known to support the=20 >>>>>>> resulting >>>>>>> larger frames >>>>>>> * A path discovery mechanism is mandated by=20 >>>>>>> SFC when >>>>>>> non-IP transports >>>>>>> are used * An SFC-specific fragmentation=20 >>>>>>> header and >>>>>>> mechanisms must be >>>>>>> defined (i.e., >>>>>>>=20 >>>>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-o >>>>>>> r- >>>>>>> f >>>>>>> rame) >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>> [mailto:jmh@joelhalpern.com >>>>>>> ] Sent: Thursday,=20 >>>>>>> February >>>>>>> 13, 2014 10:10 >>>>>>> AM To: mohamed.boucadair@orange.com >>>>>>> ; Dave=20 >>>>>>> Dolson; >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; Ron=20 >>>>>>> Parker; >>>>>>> 'paulq@cisco.com ' Cc: >>>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org=20 >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com >>>>>>> ' Subject: >>>>>>> Re: [sfc] Framework >>>>>>>=20 >>>>>>> There is a related complexity. I hope that we=20 >>>>>>> expect to >>>>>>> support IPv6. >>>>>>> IPv6 explicitly prohibits network elements from >>>>>>> fragmenting end user >>>>>>> packets. >>>>>>>=20 >>>>>>> Yours, Joel >>>>>>>=20 >>>>>>> On 2/13/14, 8:21 AM, mohamed.boucadair@orange.com >>>>>>> wrote: >>>>>>>=20 >>>>>>> Re-, >>>>>>>=20 >>>>>>> FWIW, one of the existing architecture drafts >>>>>>> includes the following >>>>>>> behavior >>>>>>>=20 >>>>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02# >>>>>>> se >>>>>>> c >>>>>>> tion- >>>>>>> 6 >>>>>>>=20 >>>>>>>=20 >>>>>>> >>>>>> on- >>>>>>> 6>): >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> " >>>>>>>=20 >>>>>>> 6. Fragmentation Considerations >>>>>>>=20 >>>>>>> If adding the Service Chaining Header=20 >>>>>>> would result >>>>>>> in a fragmented >>>>>>> packet, the classifier should include a=20 >>>>>>> Service >>>>>>> Chaining Header in >>>>>>> each fragment. Doing so would prevent SF=20 >>>>>>> Nodes to >>>>>>> dedicate resource >>>>>>> to handle fragments. " >>>>>>>=20 >>>>>>> Cheers, Med >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- De : sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> De la part de Dave Dolson Envoy=E9 : >>>>>>> jeudi 13 f=E9vrier 2014 13:39 =C0 : >>>>>>> 'Nicolas.BOUTHORS@qosmos.com >>>>>>> '; >>>>>>> 'Ron_Parker@affirmednetworks.__com >>>>>>>=20 >>>>>>> '; >>>>>>> 'jmh@joelhalpern.com =20 >>>>>>> '; >>>>>>> 'paulq@cisco.com=20 >>>>>>> ' Cc : >>>>>>> 'S.Majee@F5.com'; 'sfc@ietf.org >>>>>>> '; >>>>>>> 'linda.dunbar@huawei.com >>>>>>> '=20 >>>>>>> Objet >>>>>>> : Re: >>>>>>> [sfc] Framework >>>>>>>=20 >>>>>>> Good point to consider fragmentation. >>>>>>>=20 >>>>>>> We should design the encapsulation=20 >>>>>>> such that the >>>>>>> forwarding >>>>>>> functions do not need to reassemble. Each >>>>>>> fragment should be >>>>>>> independently forwardable; some SFs=20 >>>>>>> may choose >>>>>>> to ignore these >>>>>>> packets. >>>>>>>=20 >>>>>>> Any layer 2.5 protocol like VLAN or=20 >>>>>>> MPLS would >>>>>>> support this. >>>>>>> Otherwise, a reassembly layer could be=20 >>>>>>> added >>>>>>> after the forwarding >>>>>>> coordinates. Think of something like=20 >>>>>>> the >>>>>>> IPv6 >>>>>>> reassembly option >>>>>>> after a GRE header, for instance. >>>>>>>=20 >>>>>>> IP | GRE | reassem | frag data >>>>>>>=20 >>>>>>> We could alternatively mandate the=20 >>>>>>> inner IP be >>>>>>> fragmented and that >>>>>>> path-MTU discovery be supported. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ----- Original Message ----- From: >>>>>>> Nicolas BOUTHORS >>>>>>> [mailto:Nicolas.BOUTHORS@__qosmos.com >>>>>>> ] >>>>>>> Sent: >>>>>>> Thursday, February 13, >>>>>>> 2014 04:13 AM To: Ron Parker >>>>>>> >>>>>>=20 >>>>>>> >; >>>>>>> Dave Dolson; Joel M. Halpern >>>>>>> >>>>>> >; Paul Quinn >>>>>>> (paulq) >>>>>> > Cc: Sumandra=20 >>>>>>> Majee >>>>>>> ; >>>>>>> sfc@ietf.org =20 >>>>>>> >>>>>> >; Linda Dunbar >>>>>>> >>>>>> > >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> If we do not enforce a fix header size=20 >>>>>>> we have >>>>>>> other implication. >>>>>>>=20 >>>>>>> There is the question of segmentation and >>>>>>> reassembly responsibility >>>>>>> as well. >>>>>>>=20 >>>>>>> If adding length to the service header=20 >>>>>>> forces >>>>>>> segmentation, then >>>>>>> whose responsibility is it to=20 >>>>>>> reassemble the >>>>>>> payload before passing >>>>>>> it to the SF. >>>>>>>=20 >>>>>>> Similar question for packet re-ordering. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> __________________________________________ From: >>>>>>> Ron Parker >>>>>>> [Ron_Parker@affirmednetworks.__com >>>>>>>=20 >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, >>>>>>> 2014 11:25 PM To: Dave Dolson; Joel M. >>>>>>> Halpern; >>>>>>> Paul Quinn >>>>>>> (paulq) Cc: Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda Dunbar >>>>>>> Subject: >>>>>>> Re: [sfc] Framework >>>>>>>=20 >>>>>>> Dave, >>>>>>>=20 >>>>>>> Yes, that is a good point if we logically >>>>>>> separate the forwarding >>>>>>> function from the SFC-aware service=20 >>>>>>> function, as >>>>>>> we should. The >>>>>>> forwarding function is concerned with=20 >>>>>>> only the >>>>>>> inbound transport >>>>>>> header, the fixed portion of the=20 >>>>>>> service header >>>>>>> containing the >>>>>>> chain information, and the outbound=20 >>>>>>> transport >>>>>>> header. The >>>>>>> service function may look at the=20 >>>>>>> entirety of the >>>>>>> service header and >>>>>>> would look at the encapsulated packet. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: Dave=20 >>>>>>> Dolson >>>>>>> [mailto:ddolson@sandvine.com >>>>>>> ] Sent: >>>>>>> Wednesday, >>>>>>> February 12, 2014 >>>>>>> 5:18 PM To: Joel M. Halpern; Ron=20 >>>>>>> Parker; Paul >>>>>>> Quinn (paulq) Cc: >>>>>>> Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda Dunbar >>>>>>> Subject: RE: >>>>>>> [sfc] >>>>>>> Framework >>>>>>>=20 >>>>>>> The forwarding plane might not even=20 >>>>>>> need to look >>>>>>> at the encapsulated >>>>>>> packet. >>>>>>>=20 >>>>>>> For example, (if the SF Identifier is=20 >>>>>>> a VLAN >>>>>>> tag), an Ethernet >>>>>>> switch can forward packets of the form: >>>>>>> Ether | >>>>>>> VLAN | BLOB. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> On Behalf Of Joel M. Halpern Sent: >>>>>>> Wednesday, February 12, 2014 4:30 PM To: >>>>>>> Ron >>>>>>> Parker; Dave Dolson; >>>>>>> Paul Quinn (paulq) Cc: Sumandra Majee; >>>>>>> sfc@ietf.org ;=20 >>>>>>> Linda Dunbar >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> I agree as well. Yours, Joel >>>>>>>=20 >>>>>>> On 2/12/14, 4:24 PM, Ron Parker wrote: >>>>>>>=20 >>>>>>> Hi, Dave. >>>>>>>=20 >>>>>>> I Agree with your statement. And >>>>>>> if the >>>>>>> total length of the >>>>>>> header is >>>>>>>=20 >>>>>>> contained in the mandatory portion,=20 >>>>>>> the hardware >>>>>>> implementation can >>>>>>> easily locate the encapsulated packet. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Dave Dolson >>>>>>> [mailto:ddolson@sandvine.com >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, >>>>>>> 2014 4:10 PM To: Ron Parker; Paul=20 >>>>>>> Quinn >>>>>>> (paulq) Cc: Joel M. >>>>>>> Halpern; Sumandra Majee; sfc@ietf.org >>>>>>> ; Linda=20 >>>>>>> Dunbar >>>>>>> Subject: >>>>>>> RE: [sfc] Framework >>>>>>>=20 >>>>>>> I think a good approach would be: >>>>>>>=20 >>>>>>> The information required for=20 >>>>>>> forwarding (the >>>>>>> SF Identifier) should >>>>>>> be in >>>>>>>=20 >>>>>>> a mandatory fixed-size header. >>>>>>>=20 >>>>>>>=20 >>>>>>> Optional information (if any) is=20 >>>>>>> NOT to be >>>>>>> used for forwarding, but >>>>>>> is >>>>>>>=20 >>>>>>> for consumption by one or more of the >>>>>>> applications in the chain. >>>>>>>=20 >>>>>>>=20 >>>>>>> Then the forwarding plane, and=20 >>>>>>> even the PDP, >>>>>>> can be agnostic about >>>>>>> the >>>>>>>=20 >>>>>>> meta-data. >>>>>>>=20 >>>>>>>=20 >>>>>>> -Dave >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>> ] >>>>>>> On Behalf Of Ron Parker Sent: >>>>>>> Wednesday, February 12, 2014 4:05=20 >>>>>>> PM >>>>>>> To: >>>>>>> Paul Quinn (paulq) Cc: >>>>>>> Joel M. Halpern; Sumandra Majee; >>>>>>> sfc@ietf.org=20 >>>>>>> ; Linda Dunbar >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> Paul, >>>>>>>=20 >>>>>>> That is why I am proposing a=20 >>>>>>> hybrid where >>>>>>> extensions or options can >>>>>>> be >>>>>>>=20 >>>>>>> added but the total length is=20 >>>>>>> contained in the >>>>>>> fixed portion. I >>>>>>> can envision certain deployments (e.g., >>>>>>> Enterprise) where perhaps >>>>>>> extensions are not needed and the SFC >>>>>>> functionality is realized >>>>>>> in hardware. And, I can envision >>>>>>> certain other >>>>>>> deployments >>>>>>> (e.g., 3gpp) where the extension=20 >>>>>>> headers add >>>>>>> sufficient value to >>>>>>> justify software based implementations. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Paul Quinn >>>>>>> (paulq) >>>>>>> [mailto:paulq@cisco.com >>>>>>> ] Sent: >>>>>>> Wednesday, >>>>>>> February 12, 2014 >>>>>>> 3:40 PM To: Ron Parker Cc:=20 >>>>>>> Sumandra Majee; >>>>>>> Linda Dunbar; Joel M. >>>>>>> Halpern; sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> We certainly need to be very=20 >>>>>>> careful with >>>>>>> variable length headers >>>>>>> when >>>>>>>=20 >>>>>>> hardware platform are in play. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron, your examples of IP options=20 >>>>>>> and >>>>>>> v6 EH >>>>>>> have both suffered from >>>>>>>=20 >>>>>>> significant implementation and deployment >>>>>>> hurdles due to the >>>>>>> complexity and cost associated with=20 >>>>>>> hardware >>>>>>> support for the >>>>>>> option/EH. >>>>>>>=20 >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>> On Feb 12, 2014, at 3:10 PM, Ron=20 >>>>>>> Parker >>>>>>> >>>>>>=20 >>>>>>> > >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi, Sumandra. >>>>>>>=20 >>>>>>> Regarding service header=20 >>>>>>> flexibility, I >>>>>>> completely agree. I >>>>>>> might >>>>>>>=20 >>>>>>> suggest a compromise between hardware >>>>>>> friendliness and software >>>>>>> flexibility. If the header had the >>>>>>> ability to >>>>>>> add extensions >>>>>>> (perhaps similar to IPv6) but also had=20 >>>>>>> the >>>>>>> header length encoded in >>>>>>> the mandatory part (like IPv4), then a=20 >>>>>>> hardware >>>>>>> implementation would >>>>>>> be free to skip over the extensions=20 >>>>>>> (in cases >>>>>>> where the deployment >>>>>>> justifies ignoring the extensions). >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: >>>>>>> Sumandra Majee >>>>>>> [mailto:S.Majee@F5.com >>>>>>> ] Sent: >>>>>>> Wednesday, February 12, 2014 >>>>>>> 3:04 PM To: Ron Parker; Linda=20 >>>>>>> Dunbar; >>>>>>> Joel M. Halpern; >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: Re: [sfc] Framework >>>>>>>=20 >>>>>>> For all of those=20 >>>>>>> reasons, I >>>>>>> strongly support a =20 >>>>>>> canonical service >>>>>>> header that is=20 >>>>>>> independent of >>>>>>> the transport=20 >>>>>>> methodology. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I agree. However the format of=20 >>>>>>> service >>>>>>> header should be >>>>>>> standardized in >>>>>>>=20 >>>>>>> a way that is flexible. Some of us=20 >>>>>>> would like to >>>>>>> see variable length >>>>>>> header that is also HW friendly. The=20 >>>>>>> service >>>>>>> header can be >>>>>>> represented as a mandotory fixed=20 >>>>>>> length header >>>>>>> (like IP >>>>>>> header) along with an optional=20 >>>>>>> variable length >>>>>>> attribute field. >>>>>>> Different services can be interested in >>>>>>> different metadata, for >>>>>>> example subscriber ID could be of=20 >>>>>>> interest in >>>>>>> the mobile core >>>>>>> service chain only. >>>>>>>=20 >>>>>>>=20 >>>>>>> Sumandra >>>>>>>=20 >>>>>>> On 2/12/14, 11:32 AM, "Ron=20 >>>>>>> Parker" >>>>>>>=20 >>>>>>> >>>>>>=20 >>>>>>> > >>>>>>>=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> Linda, >>>>>>>=20 >>>>>>> My interpretation of the >>>>>>> architecture docs is that=20 >>>>>>> the service >>>>>>> function chain is built in an >>>>>>> abstract manner (i.e.,=20 >>>>>>> SF-A then >>>>>>> SF-B >>>>>>>=20 >>>>>>> then SF-C). >>>>>>>=20 >>>>>>> Separately, a locator=20 >>>>>>> table provides >>>>>>> network location for >>>>>>> each of those service=20 >>>>>>> functions. >>>>>>> In this way, you can >>>>>>> locate the service=20 >>>>>>> functions >>>>>>>=20 >>>>>>> in >>>>>>>=20 >>>>>>> a manner appropriate to=20 >>>>>>> the type of >>>>>>> transport you are >>>>>>> using. If you want that to= =20 >>>>>>> be >>>>>>> interface+VLAN, >>>>>>> gateway-IP+MPLS label=20 >>>>>>> stack, IP >>>>>>>=20 >>>>>>> address, >>>>>>>=20 >>>>>>> GRE tunnel remote IP +=20 >>>>>>> key, etc., >>>>>>> you can do that. You >>>>>>> can even potentially locate >>>>>>> different service=20 >>>>>>> functions that >>>>>>> reside in the same chain with >>>>>>> different flavors of >>>>>>> network locators. Another >>>>>>> justification to separate the >>>>>>> identity of a service=20 >>>>>>> function from >>>>>>> its network location is >>>>>>> load balancing. If, for=20 >>>>>>> example, >>>>>>> SF-A had 3 IP addresses, >>>>>>> that would imply load=20 >>>>>>> balancing to 3 >>>>>>> instances using IP as a >>>>>>> transport layer. >>>>>>>=20 >>>>>>> For all of those reasons,=20 >>>>>>> I strongly >>>>>>> support a canonical service >>>>>>> header that is independent=20 >>>>>>> of the >>>>>>> transport >>>>>>> methodology. At a=20 >>>>>>> particular >>>>>>> node, the decision as to >>>>>>> where to go next should be=20 >>>>>>> based >>>>>>> solely on information=20 >>>>>>> carried in >>>>>>> the canonical service=20 >>>>>>> header and not >>>>>>> on the >>>>>>>=20 >>>>>>> fields >>>>>>>=20 >>>>>>> in the transport header. =20 >>>>>>> That is, >>>>>>> the SFC node discards >>>>>>> the transport header and=20 >>>>>>> extracts >>>>>>> the chain ID from the >>>>>>> service header. Through >>>>>>> mechanisms we have not yet=20 >>>>>>> begun >>>>>>> to discuss, the SFC node=20 >>>>>>> knows how >>>>>>> to interpret the chain ID and >>>>>>> ultimately how to progress =20 >>>>>>> the packet. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc >>>>>>>=20 >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>>=20 >>>>>>> ] On >>>>>>> Behalf Of Linda Dunbar >>>>>>> Sent: Wednesday, February=20 >>>>>>> 12, 2014 >>>>>>> 12:01 PM To: Joel M. >>>>>>> Halpern; sfc@ietf.org >>>>>>> >>>>>>> Subject: Re: >>>>>>> [sfc] Framework >>>>>>>=20 >>>>>>> Agree with Joel's statement. >>>>>>>=20 >>>>>>> I think a simple sentence=20 >>>>>>> below >>>>>>> should be added Section=20 >>>>>>> 5.2 (SFC >>>>>>> Classifier) to emphasize=20 >>>>>>> this point. >>>>>>>=20 >>>>>>> "A Service Chain=20 >>>>>>> Classifier node can >>>>>>> associate a unique Layer 2 >>>>>>> or 3 Label (e.g. VLAN,=20 >>>>>>> MPLS >>>>>>> label) >>>>>>> to the packets in the flow. >>>>>>> Those Layer 2 or 3 Label=20 >>>>>>> makes it >>>>>>> easier for subsequent nodes >>>>>>> along the flow path to=20 >>>>>>> steer the >>>>>>> flow to the service functions >>>>>>> specified by the flow's =20 >>>>>>> service chain." >>>>>>>=20 >>>>>>>=20 >>>>>>> Linda -----Original >>>>>>> Message----- >>>>>>> From: sfc >>>>>>>=20 >>>>>>> [mailto:sfc-bounces@ietf.org >>>>>>>=20 >>>>>>> ] On >>>>>>> Behalf Of Joel M. Halpern >>>>>>> Sent: Wednesday, February=20 >>>>>>> 12, 2014 >>>>>>> 10:20 AM To: >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>> Subject: [sfc] Framework >>>>>>>=20 >>>>>>> I was looking at the=20 >>>>>>> framework >>>>>>> proposal. The proposal has=20 >>>>>>> a very >>>>>>> specific model of the=20 >>>>>>> scope of the >>>>>>> transport header (that it is >>>>>>> derived from, and relates=20 >>>>>>> only to, >>>>>>> the first service function to >>>>>>> which the packet will be=20 >>>>>>> directed. >>>>>>> That is clearly an=20 >>>>>>> operational >>>>>>> model we need to support. >>>>>>>=20 >>>>>>> However, I would like to=20 >>>>>>> allow other >>>>>>> transport operational >>>>>>> models, such as the use of=20 >>>>>>> a VLAN to >>>>>>> direct traffic along a >>>>>>> chain. Or the use of an=20 >>>>>>> MPLS label, >>>>>>> or an MPLS label stack. >>>>>>>=20 >>>>>>> Yours, Joel M. Halpern >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org=20 >>>>>>> >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ sfc >>>>>>> mailing list >>>>>>> sfc@ietf.org >>>>>>>=20 >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _________________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/__listinfo/sfc >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>>=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 >>>=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 >=20 From nobody Tue Feb 18 10:16:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793FB1A00EC for ; Tue, 18 Feb 2014 10:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1di5oyNBMchq for ; Tue, 18 Feb 2014 10:16:02 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 822361A002C for ; Tue, 18 Feb 2014 10:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26197; q=dns/txt; s=iport; t=1392747360; x=1393956960; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LxRcukC82k0KA1HmwA/tPbfu+xBBwPw1/sV8tADcpFY=; b=AY1OgoBep1boL2OxzlRe8WHwoZxdexqty738zq3syUBbs0q3Mxwh5vk8 Hn9A8l9k0e7WsZJuOOcgQAKgUcLWVZteDxRDJq47TP5s4S/KSGLpm29Yx TPvg0JDpVm+G9o2C1MWvRc32ULuTmWZT0uRF/mhPWlPJPqJC40V6Ggex5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAKeiA1OtJV2a/2dsb2JhbABZgwY4V79UgRwWdIIlAQEBBAEBARcNQAcEEwQCAQgOAwECAQEBFwIPByEGCxQDBggCBAESCYdoAxENxA8NiA8XjGeBNw9WBQYMBgeEGQSWQIFsgTKLLAOFQoMtgXE5 X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="304890372" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2014 18:15:58 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IIFwQS027328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 18:15:58 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.131]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 12:15:57 -0600 From: "Jeffrey Napper (jenapper)" To: Jerome Moisand , Alla Goldner , Linda Dunbar , "Haeffner, Walter, Vodafone DE" , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" , "diego@tid.es" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPLNV4S611HaURDU+MXSHKth/YAA== Date: Tue, 18 Feb 2014 18:15:57 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.75.174] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UEWOZvK7WI9p63LNqn283wQvMVc Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:16:07 -0000 Hi guys, Yes, we have submitted a revision that includes discussion of the TDF. https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ The changes from the previous draft include a short comparison of fixed networks that are similar to 3GPP, introduction of the TDF, additional co-authors Martin and Diego, and some other tidying up. I hope that the new text addresses your concerns. Please let us know if there are still problems with the text. I think Walter will present some slides over the draft in London. Cheers, Jeff -----Original Message----- From: Jerome Moisand Date: Friday, February 14, 2014 at 4:28 PM To: Alla Goldner , Linda Dunbar , Jeffrey Napper , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Linda, > >A PGW is a PCEF for sure (hence is more than a classifier). So this part >of your proposed drawing would have to be improved. > >Now in the TDF case, a better drawing would show PGW(PCEF) and TDF(PCEF) >in sequence. As this is the reality of things, a TDF does not replace a >PGW, it (optionally) complements it. > >Anyhoo, I feel we're going a bit in circles here. Why not letting the >authors of this draft (who obviously know the 3GPP constructs very well) >improve it as they see fit based on the feedback? > >Tx >Jerome > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Friday, February 14, 2014 1:43 AM >To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner, >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Linda, all, > >I think this presentation is more correct, thank you. > >One thing though may need to be corrected: PCEF is an integral part of >PGW as defined by 3GPP standards. Therefore, we may, as an option, >mention "PCEF/TDF" without "PGW", and then put a note that PCEF resides >in PGW. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Friday, February 14, 2014 1:17 AM >To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner, >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla, Jerome,=20 > >Since 3GPP has defined many components and are still involving, can we >use a simplified box to represent an entity associated with P-GW that >classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as: > > > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF/| | |Network| > |rules| < ---- > |Ctrller| > +-----+ | +----+--+ > | | > V | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| & or | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > |TDF/PCEF | | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > > >As for the description of metadata used by Gi-LAN service function, we >don't have to specifically say which elements defined by 3GPP encoded >them in.=20 > > >Linda >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 10:30 AM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >I don't know if the whole PCC architecture is truly optional in 3GPP >theory (I've never seen it expressed that way, but I'll take your word >for it), but one would be hard-pressed to find a 3G/LTE mobile broadband >network without it. So in practice my 100% statement remains true (I'll >give you 99.9% if you wish!). > >So I have a bit of an issue putting PGW and TDF at the same level. This >simply doesn't reflect any reality, nor the spirit of the 3GPP specs. > >And in the fixed-broadband world in BBF terms, yeah, the BNG IS mandatory >(I took a very active role in several of those specs, e.g. TR-101). While >a DPI function is truly optional (and not that many subscribers in >absolute % go through it in practice) and not standardized. > >Anyway, I agree with you that mobile use cases with or without TDF should >be considered. A case without PGW would seem much more dubious to me. We >may be saying more or the same thing, overall. > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Thursday, February 13, 2014 11:15 AM >To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Jerome, > >Yes, TDF is an optional element in mobile networks. As a such, Sd >interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface is >optional in exactly the same way. The whole 3GPP PCC architecture is >optional. Therefore, the claim about 100% of mobile data subscribers may >not be fully correct. And with regards to the features required for >service classification and service enforcement that you describe below - >they are present at both GGSN/PGW and TDF. > >The bottom line is that use cases where PGW is considered as classifier >OF COURSE should be considered, same as use cases where TDF is considered >as a classifier. And, once describing those use cases, the existing 3GPP >architecture should be assumed. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 5:27 PM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla & folks, > >Well... I don't know... Getting deep in network architectures and the >role of the various network elements is indeed crucial. Both 3GPP and BBF >(Broadband Forum) did a lot of work in the past decade to define >architecture & nodal requirements, which shaped in turn the deployment of >all major Service Providers worldwide. So quite clearly, service chaining >have to build on that and find a good way to insert itself into such >architectures while extending them. > >Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate for >service classification/enforcement, as it... already does it for its own >purpose! This is BY NATURE a highly scalable subscriber & service >management system, classifying and enforcing policies (usually L3, >occasionally higher), and fully integrated with the HSS/PCRF chain which >holds the subscriber/service authentication & authorization data. As >such, service classification *and* service enforcement (and service >accounting) is already there. For 100% of the mobile (data) subscribers. >Sure enough, a TDF system may also do its own form of service >classification (and processing too), but let's not forget this is an >OPTIONAL system on the data path on the recently defined 3GPP >architectures you referred to. For many use cases, there is just no point >going through a DPI function. While for other use cases, there is clearly >such a point, but only when it brings clear value for a given service >construct, only applicable to corresponding subscribers. > >In the same vein, in fixed-broadband architectures, a BNG is the primary >subscriber management system on the data path, fully integrated with a >AAA system, and already doing service classification *and* service >processing at scale for 100% of the subscribers. Any >classification/enforcement system behind it is optional and only >applicable to a subset of services & subscribers. > >Bottomline: sure, use cases with TDF should be described, but PGW-centric >use cases remain the rule, not the exception. And double-clicking on >existing standardized network architectures (e.g. 3GPP and BBF) and >related deployments is crucial for our SFC endeavor. > >Jerome Moisand. > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner >Sent: Thursday, February 13, 2014 1:18 AM >To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone >DE; Dave Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Deal Linda,=20 > >The 3GPP architecture picture described below is not accurate. >Starting from R11, PCRF interacts also with TDF (Traffic Detection >Function) for providing ADC (Application Detection and Control) Rules for >application detection, enforcement and also charging starting from R12. >Please see architecture diagram for your reference in the 3GPP TS 23.203. > >Therefore, we can't assume that "Since PCRF usually only interfaces with >the GGSN (via Diameter), not the service functions, do you mean "for the >GGSN (or the flow classifier) to carry the data passed down from PCRF to >packets' metadata field to service functions on the chain"?" > >Furthermore, also the claim that >"The P-GW/PCEF (per 3GPP terminology) determines the desired service >treatment, i.e. desired sequence of service functions, to specific flows >based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based on >the policies from PCRF. The traffic in each category (or flow) is mapped >to a unique interface (a physical or virtual port) or a tunnel that is >connected to the needed sequence of service functions." is not correct as >well as PGW/PCEF is not the only element which enforces different support >per different flows based on policies received from PCRF, but also TDF! > >My general feeling is that we are getting here deeply into 3GPP >architecture and make assumptions and conclusions about potential 3GPP >elements functionality which are not in scope of IETF. If we want to >define use cases for 3GPP networks, then we should show correct picture >of 3GPP architecture without redesigning it and leave 3GPP Network >Elements functionality potential extensions to 3GPP. > >Best regards, > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Thursday, February 13, 2014 12:13 AM >To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave >Dolson; Martin Stiemerling; >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Jeffrey and Walter, > >Here are some suggestions to your draft: > >Section 2.2:=20 >- your draft states "The Gi-LAN service functions may use subscriber and >service related metadata delivered from mobile control plane function >like PCRF to process the flows according to service related policies" > >Since PCRF usually only interfaces with the GGSN (via Diameter), not the >service functions, do you mean "for the GGSN (or the flow classifier) to >carry the data passed down from PCRF to packets' metadata field to >service functions on the chain"? >Since the policies passed down by PCRF usually can't be understood by >service functions, I suggest changing to the following text: > >"The (S)Gi-LAN service functions may use subscriber and service related >information, that are either embedded in packets as metadata or passed >down from control plane, to process the flows according to service >related policies" > > >Section 2.3 The most common classification scheme > >I think this section is very confusing. How is "APN for P-GW IP address" >used in traffic classification? > >Are you saying that traffic are grouped to specific P-GW? And each APN >has a VLAN-ID?=20 > >I understand that some common classification scheme could be encoding a >certain QoS to a specific flow, applying some security functions to some >flows, etc. The classification node can use simple VLAN-ID to mark >different classification. > >P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? > >I think the Wireless Service Chain example given by Walter at Berlin SFC >BOF is very good.=20 > >Walter's wireless example is described in the Section 3.2 of >https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-archi >tecture/ > >Maybe you can use the text to replace your Section 2.3? Here is the >suggested text: >----------------- >The P-GW/PCEF (per 3GPP terminology) determines the desired service >treatment, i.e. desired sequence of service functions, to specific flows >based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based on >the policies from PCRF. The traffic in each category (or flow) is mapped >to a unique interface (a physical or virtual port) or a tunnel that is >connected to the needed sequence of service functions. >=20 > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF | | |Network| > | | < ---- > |Ctrller| > +-----+ | +----+--+ > | | > | | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > | [PCEF]| | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > >Linda > >-----Original Message----- >From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] >Sent: Sunday, February 09, 2014 1:44 PM >To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Linda, > >First, thanks for the feedback. While it may look like a lot of >components, we still have simplified 3GPP quite a lot. For example, in >the first draft we left out the TDF that appears in recent standards. >We=B9ll be adding that in response to other comments. I believe the >overview section is still quite short, but we will try to shorten it a >bit further if it is too long. If you feel anything in particular is >missing or extraneous, please let us know. > >Yes, it is probably overkill to have two example APNs. The User & Pass >are important for example in cases of hot-lining where the user must >first be authenticated (for various reasons) before data services are >provided/continued. It is just another example of the important >relationship between Classification (in an SFC sense) and Policy and >Charging (in a 3GPP sense). > >Cheers, >Jeff > >-----Original Message----- >From: Linda Dunbar >Date: Friday, February 7, 2014 at 11:14 PM >To: "Haeffner, Walter, Vodafone DE" , Dave >Dolson , Martin Stiemerling , >"draft-haeffner-sfc-use-case-mobility@tools.ietf.org" >, "sfc@ietf.org" > >Cc: Jeffrey Napper >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >>Walter, et al, >> >>While it is interesting to show all the components of 3GPP for GiLAN, >>but I don't think it is necessary to have all of them in the SFC use >>case draft. >> >>For example, on your Section 2.3 ("The Most common classification >>scheme"), it is very confusing to have the Table 1 & Table 2 listing >>"User name & Password". Does it mean that the "User Name & Password" >>have to associated with data packets? Or to be detected by the >>Classification nodes? >> >>Linda >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter, >>Vodafone DE >>Sent: Wednesday, February 05, 2014 7:21 PM >>To: Dave Dolson; Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >>Subject: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi Dave, >>Thanks for your comment. We are going to include a Rel.11 TDF paragraph >>in -01. Possibly we will consider 2 sections: most simple case (with >>APN), actual most advanced case (with TDF). >>Regards, >>Walter >> >>-----Urspr=FCngliche Nachricht----- >>Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >>Gesendet: Dienstag, 4. Februar 2014 20:23 >>An: Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Betreff: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Although draft-haeffner-sfc-use-case-mobility-00 describes one >>arrangement of mobility architecture, it neglects to show the role of >>the Traffic Detection Function (TDF), also described in the cited 3GPP >>TS >>23.203 (Version 12). >> >>I don't want to argue with the use cases, just the implied network >>architecture. >> >>In all of the network diagrams and examples, it should be understood >>that the P-GW is not the only location from which a policy-based >>service chain could be initiated; the standard TDF function can also >>initiate service chains selected by policy and traffic type. >> >>Section 2.1 should show an optional TDF element between the P-GW and >>the (S)Gi-LAN. >> >>A TDF communicates with a PCRF using the Sd interface, from which it >>receives Application Detection and Control (ADC) rules, similar to the >>rules deployed to the P-GW via the Gx interface. >> >>Aside from the APN classification scheme mentioned in section 2.3 of >>the draft, ADC rules can cause decisions based on application type (not >>just based on APN or UDP/TCP port classification). >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin Stiemerling >>Sent: Wednesday, January 29, 2014 9:46 AM >>To: sfc@ietf.org >>Subject: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi all, >> >>I wanted to raise your attention to the below quoted draft, as it >>wasn't posted to the SFC list. >> >>The draft outlines very well the use cases in mobile networks. >> >>Thanks, >> >> Martin >> >> >>-------- Original Message -------- >>Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >>Date: Tue, 28 Jan 2014 14:26:15 -0800 >>From: internet-drafts@ietf.org >>Reply-To: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Service Function Chaining Use Cases in Mobile >>Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >> Pages : 17 >> Date : 2014-01-28 >> >>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 and framework statements >> 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 ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery, take care of security and privacy or >> support application and business support platforms. 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 IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >>_______________________________________________ >>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 >########################################################################## >#################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by >a reply e-mail and delete this message. >Thank you. >########################################################################## >#################### > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > > > >########################################################################## >#################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by >a reply e-mail and delete this message. >Thank you. >########################################################################## >#################### > > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >########################################################################## >#################### >This message is intended only for the designated recipient(s).It may >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or >distribute this message. >If you have mistakenly received this message, please notify the sender by >a reply e-mail and delete this message. >Thank you. >########################################################################## >#################### > > > From nobody Tue Feb 18 10:23:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0421A067C for ; Tue, 18 Feb 2014 10:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 Y9Pgy7_sliZ8 for ; Tue, 18 Feb 2014 10:23:30 -0800 (PST) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 499691A06F0 for ; Tue, 18 Feb 2014 10:23:28 -0800 (PST) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Tue, 18 Feb 2014 20:23:24 +0200 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 20:22:39 +0200 From: Alla Goldner To: "Jeffrey Napper (jenapper)" , Jerome Moisand , Linda Dunbar , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin Stiemerling , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" , "diego@tid.es" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPLNViJlWiPGFg5UyYRkqbDxGeB5q7Uobw Date: Tue, 18 Feb 2014 18:22:38 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.57.164.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ruq9PDuv1s2aORVTV8zxF0L8i8w Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:23:36 -0000 Hi, Thanks a lot for this update! There are two things which needs to be corrected: 1. The related 3GPP specification should be TS 23.203 and not TS 29.212 (= 29.212 is protocol level description only while TS 23.203 defines general= =20PCC architecture). 2. The sentence "The Traffic Detection Function (TDF) [TS.29.212] is curr= ently under standardization within 3GPP." is not correct, as TDF was stan= dardized back in R11 of 3GPP and this is an existing entity for the last = couple of years thus should be described as a such. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com=20 www.allot.com -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com]=20 Sent: Tuesday, February 18, 2014 8:16 PM To: Jerome Moisand; Alla Goldner; Linda Dunbar; Haeffner, Walter, Vodafon= e DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobili= ty@tools.ietf.org; sfc@ietf.org; diego@tid.es Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-= 00.txt Hi guys, Yes, we have submitted a revision that includes discussion of the TDF. https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ The changes from the previous draft include a short comparison of fixed n= etworks that are similar to 3GPP, introduction of the TDF, additional co-= authors Martin and Diego, and some other tidying up. I hope that the new text addresses your concerns. Please let us know if t= here are still problems with the text. I think Walter will present some s= lides over the draft in London. Cheers, Jeff -----Original Message----- From: Jerome Moisand Date: Friday, February 14, 2014 at 4:28 PM To: Alla Goldner , Linda Dunbar , Jeffrey Napper , "Haeffner, Walter, Vodafone DE= " , Dave Dolson , Mar= tin Stiemerling , "draft-haeffner-sfc-use-case-mobili= ty@tools.ietf.org" , "sfc@ietf.org" Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Linda, > >A PGW is a PCEF for sure (hence is more than a classifier). So this=20 >part of your proposed drawing would have to be improved. > >Now in the TDF case, a better drawing would show PGW(PCEF) and=20 >TDF(PCEF) in sequence. As this is the reality of things, a TDF does not = >replace a PGW, it (optionally) complements it. > >Anyhoo, I feel we're going a bit in circles here. Why not letting the=20 >authors of this draft (who obviously know the 3GPP constructs very=20 >well) improve it as they see fit based on the feedback? > >Tx >Jerome > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Friday, February 14, 2014 1:43 AM >To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Linda, all, > >I think this presentation is more correct, thank you. > >One thing though may need to be corrected: PCEF is an integral part of=20 >PGW as defined by 3GPP standards. Therefore, we may, as an option,=20 >mention "PCEF/TDF" without "PGW", and then put a note that PCEF resides = >in PGW. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Friday, February 14, 2014 1:17 AM >To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla, Jerome, > >Since 3GPP has defined many components and are still involving, can we=20 >use a simplified box to represent an entity associated with P-GW that=20 >classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as: > > > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF/| | |Network| > |rules| < ---- > |Ctrller| > +-----+ | +----+--+ > | | > V | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| & or | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > |TDF/PCEF | | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > > >As for the description of metadata used by Gi-LAN service function, we=20 >don't have to specifically say which elements defined by 3GPP encoded=20 >them in. > > >Linda >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 10:30 AM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >I don't know if the whole PCC architecture is truly optional in 3GPP=20 >theory (I've never seen it expressed that way, but I'll take your word=20 >for it), but one would be hard-pressed to find a 3G/LTE mobile=20 >broadband network without it. So in practice my 100% statement remains=20 >true (I'll give you 99.9% if you wish!). > >So I have a bit of an issue putting PGW and TDF at the same level. This = >simply doesn't reflect any reality, nor the spirit of the 3GPP specs. > >And in the fixed-broadband world in BBF terms, yeah, the BNG IS=20 >mandatory (I took a very active role in several of those specs, e.g.=20 >TR-101). While a DPI function is truly optional (and not that many=20 >subscribers in absolute % go through it in practice) and not standardize= d. > >Anyway, I agree with you that mobile use cases with or without TDF=20 >should be considered. A case without PGW would seem much more dubious=20 >to me. We may be saying more or the same thing, overall. > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Thursday, February 13, 2014 11:15 AM >To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Jerome, > >Yes, TDF is an optional element in mobile networks. As a such, Sd=20 >interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface=20 >is optional in exactly the same way. The whole 3GPP PCC architecture is = >optional. Therefore, the claim about 100% of mobile data subscribers=20 >may not be fully correct. And with regards to the features required for = >service classification and service enforcement that you describe below = >- they are present at both GGSN/PGW and TDF. > >The bottom line is that use cases where PGW is considered as classifier = >OF COURSE should be considered, same as use cases where TDF is=20 >considered as a classifier. And, once describing those use cases, the=20 >existing 3GPP architecture should be assumed. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 5:27 PM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla & folks, > >Well... I don't know... Getting deep in network architectures and the=20 >role of the various network elements is indeed crucial. Both 3GPP and=20 >BBF (Broadband Forum) did a lot of work in the past decade to define=20 >architecture & nodal requirements, which shaped in turn the deployment=20 >of all major Service Providers worldwide. So quite clearly, service=20 >chaining have to build on that and find a good way to insert itself=20 >into such architectures while extending them. > >Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate=20 >for service classification/enforcement, as it... already does it for=20 >its own purpose! This is BY NATURE a highly scalable subscriber &=20 >service management system, classifying and enforcing policies (usually=20 >L3, occasionally higher), and fully integrated with the HSS/PCRF chain=20 >which holds the subscriber/service authentication & authorization data. = >As such, service classification *and* service enforcement (and service >accounting) is already there. For 100% of the mobile (data) subscribers.= >Sure enough, a TDF system may also do its own form of service=20 >classification (and processing too), but let's not forget this is an=20 >OPTIONAL system on the data path on the recently defined 3GPP=20 >architectures you referred to. For many use cases, there is just no=20 >point going through a DPI function. While for other use cases, there is = >clearly such a point, but only when it brings clear value for a given=20 >service construct, only applicable to corresponding subscribers. > >In the same vein, in fixed-broadband architectures, a BNG is the=20 >primary subscriber management system on the data path, fully integrated = >with a AAA system, and already doing service classification *and*=20 >service processing at scale for 100% of the subscribers. Any=20 >classification/enforcement system behind it is optional and only=20 >applicable to a subset of services & subscribers. > >Bottomline: sure, use cases with TDF should be described, but=20 >PGW-centric use cases remain the rule, not the exception. And=20 >double-clicking on existing standardized network architectures (e.g.=20 >3GPP and BBF) and related deployments is crucial for our SFC endeavor. > >Jerome Moisand. > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner >Sent: Thursday, February 13, 2014 1:18 AM >To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone = >DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Deal Linda, > >The 3GPP architecture picture described below is not accurate. >Starting from R11, PCRF interacts also with TDF (Traffic Detection >Function) for providing ADC (Application Detection and Control) Rules=20 >for application detection, enforcement and also charging starting from R= 12. >Please see architecture diagram for your reference in the 3GPP TS 23.203= . > >Therefore, we can't assume that "Since PCRF usually only interfaces=20 >with the GGSN (via Diameter), not the service functions, do you mean=20 >"for the GGSN (or the flow classifier) to carry the data passed down=20 >from PCRF to packets' metadata field to service functions on the chain"?= " > >Furthermore, also the claim that >"The P-GW/PCEF (per 3GPP terminology) determines the desired service=20 >treatment, i.e. desired sequence of service functions, to specific=20 >flows based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based=20 >on the policies from PCRF. The traffic in each category (or flow) is=20 >mapped to a unique interface (a physical or virtual port) or a tunnel=20 >that is connected to the needed sequence of service functions." is not=20 >correct as well as PGW/PCEF is not the only element which enforces=20 >different support per different flows based on policies received from PC= RF, but also TDF! > >My general feeling is that we are getting here deeply into 3GPP=20 >architecture and make assumptions and conclusions about potential 3GPP=20 >elements functionality which are not in scope of IETF. If we want to=20 >define use cases for 3GPP networks, then we should show correct=20 >picture of 3GPP architecture without redesigning it and leave 3GPP=20 >Network Elements functionality potential extensions to 3GPP. > >Best regards, > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Thursday, February 13, 2014 12:13 AM >To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave=20 >Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Jeffrey and Walter, > >Here are some suggestions to your draft: > >Section 2.2:=20 >- your draft states "The Gi-LAN service functions may use subscriber=20 >and service related metadata delivered from mobile control plane=20 >function like PCRF to process the flows according to service related pol= icies" > >Since PCRF usually only interfaces with the GGSN (via Diameter), not=20 >the service functions, do you mean "for the GGSN (or the flow=20 >classifier) to carry the data passed down from PCRF to packets'=20 >metadata field to service functions on the chain"? >Since the policies passed down by PCRF usually can't be understood by=20 >service functions, I suggest changing to the following text: > >"The (S)Gi-LAN service functions may use subscriber and service related = >information, that are either embedded in packets as metadata or passed=20 >down from control plane, to process the flows according to service=20 >related policies" > > >Section 2.3 The most common classification scheme > >I think this section is very confusing. How is "APN for P-GW IP address"= >used in traffic classification? > >Are you saying that traffic are grouped to specific P-GW? And each APN=20 >has a VLAN-ID? > >I understand that some common classification scheme could be encoding a = >certain QoS to a specific flow, applying some security functions to=20 >some flows, etc. The classification node can use simple VLAN-ID to mark = >different classification. > >P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? > >I think the Wireless Service Chain example given by Walter at Berlin=20 >SFC BOF is very good. > >Walter's wireless example is described in the Section 3.2 of=20 >https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-ar >chi >tecture/ > >Maybe you can use the text to replace your Section 2.3? Here is the=20 >suggested text: >----------------- >The P-GW/PCEF (per 3GPP terminology) determines the desired service=20 >treatment, i.e. desired sequence of service functions, to specific=20 >flows based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based=20 >on the policies from PCRF. The traffic in each category (or flow) is=20 >mapped to a unique interface (a physical or virtual port) or a tunnel=20 >that is connected to the needed sequence of service functions. >=20 > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF | | |Network| > | | < ---- > |Ctrller| > +-----+ | +----+--+ > | | > | | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > | [PCEF]| | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > >Linda > >-----Original Message----- >From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] >Sent: Sunday, February 09, 2014 1:44 PM >To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin=20 >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Linda, > >First, thanks for the feedback. While it may look like a lot of=20 >components, we still have simplified 3GPP quite a lot. For example, in=20 >the first draft we left out the TDF that appears in recent standards. >We=B9ll be adding that in response to other comments. I believe the=20 >overview section is still quite short, but we will try to shorten it a=20 >bit further if it is too long. If you feel anything in particular is=20 >missing or extraneous, please let us know. > >Yes, it is probably overkill to have two example APNs. The User & Pass=20 >are important for example in cases of hot-lining where the user must=20 >first be authenticated (for various reasons) before data services are=20 >provided/continued. It is just another example of the important=20 >relationship between Classification (in an SFC sense) and Policy and=20 >Charging (in a 3GPP sense). > >Cheers, >Jeff > >-----Original Message----- >From: Linda Dunbar >Date: Friday, February 7, 2014 at 11:14 PM >To: "Haeffner, Walter, Vodafone DE" ,=20 >Dave Dolson , Martin Stiemerling=20 >, "draft-haeffner-sfc-use-case-mobility@tools.ietf.o= rg" >, "sfc@ietf.org" > >Cc: Jeffrey Napper >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >>Walter, et al, >> >>While it is interesting to show all the components of 3GPP for GiLAN,=20 >>but I don't think it is necessary to have all of them in the SFC use=20 >>case draft. >> >>For example, on your Section 2.3 ("The Most common classification=20 >>scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >>"User name & Password". Does it mean that the "User Name & Password" >>have to associated with data packets? Or to be detected by the=20 >>Classification nodes? >> >>Linda >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter, = >>Vodafone DE >>Sent: Wednesday, February 05, 2014 7:21 PM >>To: Dave Dolson; Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >>Subject: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi Dave, >>Thanks for your comment. We are going to include a Rel.11 TDF=20 >>paragraph in -01. Possibly we will consider 2 sections: most simple=20 >>case (with APN), actual most advanced case (with TDF). >>Regards, >>Walter >> >>-----Urspr=FCngliche Nachricht----- >>Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >>Gesendet: Dienstag, 4. Februar 2014 20:23 >>An: Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Betreff: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >>arrangement of mobility architecture, it neglects to show the role of=20 >>the Traffic Detection Function (TDF), also described in the cited 3GPP = >>TS >>23.203 (Version 12). >> >>I don't want to argue with the use cases, just the implied network=20 >>architecture. >> >>In all of the network diagrams and examples, it should be understood=20 >>that the P-GW is not the only location from which a policy-based=20 >>service chain could be initiated; the standard TDF function can also=20 >>initiate service chains selected by policy and traffic type. >> >>Section 2.1 should show an optional TDF element between the P-GW and=20 >>the (S)Gi-LAN. >> >>A TDF communicates with a PCRF using the Sd interface, from which it=20 >>receives Application Detection and Control (ADC) rules, similar to the = >>rules deployed to the P-GW via the Gx interface. >> >>Aside from the APN classification scheme mentioned in section 2.3 of=20 >>the draft, ADC rules can cause decisions based on application type=20 >>(not just based on APN or UDP/TCP port classification). >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin=20 >>Stiemerling >>Sent: Wednesday, January 29, 2014 9:46 AM >>To: sfc@ietf.org >>Subject: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi all, >> >>I wanted to raise your attention to the below quoted draft, as it=20 >>wasn't posted to the SFC list. >> >>The draft outlines very well the use cases in mobile networks. >> >>Thanks, >> >> Martin >> >> >>-------- Original Message -------- >>Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >>Date: Tue, 28 Jan 2014 14:26:15 -0800 >>From: internet-drafts@ietf.org >>Reply-To: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> >> >> Title : Service Function Chaining Use Cases in Mobil= e >>Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >> Pages : 17 >> Date : 2014-01-28 >> >>Abstract: >> This document provides some exemplary use cases for service functio= n >> chaining in mobile service provider networks. The objective of thi= s >> 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 and framework statemen= ts >> of the working group. >> >> Service function chains typically reside in a LAN segment which lin= ks >> the mobile access network to the actual application platforms locat= ed >> in the carrier's datacenters or somewhere else in the Internet. >> Service function chains ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery, take care of security and privacy = or >> support application and business support platforms. General >> considerations and specific use cases are presented in this documen= t >> to demonstrate the different technical requirements of these goals >> for service function chaining in mobile service provider networks. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>_______________________________________________ >>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 >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > > > >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > > > #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Tue Feb 18 10:29:26 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031661A0408 for ; Tue, 18 Feb 2014 10:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 ox8uVppFCdOw for ; Tue, 18 Feb 2014 10:29:19 -0800 (PST) Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA821A06DD for ; Tue, 18 Feb 2014 10:29:19 -0800 (PST) Received: from mailint09.vodafone.com (localhost [127.0.0.1]) by mailout09.vodafone.com (Postfix) with ESMTP id BC02AE143F for ; Tue, 18 Feb 2014 19:29:12 +0100 (CET) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09.vodafone.com (Postfix) with ESMTPS id A6BFBE13D6; Tue, 18 Feb 2014 19:29:12 +0100 (CET) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.50]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0146.002; Tue, 18 Feb 2014 19:29:11 +0100 From: "Haeffner, Walter, Vodafone DE" To: Alla Goldner , "Jeffrey Napper (jenapper)" , Jerome Moisand , Linda Dunbar , Dave Dolson , "Martin Stiemerling" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , "sfc@ietf.org" , "diego@tid.es" Thread-Topic: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt Thread-Index: AQHPLNV+qDauYU1b60arTsz8WsLYK5q7Ql8AgAARcZA= Date: Tue, 18 Feb 2014 18:29:11 +0000 Message-ID: References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/O9kkj7PbGdU0fR7cCUU1u_qxF7Y Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:29:25 -0000 Hi Alla,=20 Thanks for your support. We will correct the 3GPPP doc reference and well, = you are right, TDF came with Rel. 11 (as I remarked in an earlier mail). Regards,=20 Walter =20 -----Urspr=FCngliche Nachricht----- Von: Alla Goldner [mailto:agoldner@allot.com]=20 Gesendet: Dienstag, 18. Februar 2014 19:23 An: Jeffrey Napper (jenapper); Jerome Moisand; Linda Dunbar; Haeffner, Walt= er, Vodafone DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-ca= se-mobility@tools.ietf.org; sfc@ietf.org; diego@tid.es Betreff: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi, Thanks a lot for this update! There are two things which needs to be corrected: 1. The related 3GPP specification should be TS 23.203 and not TS 29.212 (29= .212 is protocol level description only while TS 23.203 defines general PCC= architecture). 2. The sentence "The Traffic Detection Function (TDF) [TS.29.212] is curren= tly under standardization within 3GPP." is not correct, as TDF was standard= ized back in R11 of 3GPP and this is an existing entity for the last couple= of years thus should be described as a such. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972= 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 agoldner@allot.com www.a= llot.com -----Original Message----- From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com]=20 Sent: Tuesday, February 18, 2014 8:16 PM To: Jerome Moisand; Alla Goldner; Linda Dunbar; Haeffner, Walter, Vodafone = DE; Dave Dolson; Martin Stiemerling; draft-haeffner-sfc-use-case-mobility@t= ools.ietf.org; sfc@ietf.org; diego@tid.es Subject: Re: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00= .txt Hi guys, Yes, we have submitted a revision that includes discussion of the TDF. https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ The changes from the previous draft include a short comparison of fixed net= works that are similar to 3GPP, introduction of the TDF, additional co-auth= ors Martin and Diego, and some other tidying up. I hope that the new text addresses your concerns. Please let us know if the= re are still problems with the text. I think Walter will present some slide= s over the draft in London. Cheers, Jeff -----Original Message----- From: Jerome Moisand Date: Friday, February 14, 2014 at 4:28 PM To: Alla Goldner , Linda Dunbar , Jeffrey Napper , "Haeffner, Walter, Vodafone DE" , Dave Dolson , Martin St= iemerling , "draft-haeffner-sfc-use-case-mobility@tools= .ietf.org" , "sfc@ietf.org" Subject: RE: [sfc] Fwd: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >Linda, > >A PGW is a PCEF for sure (hence is more than a classifier). So this=20 >part of your proposed drawing would have to be improved. > >Now in the TDF case, a better drawing would show PGW(PCEF) and=20 >TDF(PCEF) in sequence. As this is the reality of things, a TDF does not=20 >replace a PGW, it (optionally) complements it. > >Anyhoo, I feel we're going a bit in circles here. Why not letting the=20 >authors of this draft (who obviously know the 3GPP constructs very=20 >well) improve it as they see fit based on the feedback? > >Tx >Jerome > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Friday, February 14, 2014 1:43 AM >To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Linda, all, > >I think this presentation is more correct, thank you. > >One thing though may need to be corrected: PCEF is an integral part of=20 >PGW as defined by 3GPP standards. Therefore, we may, as an option,=20 >mention "PCEF/TDF" without "PGW", and then put a note that PCEF resides=20 >in PGW. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Friday, February 14, 2014 1:17 AM >To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla, Jerome, > >Since 3GPP has defined many components and are still involving, can we=20 >use a simplified box to represent an entity associated with P-GW that=20 >classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such as: > > > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF/| | |Network| > |rules| < ---- > |Ctrller| > +-----+ | +----+--+ > | | > V | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| & or | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > |TDF/PCEF | | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > > >As for the description of metadata used by Gi-LAN service function, we=20 >don't have to specifically say which elements defined by 3GPP encoded=20 >them in. > > >Linda >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 10:30 AM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >I don't know if the whole PCC architecture is truly optional in 3GPP=20 >theory (I've never seen it expressed that way, but I'll take your word=20 >for it), but one would be hard-pressed to find a 3G/LTE mobile=20 >broadband network without it. So in practice my 100% statement remains=20 >true (I'll give you 99.9% if you wish!). > >So I have a bit of an issue putting PGW and TDF at the same level. This=20 >simply doesn't reflect any reality, nor the spirit of the 3GPP specs. > >And in the fixed-broadband world in BBF terms, yeah, the BNG IS=20 >mandatory (I took a very active role in several of those specs, e.g.=20 >TR-101). While a DPI function is truly optional (and not that many=20 >subscribers in absolute % go through it in practice) and not standardized. > >Anyway, I agree with you that mobile use cases with or without TDF=20 >should be considered. A case without PGW would seem much more dubious=20 >to me. We may be saying more or the same thing, overall. > >-----Original Message----- >From: Alla Goldner [mailto:agoldner@allot.com] >Sent: Thursday, February 13, 2014 11:15 AM >To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Dear Jerome, > >Yes, TDF is an optional element in mobile networks. As a such, Sd=20 >interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface=20 >is optional in exactly the same way. The whole 3GPP PCC architecture is=20 >optional. Therefore, the claim about 100% of mobile data subscribers=20 >may not be fully correct. And with regards to the features required for=20 >service classification and service enforcement that you describe below=20 >- they are present at both GGSN/PGW and TDF. > >The bottom line is that use cases where PGW is considered as classifier=20 >OF COURSE should be considered, same as use cases where TDF is=20 >considered as a classifier. And, once describing those use cases, the=20 >existing 3GPP architecture should be assumed. > >Best regards, > > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: Jerome Moisand [mailto:jmoisand@juniper.net] >Sent: Thursday, February 13, 2014 5:27 PM >To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20 >Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Alla & folks, > >Well... I don't know... Getting deep in network architectures and the=20 >role of the various network elements is indeed crucial. Both 3GPP and=20 >BBF (Broadband Forum) did a lot of work in the past decade to define=20 >architecture & nodal requirements, which shaped in turn the deployment=20 >of all major Service Providers worldwide. So quite clearly, service=20 >chaining have to build on that and find a good way to insert itself=20 >into such architectures while extending them. > >Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate=20 >for service classification/enforcement, as it... already does it for=20 >its own purpose! This is BY NATURE a highly scalable subscriber &=20 >service management system, classifying and enforcing policies (usually=20 >L3, occasionally higher), and fully integrated with the HSS/PCRF chain=20 >which holds the subscriber/service authentication & authorization data.=20 >As such, service classification *and* service enforcement (and service >accounting) is already there. For 100% of the mobile (data) subscribers. >Sure enough, a TDF system may also do its own form of service=20 >classification (and processing too), but let's not forget this is an=20 >OPTIONAL system on the data path on the recently defined 3GPP=20 >architectures you referred to. For many use cases, there is just no=20 >point going through a DPI function. While for other use cases, there is=20 >clearly such a point, but only when it brings clear value for a given=20 >service construct, only applicable to corresponding subscribers. > >In the same vein, in fixed-broadband architectures, a BNG is the=20 >primary subscriber management system on the data path, fully integrated=20 >with a AAA system, and already doing service classification *and*=20 >service processing at scale for 100% of the subscribers. Any=20 >classification/enforcement system behind it is optional and only=20 >applicable to a subset of services & subscribers. > >Bottomline: sure, use cases with TDF should be described, but=20 >PGW-centric use cases remain the rule, not the exception. And=20 >double-clicking on existing standardized network architectures (e.g.=20 >3GPP and BBF) and related deployments is crucial for our SFC endeavor. > >Jerome Moisand. > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner >Sent: Thursday, February 13, 2014 1:18 AM >To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone=20 >DE; Dave Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Deal Linda, > >The 3GPP architecture picture described below is not accurate. >Starting from R11, PCRF interacts also with TDF (Traffic Detection >Function) for providing ADC (Application Detection and Control) Rules=20 >for application detection, enforcement and also charging starting from R12= . >Please see architecture diagram for your reference in the 3GPP TS 23.203. > >Therefore, we can't assume that "Since PCRF usually only interfaces=20 >with the GGSN (via Diameter), not the service functions, do you mean=20 >"for the GGSN (or the flow classifier) to carry the data passed down=20 >from PCRF to packets' metadata field to service functions on the chain"?" > >Furthermore, also the claim that >"The P-GW/PCEF (per 3GPP terminology) determines the desired service=20 >treatment, i.e. desired sequence of service functions, to specific=20 >flows based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based=20 >on the policies from PCRF. The traffic in each category (or flow) is=20 >mapped to a unique interface (a physical or virtual port) or a tunnel=20 >that is connected to the needed sequence of service functions." is not=20 >correct as well as PGW/PCEF is not the only element which enforces=20 >different support per different flows based on policies received from PCRF= , but also TDF! > >My general feeling is that we are getting here deeply into 3GPP=20 >architecture and make assumptions and conclusions about potential 3GPP=20 >elements functionality which are not in scope of IETF. If we want to=20 >define use cases for 3GPP networks, then we should show correct=20 >picture of 3GPP architecture without redesigning it and leave 3GPP=20 >Network Elements functionality potential extensions to 3GPP. > >Best regards, > >Alla Goldner >Director of Mobile Technologies and Standards Allot Communications Tel >+972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >+agoldner@allot.com >www.allot.com > > > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >Sent: Thursday, February 13, 2014 12:13 AM >To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave=20 >Dolson; Martin Stiemerling;=20 >draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Jeffrey and Walter, > >Here are some suggestions to your draft: > >Section 2.2:=20 >- your draft states "The Gi-LAN service functions may use subscriber=20 >and service related metadata delivered from mobile control plane=20 >function like PCRF to process the flows according to service related polic= ies" > >Since PCRF usually only interfaces with the GGSN (via Diameter), not=20 >the service functions, do you mean "for the GGSN (or the flow=20 >classifier) to carry the data passed down from PCRF to packets'=20 >metadata field to service functions on the chain"? >Since the policies passed down by PCRF usually can't be understood by=20 >service functions, I suggest changing to the following text: > >"The (S)Gi-LAN service functions may use subscriber and service related=20 >information, that are either embedded in packets as metadata or passed=20 >down from control plane, to process the flows according to service=20 >related policies" > > >Section 2.3 The most common classification scheme > >I think this section is very confusing. How is "APN for P-GW IP address" >used in traffic classification? > >Are you saying that traffic are grouped to specific P-GW? And each APN=20 >has a VLAN-ID? > >I understand that some common classification scheme could be encoding a=20 >certain QoS to a specific flow, applying some security functions to=20 >some flows, etc. The classification node can use simple VLAN-ID to mark=20 >different classification. > >P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? > >I think the Wireless Service Chain example given by Walter at Berlin=20 >SFC BOF is very good. > >Walter's wireless example is described in the Section 3.2 of=20 >https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-ar >chi >tecture/ > >Maybe you can use the text to replace your Section 2.3? Here is the=20 >suggested text: >----------------- >The P-GW/PCEF (per 3GPP terminology) determines the desired service=20 >treatment, i.e. desired sequence of service functions, to specific=20 >flows based on the policies from PCRF. >The P-GW in the figure acts as the Service Chain Classification Node. >P-GW separates the traffic into different categories (or flows) based=20 >on the policies from PCRF. The traffic in each category (or flow) is=20 >mapped to a unique interface (a physical or virtual port) or a tunnel=20 >that is connected to the needed sequence of service functions. >=20 > | Mobile backhaul Network > +-----+ | +---+---+ > |PCRF | | |Network| > | | < ---- > |Ctrller| > +-----+ | +----+--+ > | | > | | > +---------+ | +--------+ +----+ +---------+ >-- >| P-GW | --> |LB |---| FW |--> | Web | ------> > | | | | | | | | Proxy | >--->| | | +--------+ +----+ +---------+ >--->| | | +---------+ +----+ >-- >| | --> |Video |---| FW |--> ----------- ------> > | [PCEF]| | |Optimizer| | | > | | | +---------+ +----+ >--->| | | +--------+ +-----+ >-- >| | --> |SBC |---| ACL |--> ----------- ------> > | | | | | | | > +---------+ | +--------+ +-----+ > >Figure 1 Service Chain for Mobile Network > >Linda > >-----Original Message----- >From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] >Sent: Sunday, February 09, 2014 1:44 PM >To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin=20 >Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >sfc@ietf.org >Subject: Re: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >Hi Linda, > >First, thanks for the feedback. While it may look like a lot of=20 >components, we still have simplified 3GPP quite a lot. For example, in=20 >the first draft we left out the TDF that appears in recent standards. >We=B9ll be adding that in response to other comments. I believe the=20 >overview section is still quite short, but we will try to shorten it a=20 >bit further if it is too long. If you feel anything in particular is=20 >missing or extraneous, please let us know. > >Yes, it is probably overkill to have two example APNs. The User & Pass=20 >are important for example in cases of hot-lining where the user must=20 >first be authenticated (for various reasons) before data services are=20 >provided/continued. It is just another example of the important=20 >relationship between Classification (in an SFC sense) and Policy and=20 >Charging (in a 3GPP sense). > >Cheers, >Jeff > >-----Original Message----- >From: Linda Dunbar >Date: Friday, February 7, 2014 at 11:14 PM >To: "Haeffner, Walter, Vodafone DE" ,=20 >Dave Dolson , Martin Stiemerling=20 >, "draft-haeffner-sfc-use-case-mobility@tools.ietf.org= " >, "sfc@ietf.org" > >Cc: Jeffrey Napper >Subject: RE: [sfc] Fwd: I-D Action: >draft-haeffner-sfc-use-case-mobility-00.txt > >>Walter, et al, >> >>While it is interesting to show all the components of 3GPP for GiLAN,=20 >>but I don't think it is necessary to have all of them in the SFC use=20 >>case draft. >> >>For example, on your Section 2.3 ("The Most common classification=20 >>scheme"), it is very confusing to have the Table 1 & Table 2 listing=20 >>"User name & Password". Does it mean that the "User Name & Password" >>have to associated with data packets? Or to be detected by the=20 >>Classification nodes? >> >>Linda >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, Walter,=20 >>Vodafone DE >>Sent: Wednesday, February 05, 2014 7:21 PM >>To: Dave Dolson; Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >>Subject: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi Dave, >>Thanks for your comment. We are going to include a Rel.11 TDF=20 >>paragraph in -01. Possibly we will consider 2 sections: most simple=20 >>case (with APN), actual most advanced case (with TDF). >>Regards, >>Walter >> >>-----Urspr=FCngliche Nachricht----- >>Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >>Gesendet: Dienstag, 4. Februar 2014 20:23 >>An: Martin Stiemerling; >>draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>Betreff: Re: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >>arrangement of mobility architecture, it neglects to show the role of=20 >>the Traffic Detection Function (TDF), also described in the cited 3GPP=20 >>TS >>23.203 (Version 12). >> >>I don't want to argue with the use cases, just the implied network=20 >>architecture. >> >>In all of the network diagrams and examples, it should be understood=20 >>that the P-GW is not the only location from which a policy-based=20 >>service chain could be initiated; the standard TDF function can also=20 >>initiate service chains selected by policy and traffic type. >> >>Section 2.1 should show an optional TDF element between the P-GW and=20 >>the (S)Gi-LAN. >> >>A TDF communicates with a PCRF using the Sd interface, from which it=20 >>receives Application Detection and Control (ADC) rules, similar to the=20 >>rules deployed to the P-GW via the Gx interface. >> >>Aside from the APN classification scheme mentioned in section 2.3 of=20 >>the draft, ADC rules can cause decisions based on application type=20 >>(not just based on APN or UDP/TCP port classification). >> >> >> >> >>-----Original Message----- >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin=20 >>Stiemerling >>Sent: Wednesday, January 29, 2014 9:46 AM >>To: sfc@ietf.org >>Subject: [sfc] Fwd: I-D Action: >>draft-haeffner-sfc-use-case-mobility-00.txt >> >>Hi all, >> >>I wanted to raise your attention to the below quoted draft, as it=20 >>wasn't posted to the SFC list. >> >>The draft outlines very well the use cases in mobile networks. >> >>Thanks, >> >> Martin >> >> >>-------- Original Message -------- >>Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >>Date: Tue, 28 Jan 2014 14:26:15 -0800 >>From: internet-drafts@ietf.org >>Reply-To: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> >> >> Title : Service Function Chaining Use Cases in Mobile >>Networks >> Authors : Walter Haeffner >> Jeffrey Napper >> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >> Pages : 17 >> Date : 2014-01-28 >> >>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 and framework statements >> 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 ensure a fair distribution of network >> resources according to agreed service policies, enhance the >> performance of service delivery, take care of security and privacy or >> support application and business support platforms. 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 IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>_______________________________________________ >>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 >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > > > >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc >####################################################################### >### >#################### >This message is intended only for the designated recipient(s).It may=20 >contain confidential or proprietary information. >If you are not the designated recipient, you may not review, copy or=20 >distribute this message. >If you have mistakenly received this message, please notify the sender=20 >by a reply e-mail and delete this message. >Thank you. >####################################################################### >### >#################### > > > ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.=20 Thank you. ###########################################################################= ################### From nobody Tue Feb 18 16:32:38 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB41A0423 for ; Tue, 18 Feb 2014 16:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 LvqQ8A6cmQVu for ; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 809121A010A for ; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Feb 2014 17:32:28 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 18 Feb 2014 17:32:26 -0700 Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 12D153E4003E for ; Tue, 18 Feb 2014 17:32:26 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08027.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1J0W2Yb7012684 for ; Wed, 19 Feb 2014 01:32:02 +0100 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1J0WPcr019246 for ; Tue, 18 Feb 2014 17:32:25 -0700 Received: from cichlid.raleigh.ibm.com (dyn9050016163.mts.ibm.com [9.50.16.163] (may be forged)) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s1J0WOk0019190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Feb 2014 17:32:25 -0700 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s1J0WNs9023710 for ; Tue, 18 Feb 2014 19:32:23 -0500 Date: Tue, 18 Feb 2014 19:32:23 -0500 Message-ID: From: Thomas Narten To: sfc@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14021900-3532-0000-0000-000005CB17E7 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HqUEPR5Xobii0jMkI_u7Gqj7lUM Subject: [sfc] Draft SFC agenda for London X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:32:35 -0000 WG, Below is draft agenda for the London SFC meeting. Note that it is a draft and we may make changes. (And if you made a request but didn't get a response from us, please resend it to us in case we missed it.) The goal for London is to make the best use of face-to-face time. We are open to suggestions on where we need to spend the most time and on which topics are the most urgent. Note that we have a lot of drafts (20+ by my count) in the general area of SFC. We obviously can't give them all agenda time. The drafts that were given agenda time mostly get only 10 minutes. One can't do much with a ten minute slot, so the goal isn't to present what is in the draft (folk can presumably read the draft for that). Rather, it is to help the WG decide what to do with the ID. That is, what should happen to its content. E.g.: - Document has useful content that should be moved into another (WG) document. - Good basis for one of the WG documents per the charter (In order for that to happen the document needs to be the most appropriate out of the collection of related documents) - Merge document with one or more other documents, so that combined document could become WG document. - Useful info, but no need for WG to take on formally, may or may not eventually get published as an RFC. - Something else... (e.g., too solution oriented for now, defer until after the WG has gotten further in its work, etc.) Agenda below. Thomas & Jim IETF89 London SFC Agenda Total time: 2.5 hours 0.00 Introduction (WG-chairs) - [5 minutes] - BBF/IETF SFC Liaison - Review of charter priorities 00.05 SFC problem statement discussion - [10 minutes] Purpose: Are there any outstanding issues? can we start WGLC with goal of sending to IESG [milestone April 2014] - Problem statement review (Thomas Nadeau) - [5 minutes] * http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ - Problem statement Q&A (open-mic) - [5 minutes] 00:15 SFC use case/requirements discussion (WG-chairs, presenters + open-mic) - [70 minutes] Purpose: Work towards having a single WG document plus a small number of more detailed scenario-specific use case documents. No need for a document on every possible use case. Further discuss SFC requirements and how use cases are driving those requirements; do we need an overall document tracking requirements? Questions to answer: 1) which document should be the overview document, and what use cases should it cover? mailing list discussion suggests draft-liu-sfc-use-cases as the best candidate to fulfill this role. 2) which documents are worth pursuing as standalone WG documents? - SFC use case direction and evolution (WG-chairs) - [10 minutes] - SFC use cases (Shucheng Liu) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ - SFC long lived flows use cases (Ramki Krishnan) - [10 minutes] * http://datatracker.ietf.org/doc/draft-krishnan-sfc-long-lived-flow-use-cases/ - SFC mobility use cases (Jeff Napper) - [10 minutes] * http://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ - SFC DC use cases (Surendra Kumar) - [10 minutes] * http://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/ - Requirements for SFC (TBD) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ - SFC use cases/requirements Q&A (open-mic) - [10 minutes] 01:25 SFC architecture discussion (presenters + open-mic) - [30 minutes] Purpose: work towards having a single WG document. How do we get there? what gaps need filling from other existing documents? - SFC architecture (Paul Quinn/Andre Bellevue) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch/ - SFC architecture & framework (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework/ - SFC architecture Q&A (open-mic) - [10 minutes] 01:55 Requirements/motivations for encapsulation functionality - [30 minutes] Purpose: review requirements for the SFC service encapsulation and metadata considerations. - Metadata Considerations (Ross Callon) - [10 minutes] * http://datatracker.ietf.org/doc/draft-rijsman-sfc-metadata-considerations/ - Network Service Headers (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ - Requirements/motivations Q&A (open-mic) - [10 minutes] 02:25 Closing (WG chairs) - [5 minutes] From nobody Wed Feb 19 19:07:41 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654051A0291 for ; Wed, 19 Feb 2014 19:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.447 X-Spam-Level: X-Spam-Status: No, score=-100.447 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMrRqgZErCmT for ; Wed, 19 Feb 2014 19:07:35 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 190AA1A03CF for ; Wed, 19 Feb 2014 19:07:35 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 0C0EE2A414 for ; Thu, 20 Feb 2014 11:07:22 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E3849718A71; Thu, 20 Feb 2014 11:07:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s1K37KaS010814; Thu, 20 Feb 2014 11:07:20 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: mohamed.boucadair@orange.com MIME-Version: 1.0 X-KeepSent: FC1EBB1F:5E46E084-48257C85:000EBFD6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Thu, 20 Feb 2014 11:07:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-20 11:07:02, Serialize complete at 2014-02-20 11:07:02 Content-Type: multipart/alternative; boundary="=_alternative 0011103448257C85_=" X-MAIL: mse02.zte.com.cn s1K37KaS010814 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WeB0GIefQzz1So-hyFvfXXEfCHg Cc: Wei Meng , wang.cui1@zte.com.cn, sfc@ietf.org, Bhumip Khasnabish Subject: [sfc] Framework & routing X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 03:07:39 -0000 This is a multipart message in MIME format. --=_alternative 0011103448257C85_= Content-Type: text/plain; charset="US-ASCII" Hi, med I was looking at your framework proposal. The proposal elaborates on framework & PDP architecture and some deployment considerations such as deployment models. In section 10.2 para 3, it describes a router-based mechanisam which offers a default router for the packets delivery between SF nodes. However,I would like to know how inbound traffic steer packets to the Ingress Node for inbound direction ? Such as, there is a NAT44 SF node with public ipv4 address pool 12.3.4.0/24, then how to advertise this route to the legacy network for the inbound traffic ? This maybe a deployment consideration need to point out. BRs, Linda -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0011103448257C85_= Content-Type: text/html; charset="US-ASCII"
Hi, med

  I was looking at your framework proposal.

  The proposal elaborates on framework &  PDP architecture and
  some deployment considerations such as deployment models.
 
  In section 10.2 para 3, it describes a router-based mechanisam
  which offers a default router for the packets delivery between
  SF nodes.

  However,I would like to know how inbound traffic steer packets
  to the Ingress Node for inbound direction ?
  Such as, there is a NAT44 SF node with public ipv4 address pool
  12.3.4.0/24, then how to advertise this route to the legacy network
  for the inbound traffic ?
  This maybe a deployment consideration need to point out.

BRs,
Linda 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0011103448257C85_=-- From nobody Wed Feb 19 21:27:18 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2643A1A0329 for ; Wed, 19 Feb 2014 21:27: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 zw93Y1BPn5YZ for ; Wed, 19 Feb 2014 21:27:12 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1D11A02D8 for ; Wed, 19 Feb 2014 21:27:12 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id x10so1334887pdj.8 for ; Wed, 19 Feb 2014 21:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:mime-version:message-id :content-type; bh=O2kC7FGLA7Yp4T1UHUT/Yvso0wVd3NjUgNUKuIkMkJQ=; b=UQ8dSztj36gpLvdmCLComQm6NEJZRuwVehj23GBSSEVOVLTELN9WSoP8XywCHq0Bfk I8UyDuN5Fc9eTmO1TmmSv6rfzVm5bcOxChKH4HYrZytLle78dKisKCyduW6/0aGz9+Rx yLfgSQwZCHFHSoDSOCc2RCyRnrYWqimuG0oAYV2AU1X7/QlTNf0efrl2tVzrL++4sic7 DzybSAtu8IwNqtYHP4pwRYHVj3Gdcp3hyC4p5WDiN8L4nTasIQr0ZQ7nQ9s/Uo1erAY/ P5RADDXXvQxhRPyxpORpBWEIPv4QUhiBPsTPlnvsZ+Mbkru8fcUm7Zrcrl9vcs3v3L4c a1dw== X-Received: by 10.66.119.172 with SMTP id kv12mr44498589pab.34.1392874029314; Wed, 19 Feb 2014 21:27:09 -0800 (PST) Received: from netlab-PC ([166.111.68.231]) by mx.google.com with ESMTPSA id qs1sm6623573pbb.18.2014.02.19.21.27.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 19 Feb 2014 21:27:07 -0800 (PST) Date: Thu, 20 Feb 2014 13:27:06 +0800 From: "Yuchi Chen" To: meng.wei2 X-Priority: 3 X-GUID: FD4F5B0B-B281-4D2B-B1B6-A1830F60F7D6 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20140219111718535910110@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart762480753367_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YgQ1tc53jzqvegAlBvpTiIepG_Q Cc: sfc Subject: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 05:27:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart762480753367_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2VpLA0KDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0LiBJTUhPIHRoaXMgZHJhZnQgcHJvdmlkZXMg YSBuZXcgcG9pbnQgb2YgdmlldyB0aGF0IFNGQyBjYW4gYmUgYXBwbGllZCBpbiB0aGUgZGVwbG95 bWVudCBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gDQoNCkhlcmUgaXMgYSBxdWVzdGlv biBJIGhhdmU6ICB3aGF0IGlzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBDUEUvQk5BUyBhbmQg dGhlIGNsYXNzaWZpZXI/IEZvciBub3cgdGhlIGNsYXNzaWZpZXIgc2VlbXMgdG8gYmUgYW4gaW5k aXZpZHVhbCBkZXZpY2UuIElmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgSSB0aGluayBp dCBtaWdodCBiZSB0cml2YWwgdG8gaW1wbGVtZW50IHN1Y2ggdmFyaW91cyBkZXZpY2VzLCBhcyB0 aGVpciBzcGVjZmljYXRpb25zIHNob3VsZCBxdWl0ZSBkZXBlbmQgb24gdGhlaXIgYWN0dWFsIGxv Y2F0aW9ucyBpbiB0aGUgbmV0d29yay4gSXMgaXQgcG9zc2libGUgdG8gbGV0IENQRS9CTkFTIHBl cmZvcm0gdGhlIHNlcnZpY2UgZnVuY3Rpb25zPw0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0KDQpZdWNo aSBDaGVu ------=_001_NextPart762480753367_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Wei,
 
I've read the draft. IMHO this draft provides a n= ew=20 point of view that SFC can be applied in the deployment of=20 IPv6 transition mechanisms.
 
Here is a question I have:  what is the relations= hip=20 between CPE/BNAS and the classifier? For now the classifier seems to be an= =20 individual device. If I understand this correctly, I think = it=20 might be trival to implement such various devices,=20 as their specfications should quite depend on their ac= tual=20 locations in the network. Is it possible to let CPE/BNAS pe= rform=20 the service functions?
 
Best regards!
Yuc= hi=20 Chen
------=_001_NextPart762480753367_=------ From nobody Thu Feb 20 11:53:30 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D879B1A01FD for ; Thu, 20 Feb 2014 11:51:38 -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, 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 xBuPh3Mj23e2 for ; Thu, 20 Feb 2014 11:51:36 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA861A0253 for ; Thu, 20 Feb 2014 11:51:36 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-8d-53065cc52889 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A7.CF.11484.5CC56035; Thu, 20 Feb 2014 20:51:33 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 14:51:31 -0500 From: David Sinicrope To: "sfc@ietf.org" Thread-Topic: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" Thread-Index: AQHPKP1/X5ceh++Z40O22iDFEi75Qpq+mFOH Date: Thu, 20 Feb 2014 19:51:31 +0000 Message-ID: <8B9D86CE-44C0-431F-8764-8D4BDFB526F6@ericsson.com> References: <20140213205221.31626.74483.idtracker@ietfa.amsl.com> In-Reply-To: <20140213205221.31626.74483.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8B9D86CE44C0431F87648D4BDFB526F6ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyuXRPoO7RGLZgg5vfDCyePNjK7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJXLb7MVfLGp2Ni8kqmBcb9FFyMnh4SAicSbl6eYIWwxiQv3 1rN1MXJxCAkcYZS4few9I4SznFFi24wJTCBVbEAd6zbuYQGxRQQUJc69nABmCwskSyz+0MUE EU+WmD7vJyOEbSSx4PA0NhCbRUBVYu+6PrAaXgF7ibNvDoH1Cgk4Sjy8+xHM5hRwkng2fSc7 iM0IdNH3U2vA6pkFxCVuPZnPBHGpgMSSPeehrhaVePn4HytETbJE77vrrBDzBSVOznzCMoFR eBaS9llIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAmPi mASb4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR/PD5tamn SlWuPtob9thl2RLR6ef8p502Er9SEmmh2c/rIPtYao2q79UvDunvGd8y5n6126LC/OzGwq7K bTb7tzZcqlj0zIbhe6nc1WeHJYSmWAafMXCufaUubXmZ42FvbcW3NPHCb+vXslzatfdJc+GR Ezaz6//MzOvep+kWVv5wx80d+fXHlFiKMxINtZiLihMB+0HdAVcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0Vr0GjJFGQ4wJkJBnT3aQeV-eFg X-Mailman-Approved-At: Thu, 20 Feb 2014 11:53:28 -0800 Subject: [sfc] Fwd: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:51:39 -0000 --_000_8B9D86CE44C0431F87648D4BDFB526F6ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: Liaison Statement Management Tool > Date: February 13, 2014 at 15:52:21 EST To: Jim Guichard >, Thomas Na= rten > Cc: Stewart Bryant >, Adrian = Farrel >, David Sinicrope <= david.sinicrope@ericsson.com>, >, >, >, >, >, >, >, >, >, > Subject: New Liaison Statement, "Broadband Forum Work on Flexible Service C= haining (SD-326)" Title: Broadband Forum Work on Flexible Service Chaining (SD-326) Submission Date: 2014-02-13 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/ From: Broadband Forum (Christophe Alter >) To: Service Function Chaining (Jim Guichard >, Thomas Narten >) Cc: Stewart Bryant >,Adrian F= arrel >,David Sinicrope >,christophe= .alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat@alcatel-lucent.com,rmersh@broadband-forum.org,hongyu.li@huawei.com,jmoisand= @juniper.net,gbingham@broadband-forum.org,adrian@olddog.co.uk Response Contact: Technical Contact: Purpose: For information Body: Attachments: Broadband Forum Work on Flexible Service Chaining (SD-326) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-02-13-broadb= and-forum-sfc-broadband-forum-work-on-flexible-service-chaining-sd-326-atta= chment-1.pdf --_000_8B9D86CE44C0431F87648D4BDFB526F6ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI 


Begin forwarded message:

From: Liaison Statement Management Tool <lsmt@ietf.org>
Date: February 13, 2014 at 15:52:21 EST
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Cc: Stewart Bryant <stbryan= t@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>, David Sinicrope <david.sinicrope@ericsson.com>, <christophe.alter@orange= .com>, <sudawood@cisco.com<= /a>>, <georgedob= rowski@mail01.huawei.com>, <michael.fargano@centurylink.com>, <Christele.bouc= hat@alcatel-lucent.com>, <rmersh@broadband-forum.org>, <hongyu.li@huawei.com>, <jmoisand@juniper.net>, <gbingham@broadband-for= um.org>, <adrian@olddog.co= .uk>
Subject: New Liaison Statement, "Broadband Forum Work on Fle= xible Service Chaining (SD-326)"

Title: Broadband Forum Work on Flexible Service Chaining (SD-326= )
Submission Date: 2014-02-13
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/

From: Broadband Forum (Christophe Alter <christophe.alter@orange-ftgroup.com>)<= /span>
To: Service Function Chaining (Jim Guichard <jguichar@cisco.com>, Thomas Narten <narten@us.ibm.com>)
Cc: Stewart Bryant <stbryant= @cisco.com>,Adrian Farrel <adrian@olddog.co.uk>,David Sinicrope <david.sinicrope@ericsson.com>,christophe.alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat= @alcatel-lucent.com,rmers= h@broadband-forum.org,hongyu.li= @huawei.com,jmoisand@juniper.ne= t,gbingham@broadband-fo= rum.org,adrian@olddog.co.uk<= /span>
Response Contact:
Technical Contact:
Purpose: For information

Body:
Attachments:

   Broadband Forum Work on Flexible Service Chaining (= SD-326)
   https://datatracker.ietf.org/= documents/LIAISON/liaison-2014-02-13-broadband-forum-sfc-broadband-forum-wo= rk-on-flexible-service-chaining-sd-326-attachment-1.pdf

--_000_8B9D86CE44C0431F87648D4BDFB526F6ericssoncom_-- From nobody Thu Feb 20 11:57:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521601A0283 for ; Thu, 20 Feb 2014 11:57:51 -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, 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 FNJRB9nucns4 for ; Thu, 20 Feb 2014 11:57:48 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA61A01D6 for ; Thu, 20 Feb 2014 11:57:48 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-78-53065e39f8d4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FF.20.11484.93E56035; Thu, 20 Feb 2014 20:57:46 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 14:57:44 -0500 From: David Sinicrope To: "sfc@ietf.org" Thread-Topic: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" Thread-Index: AQHPKP1/X5ceh++Z40O22iDFEi75Qpq+mg7a Date: Thu, 20 Feb 2014 19:57:43 +0000 Message-ID: <7A7AE395-6DDC-4F46-87F7-BF9447C824A7@ericsson.com> References: <20140213205221.31626.74483.idtracker@ietfa.amsl.com> In-Reply-To: <20140213205221.31626.74483.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7A7AE3956DDC4F4687F7BF9447C824A7ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPrK5VHFuwwdlsiycPtrI7MHosWfKT KYAxissmJTUnsyy1SN8ugSuj73hZwQPbiptXj7M1MM617GLk5JAQMJGYcGYlI4QtJnHh3nq2 LkYuDiGBI4wSZye1M0M4yxklHt7uYgapYgPqWLdxDwuILSKgKHHu5QQwW1ggWWLxhy4miHiy xPR5PxkhbCOJYztegvWyCKhKvH4xBaiGg4NXwF7i1Hp5kLCQgKPEw7sfwcZwCjhJPJu+kx3E ZgQ66PupNWAjmQXEJW49mc8EcaiAxJI955khbFGJl4//sULUJEss/TuHDcTmFRCUODnzCcsE RuFZSNpnISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAiM hmMSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxnViPsJi u3dM+XJIYknFz6hLeTFO3BeOXki89+aKiB53x8MsvYnSWvUNiyZ/qHV88PFd2sWUi9lmCwOO L7OXc7x9lbPlbOLFIy+5fFlY97Ic786be7TKV+5WZk5R8cLkxDMbFgSdjmJiWL8yd5psX5Dd c+maJ7Pf29duPmv93rSFketDDPv3t0osxRmJhlrMRcWJAJUnArtUAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/j5o1e2Obi3y3tuDY7Deh3Gl21WY Subject: [sfc] Fwd: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:57:51 -0000 --_000_7A7AE3956DDC4F4687F7BF9447C824A7ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI David Sinicrope BBF/IETF Liaison Manager Begin forwarded message: From: Liaison Statement Management Tool > Date: February 13, 2014 at 15:52:21 EST To: Jim Guichard >, Thomas Na= rten > Cc: Stewart Bryant >, Adrian = Farrel >, David Sinicrope <= david.sinicrope@ericsson.com>, >, >, >, >, >, >, >, >, >, > Subject: New Liaison Statement, "Broadband Forum Work on Flexible Service C= haining (SD-326)" Title: Broadband Forum Work on Flexible Service Chaining (SD-326) Submission Date: 2014-02-13 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/ From: Broadband Forum (Christophe Alter >) To: Service Function Chaining (Jim Guichard >, Thomas Narten >) Cc: Stewart Bryant >,Adrian F= arrel >,David Sinicrope >,christophe= .alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat@alcatel-lucent.com,rmersh@broadband-forum.org,hongyu.li@huawei.com,jmoisand= @juniper.net,gbingham@broadband-forum.org,adrian@olddog.co.uk Response Contact: Technical Contact: Purpose: For information Body: Attachments: Broadband Forum Work on Flexible Service Chaining (SD-326) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-02-13-broadb= and-forum-sfc-broadband-forum-work-on-flexible-service-chaining-sd-326-atta= chment-1.pdf --_000_7A7AE3956DDC4F4687F7BF9447C824A7ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI 
David Sinicrope
BBF/IETF Liaison Manager


Begin forwarded message:

From: Liaison Statement Management Tool <lsmt@ietf.org>
Date: February 13, 2014 at 15:52:21 EST
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Cc: Stewart Bryant <stbryan= t@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>, David Sinicrope <david.sinicrope@ericsson.com>, <christophe.alter@orange= .com>, <sudawood@cisco.com<= /a>>, <georgedob= rowski@mail01.huawei.com>, <michael.fargano@centurylink.com>, <Christele.bouc= hat@alcatel-lucent.com>, <rmersh@broadband-forum.org>, <hongyu.li@huawei.com>, <jmoisand@juniper.net>, <gbingham@broadband-for= um.org>, <adrian@olddog.co= .uk>
Subject: New Liaison Statement, "Broadband Forum Work on Fle= xible Service Chaining (SD-326)"

Title: Broadband Forum Work on Flexible Service Chaining (SD-326= )
Submission Date: 2014-02-13
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/

From: Broadband Forum (Christophe Alter <christophe.alter@orange-ftgroup.com>)<= /span>
To: Service Function Chaining (Jim Guichard <jguichar@cisco.com>, Thomas Narten <narten@us.ibm.com>)
Cc: Stewart Bryant <stbryant= @cisco.com>,Adrian Farrel <adrian@olddog.co.uk>,David Sinicrope <david.sinicrope@ericsson.com>,christophe.alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat= @alcatel-lucent.com,rmers= h@broadband-forum.org,hongyu.li= @huawei.com,jmoisand@juniper.ne= t,gbingham@broadband-fo= rum.org,adrian@olddog.co.uk<= /span>
Response Contact:
Technical Contact:
Purpose: For information

Body:
Attachments:

   Broadband Forum Work on Flexible Service Chaining (= SD-326)
   https://datatracker.ietf.org/= documents/LIAISON/liaison-2014-02-13-broadband-forum-sfc-broadband-forum-wo= rk-on-flexible-service-chaining-sd-326-attachment-1.pdf

--_000_7A7AE3956DDC4F4687F7BF9447C824A7ericssoncom_-- From nobody Thu Feb 20 12:01:46 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1131A028A for ; Thu, 20 Feb 2014 12:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITAiqfQA8xMb for ; Thu, 20 Feb 2014 12:01:42 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CB49E1A0292 for ; Thu, 20 Feb 2014 12:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9929; q=dns/txt; s=iport; t=1392926489; x=1394136089; h=from:to:subject:date:message-id:mime-version; bh=YHm/suD39Gj4Li6vDa+S6qi56ErLOb2fJL50JNNDAT0=; b=JKTESrgiSfAgM1oM0Ld4UF2CmCmZhSZENbzvpjqRNNa+d0tqGPi80bMH lty2SPZ8Jp5k22+6UP0mOlzaTMgrInQAxJvOWicDqzy55xpDGLlipf1pZ LTt5p+ia+vWDUIqYALJbRwrBPbblwbQs8CwNZHoVvnvBu+5NGiVs0smTe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosGAFNeBlOtJXG8/2dsb2JhbABZgkJEOFeqU4xliAdPgREWdIIlAQICAoELAQgRAwECKDkUCQoEARKIBQ3OMReOEB0MGg0KAwSEMgSYMIEyiS6HRIFvgT6CKg X-IronPort-AV: E=Sophos;i="4.97,514,1389744000"; d="scan'208,217";a="305523344" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2014 20:01:28 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1KK1So5010803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 20:01:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 14:01:28 -0600 From: "Jim Guichard (jguichar)" To: David Sinicrope , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" Thread-Index: AQHPLnaKts/fkUTR8E6TqiSuphkEpw== Date: Thu, 20 Feb 2014 20:01:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.190] Content-Type: multipart/alternative; boundary="_000_CF2BC8C415CA4jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BlUD_vVjHeqmZMyBNbcHwHIm2dc Subject: Re: [sfc] Fwd: New Liaison Statement, "Broadband Forum Work on Flexible Service Chaining (SD-326)" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:01:45 -0000 --_000_CF2BC8C415CA4jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Thank you for bringing this to the WG=92s attention. We plan to have a shor= t discussion on how best to proceed during our upcoming meeting in London a= nd Hongyu Li will give a brief overview of the work. From: David Sinicrope > Date: Thursday, February 20, 2014 at 2:57 PM To: "sfc@ietf.org" > Subject: [sfc] Fwd: New Liaison Statement, "Broadband Forum Work on Flexibl= e Service Chaining (SD-326)" FYI David Sinicrope BBF/IETF Liaison Manager Begin forwarded message: From: Liaison Statement Management Tool > Date: February 13, 2014 at 15:52:21 EST To: Jim Guichard >, Thomas Na= rten > Cc: Stewart Bryant >, Adrian = Farrel >, David Sinicrope <= david.sinicrope@ericsson.com>, >, >, >, >, >, >, >, >, >, > Subject: New Liaison Statement, "Broadband Forum Work on Flexible Service C= haining (SD-326)" Title: Broadband Forum Work on Flexible Service Chaining (SD-326) Submission Date: 2014-02-13 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/ From: Broadband Forum (Christophe Alter >) To: Service Function Chaining (Jim Guichard >, Thomas Narten >) Cc: Stewart Bryant >,Adrian F= arrel >,David Sinicrope >,christophe= .alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat@alcatel-lucent.com,rmersh@broadband-forum.org,hongyu.li@huawei.com,jmoisand= @juniper.net,gbingham@broadband-forum.org,adrian@olddog.co.uk Response Contact: Technical Contact: Purpose: For information Body: Attachments: Broadband Forum Work on Flexible Service Chaining (SD-326) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-02-13-broadb= and-forum-sfc-broadband-forum-work-on-flexible-service-chaining-sd-326-atta= chment-1.pdf --_000_CF2BC8C415CA4jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <36EAE246B054EF4CBC075C69900A46C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi David,

Thank you for bringing this to the WG=92s attention. We plan to have a= short discussion on how best to proceed during our upcoming meeting in Lon= don and Hongyu Li will give a brief overview of the work. 

From: David Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Thursday, February 20, 2014 a= t 2:57 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Fwd: New Liaison Sta= tement, "Broadband Forum Work on Flexible Service Chaining (SD-326)&qu= ot;

FYI 
David Sinicrope
BBF/IETF Liaison Manager


Begin forwarded message:

From: Liaison Statement Management Tool <lsmt@ietf.org>
Date: February 13, 2014 at 15:52:21 EST
To: Jim Guichard <jguichar@= cisco.com>, Thomas Narten <n= arten@us.ibm.com>
Cc: Stewart Bryant <stbryan= t@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>, David Sinicrope <david.sinicrope@ericsson.com>, <christophe.alter@orange= .com>, <sudawood@cisco.com<= /a>>, <georgedob= rowski@mail01.huawei.com>, <michael.fargano@centurylink.com>, <Christele.bouc= hat@alcatel-lucent.com>, <rmersh@broadband-forum.org>, <hongyu.li@huawei.com>, <jmoisand@juniper.net>, <gbingham@broadband-for= um.org>, <adrian@olddog.co= .uk>
Subject: New Liaison Statement, "Broadband Forum Work on Fle= xible Service Chaining (SD-326)"

Title: Broadband Forum Work on Flexible Service Chaining (SD-326= )
Submission Date: 2014-02-13
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1304/

From: Broadband Forum (Christophe Alter <christophe.alter@orange-ftgroup.com>)<= /span>
To: Service Function Chaining (Jim Guichard <jguichar@cisco.com>, Thomas Narten <narten@us.ibm.com>)
Cc: Stewart Bryant <stbryant= @cisco.com>,Adrian Farrel <adrian@olddog.co.uk>,David Sinicrope <david.sinicrope@ericsson.com>,christophe.alter@orange.com,sudawood@cisco.com,georgedobrowski@mail01.huawei.com,michael.fargano@centurylink.com,Christele.bouchat= @alcatel-lucent.com,rmers= h@broadband-forum.org,hongyu.li= @huawei.com,jmoisand@juniper.ne= t,gbingham@broadband-fo= rum.org,adrian@olddog.co.uk<= /span>
Response Contact:
Technical Contact:
Purpose: For information

Body:
Attachments:

   Broadband Forum Work on Flexible Service Chaining (= SD-326)
   https://datatracker.ietf.org/= documents/LIAISON/liaison-2014-02-13-broadband-forum-sfc-broadband-forum-wo= rk-on-flexible-service-chaining-sd-326-attachment-1.pdf

 --_000_CF2BC8C415CA4jguicharciscocom_-- From nobody Thu Feb 20 18:44:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CDF1A01CD for ; Thu, 20 Feb 2014 18:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh9IQHNqDaTN for ; Thu, 20 Feb 2014 18:44:04 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB61A016A for ; Thu, 20 Feb 2014 18:44:04 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 9DF441255F4A for ; Fri, 21 Feb 2014 10:43:52 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7446E71FC8B; Fri, 21 Feb 2014 10:43:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s1L2hohx051325; Fri, 21 Feb 2014 10:43:50 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: chenycmx@gmail.com MIME-Version: 1.0 X-KeepSent: 9B640DA2:A3429159-48257C86:000A7DC1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Fri, 21 Feb 2014 10:43:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-21 10:43:30, Serialize complete at 2014-02-21 10:43:30 Content-Type: multipart/alternative; boundary="=_alternative 000F2E0E48257C86_=" X-MAIL: mse02.zte.com.cn s1L2hohx051325 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oBvE2mWdvaCTUzBRicXQ0-PS_as Cc: sfc@ietf.org Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 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, 21 Feb 2014 02:44:07 -0000 This is a multipart message in MIME format. --=_alternative 000F2E0E48257C86_= Content-Type: text/plain; charset="US-ASCII" Hi Yuchi, Thanks for your comments. IMO, classifier is a logical entity that can be located in some physical apparatuses, and that includes CPEs/BNASes. For IPv6 transition use cases, there might be some different types of technology, such as DS-Lite/LW 4o6/MAP... That brings a problem that several demonds might be made on CPEs. CPEs MUST support NAT/FIREWALL/SOFTWIRE. In this context, CPE might not be suited to implement all functions. In an actual deployment scenario, we can consider a cluster of CPEs with a same associated service node to implement the service functions. Thus, it will simplified the functionality of CPEs and let CPEs unified. I hope these can address your questions and doubts. Thanks, Wei From: "Yuchi Chen" To: meng.wei2 Cc: sfc Date: Thu, 20 Feb 2014 13:27:06 +0800 List-id: Network Service Chaining Hi Wei, I've read the draft. IMHO this draft provides a new point of view that SFC can be applied in the deployment of IPv6 transition mechanisms. Here is a question I have: what is the relationship between CPE/BNAS and the classifier? For now the classifier seems to be an individual device. If I understand this correctly, I think it might be trival to implement such various devices, as their specfications should quite depend on their actual locations in the network. Is it possible to let CPE/BNAS perform the service functions? Best regards! -------------------------------------------------------------------------------- Yuchi Chen --=_alternative 000F2E0E48257C86_= Content-Type: text/html; charset="US-ASCII"
Hi Yuchi,

  Thanks for your comments.

  IMO, classifier is a logical entity that can be located in some physical apparatuses,
and that includes CPEs/BNASes.

  For IPv6 transition use cases, there might be some different types of technology, such
as DS-Lite/LW 4o6/MAP...  That brings a problem that several demonds might be made on
CPEs. CPEs MUST support NAT/FIREWALL/SOFTWIRE.
  In this context, CPE might not be suited to implement all functions.

  In an actual deployment scenario, we can consider a cluster of CPEs with a same associated
service node to implement the service functions. Thus, it will simplified the functionality
of CPEs and let CPEs unified.
 
  I hope these can address your questions and doubts.


Thanks,
Wei




From: "Yuchi Chen" <chenycmx at gmail.com>
To: meng.wei2 <meng.wei2 at zte.com.cn>
Cc: sfc <sfc at ietf.org>
Date: Thu, 20 Feb 2014 13:27:06 +0800
List-id: Network Service Chaining <sfc.ietf.org>

Hi Wei,
 
I've read the draft. IMHO this draft provides a new point of view that SFC can be applied in the deployment of IPv6 transition mechanisms.
 
Here is a question I have:  what is the relationship between CPE/BNAS and the classifier? For now the classifier seems to be an individual device. If I understand this correctly, I think it might be trival to implement such various devices, as their specfications should quite depend on their actual locations in the network. Is it possible to let CPE/BNAS perform the service functions?
 
Best regards!

--------------------------------------------------------------------------------

Yuchi Chen --=_alternative 000F2E0E48257C86_=-- From nobody Thu Feb 20 23:32:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1E21A048E for ; Thu, 20 Feb 2014 23:32:28 -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 M2b95umTkwf1 for ; Thu, 20 Feb 2014 23:32:25 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2161A048C for ; Thu, 20 Feb 2014 23:32:25 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so3099975pbb.1 for ; Thu, 20 Feb 2014 23:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:mime-version:message-id :content-type; bh=eLETe+AF4C8YWP+sER4OfV8/5J/PFCRcnxv2xCjKOH8=; b=sM/bL9rK4zsnncU7s+DeZbrMTd0RrMmMm9bDdy0egyYMl9GhGCnPaUs3KmEd4o1cOG lKpenejouTEW26bnwLpe0VYWJyWGCVnG1via9vt5HbGaJrQg5u8Q/x8ZpeMhBrn702wc Sq1Os2SP5DQ5Ef0pOEY9ctzdUB9rHfQLeLRkwZLT1qOvahrrcblPbLYZuMoueK0zFmbT VzGfFhzfK8+KSgTyjCIdFtmW31SuY80d7JYeE0KTvmFTDS+CtZNcm2KsvDhdbzuG5OgF vxN/fL8gazvWx7hqUvAd/MMpoxgHyXl/3XiOJwAxdEhVaOybMrdzZtq14SPpLIvXFgxg 4PtQ== X-Received: by 10.66.65.134 with SMTP id x6mr7476399pas.12.1392967939185; Thu, 20 Feb 2014 23:32:19 -0800 (PST) Received: from netlab-PC ([166.111.68.231]) by mx.google.com with ESMTPSA id id1sm18347231pbc.11.2014.02.20.23.32.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 20 Feb 2014 23:32:18 -0800 (PST) Date: Fri, 21 Feb 2014 15:32:16 +0800 From: "Yuchi Chen" To: meng.wei2 References: X-Priority: 3 X-GUID: 75AB8761-9176-42AF-B897-EA2FA4769701 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201402211532119627297@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart742610054078_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rGEvJFUQ9OA7Shd3DJpSyXD3H8M Cc: sfc Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 07:32:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart742610054078_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2VpLA0KICAgICBZZXMsIHRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgdGhpbmsg eW91IG1lYW4gdGhhdCBzdWNoIGEgY2xhc3NpZmllciBpcyBub3QgcmVzcG9uc2libGUgZm9yIGZv cndhcmRpbmcgcGFja2V0cywgYnV0IG9ubHkgZm9yIHBhY2tldCBwcm9jZXNzaW5nLCBhbmQgb25j ZSB0aGUgcHJvY2VkdXJlIGlzIGRvbmUsIHRoZSBwYWNrZXQgd2lsbCBiZSByZXR1cm5lZCB0byB0 aGUgQ1BFL0JOQVMgZm9yIGZvcndhcmRpbmcuIElmIHRoaXMgaXMgdGhlIGNhc2UsIG15IHN1Z2dl c3Rpb24gaXMgdG8gY2xhcmlmeSB0aGlzIHBvaW50IHNvbWV3aGVyZSBpbiB0aGUgdGV4dCBpZiBw b3NzaWJsZS4NCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbg0KDQpGcm9tOiBtZW5n LndlaTINCkRhdGU6IDIwMTQtMDItMjEgMTA6NDMNClRvOiBjaGVueWNteA0KQ0M6IHNmYw0KU3Vi amVjdDogUmU6W3NmY10gQ29tbWVudHMgb24gZHJhZnQtbWVuZy1zZmMtYnJvYWRiYW5kLXVzZWNh c2VzLTAwDQoNCkhpIFl1Y2hpLCANCg0KICBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIA0KDQog IElNTywgY2xhc3NpZmllciBpcyBhIGxvZ2ljYWwgZW50aXR5IHRoYXQgY2FuIGJlIGxvY2F0ZWQg aW4gc29tZSBwaHlzaWNhbCBhcHBhcmF0dXNlcywgDQphbmQgdGhhdCBpbmNsdWRlcyBDUEVzL0JO QVNlcy4gDQoNCiAgRm9yIElQdjYgdHJhbnNpdGlvbiB1c2UgY2FzZXMsIHRoZXJlIG1pZ2h0IGJl IHNvbWUgZGlmZmVyZW50IHR5cGVzIG9mIHRlY2hub2xvZ3ksIHN1Y2ggDQphcyBEUy1MaXRlL0xX IDRvNi9NQVAuLi4gIFRoYXQgYnJpbmdzIGEgcHJvYmxlbSB0aGF0IHNldmVyYWwgZGVtb25kcyBt aWdodCBiZSBtYWRlIG9uIA0KQ1BFcy4gQ1BFcyBNVVNUIHN1cHBvcnQgTkFUL0ZJUkVXQUxML1NP RlRXSVJFLiANCiAgSW4gdGhpcyBjb250ZXh0LCBDUEUgbWlnaHQgbm90IGJlIHN1aXRlZCB0byBp bXBsZW1lbnQgYWxsIGZ1bmN0aW9ucy4gDQoNCiAgSW4gYW4gYWN0dWFsIGRlcGxveW1lbnQgc2Nl bmFyaW8sIHdlIGNhbiBjb25zaWRlciBhIGNsdXN0ZXIgb2YgQ1BFcyB3aXRoIGEgc2FtZSBhc3Nv Y2lhdGVkIA0Kc2VydmljZSBub2RlIHRvIGltcGxlbWVudCB0aGUgc2VydmljZSBmdW5jdGlvbnMu IFRodXMsIGl0IHdpbGwgc2ltcGxpZmllZCB0aGUgZnVuY3Rpb25hbGl0eSANCm9mIENQRXMgYW5k IGxldCBDUEVzIHVuaWZpZWQuIA0KICANCiAgSSBob3BlIHRoZXNlIGNhbiBhZGRyZXNzIHlvdXIg cXVlc3Rpb25zIGFuZCBkb3VidHMuIA0KDQoNClRoYW5rcywgDQpXZWkgDQoNCg0KDQoNCkZyb206 ICJZdWNoaSBDaGVuIiA8Y2hlbnljbXggYXQgZ21haWwuY29tPiANClRvOiBtZW5nLndlaTIgPG1l bmcud2VpMiBhdCB6dGUuY29tLmNuPiANCkNjOiBzZmMgPHNmYyBhdCBpZXRmLm9yZz4gDQpEYXRl OiBUaHUsIDIwIEZlYiAyMDE0IDEzOjI3OjA2ICswODAwIA0KTGlzdC1pZDogTmV0d29yayBTZXJ2 aWNlIENoYWluaW5nIDxzZmMuaWV0Zi5vcmc+IA0KDQpIaSBXZWksIA0KICANCkkndmUgcmVhZCB0 aGUgZHJhZnQuIElNSE8gdGhpcyBkcmFmdCBwcm92aWRlcyBhIG5ldyBwb2ludCBvZiB2aWV3IHRo YXQgU0ZDIGNhbiBiZSBhcHBsaWVkIGluIHRoZSBkZXBsb3ltZW50IG9mIElQdjYgdHJhbnNpdGlv biBtZWNoYW5pc21zLiANCiAgDQpIZXJlIGlzIGEgcXVlc3Rpb24gSSBoYXZlOiAgd2hhdCBpcyB0 aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQ1BFL0JOQVMgYW5kIHRoZSBjbGFzc2lmaWVyPyBGb3Ig bm93IHRoZSBjbGFzc2lmaWVyIHNlZW1zIHRvIGJlIGFuIGluZGl2aWR1YWwgZGV2aWNlLiBJZiBJ IHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIEkgdGhpbmsgaXQgbWlnaHQgYmUgdHJpdmFsIHRv IGltcGxlbWVudCBzdWNoIHZhcmlvdXMgZGV2aWNlcywgYXMgdGhlaXIgc3BlY2ZpY2F0aW9ucyBz aG91bGQgcXVpdGUgZGVwZW5kIG9uIHRoZWlyIGFjdHVhbCBsb2NhdGlvbnMgaW4gdGhlIG5ldHdv cmsuIElzIGl0IHBvc3NpYmxlIHRvIGxldCBDUEUvQk5BUyBwZXJmb3JtIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9ucz8gDQogIA0KQmVzdCByZWdhcmRzISANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g DQoNCll1Y2hpIENoZW4g ------=_001_NextPart742610054078_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Wei,
     Yes, thanks for the clarification. = ;I=20 think you mean that such a classifier is not responsible for forwarding pa= ckets,=20 but only for packet processing, and once the procedure is done, the packet= will=20 be returned to the CPE/BNAS for forwarding. If this is the case, my sugges= tion=20 is to clarify this point somewhere in the text if possible.
 
Best regards!
Yuc= hi=20 Chen
 
From: meng.wei2
Date: 2014-02-21 10:43
To: chenycmx
CC: sfc
Subject: Re:[sfc] Comments on=20 draft-meng-sfc-broadband-usecases-00

Hi=20 Yuchi,

  Thanks for y= our=20 comments.

  IMO, clas= sifier is=20 a logical entity that can be located in some physical apparatuses,=20
and that includes CPEs/BNASes.= =20

  For = IPv6=20 transition use cases, there might = be some=20 different types of technology, such
as=20 DS-Lite/LW 4o6/MAP...  That brings a problem that several demonds mig= ht be=20 made on
CPEs. CPEs MUST suppor= t=20 NAT/FIREWALL/SOFTWIRE.
  = In this=20 context, CPE might not be suited to implement all functions.=20

  In an actual deployment sc= enario, we=20 can consider a cluster of CPEs with a same associated
service node to implement the service functions. Thus, i= t will=20 simplified the functionality
o= f CPEs and=20 let CPEs unified.
 =20
  I hope these can addres= s your=20 questions and doubts.


Thanks,
Wei<= /FONT>=20




From: "Yuchi Chen" &l= t;chenycmx=20 at gmail.com>
To: meng.wei2= =20 <meng.wei2 at zte.com.cn>
Cc: sfc=20 <sfc at ietf.org>
Date: = Thu, 20=20 Feb 2014 13:27:06 +0800
List-i= d: Network=20 Service Chaining <sfc.ietf.org>

Hi Wei,
&nbs= p;=20
I've read the draft. IMHO this draft = provides a=20 new point of view that SFC can be applied in the deployment of IPv6 transi= tion=20 mechanisms.
 
= Here is a question I have:  what is the re= lationship=20 between CPE/BNAS and the classifier? For now the classifier seems to be an= =20 individual device. If I understand this correctly, I think it might be tri= val to=20 implement such various devices, as their specfications should quite depend= on=20 their actual locations in the network. Is it possible to let CPE/BNAS perf= orm=20 the service functions?
 <= /FONT>=20
Best regards!

--------------------------------------------------------= ------------------------=20

Yuchi Chen=20
------=_001_NextPart742610054078_=------ From nobody Fri Feb 21 06:39:20 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B271A02DF for ; Fri, 21 Feb 2014 06:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=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 LmUuXUC0wpHA for ; Fri, 21 Feb 2014 06:38:02 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3B0D1A02D0 for ; Fri, 21 Feb 2014 06:38:01 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gl10so554100lab.3 for ; Fri, 21 Feb 2014 06:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2c+Laot84rBRAVct5Yv8vR7yMbKIMZKXUt9vQnBJNKU=; b=wAPJ183ylIXlAwX9yXDhW7nkIE5ZJ+6lSLCFJ3fmCcnZ77M2zQaIGqN3oVYBmrPqfH n+IHUEIUWwubFF6X+6ZguC4MMp37Qdqmpi5DWeY7ra7sSFrt1K7ev2EkRhZDqDTWhzsu aYPpkQqU2OglEU0baIQj0kHeBK7BsFQjFYUVxNsdF0Sv22oJQXzGUPusfvT88ptAE7vp DkgPzyvhkMw5MiF/tf5yCygiJYMVneiiT0WIkaCeE/z2UMsEXn20bKHv+JG2VfO1ZNIf wiPDwKkTM39O+7b71c5iiNhq2Br7a2Jim0LIIQIsAeMN3iml8wFbwVub88xta9Q5hzeV cREQ== X-Received: by 10.112.73.100 with SMTP id k4mr4336732lbv.25.1392993477175; Fri, 21 Feb 2014 06:37:57 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:8003:27dc:298f:895f? ([2001:6e8:480:60:8003:27dc:298f:895f]) by mx.google.com with ESMTPSA id th3sm7880991lbb.11.2014.02.21.06.37.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 06:37:52 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 21 Feb 2014 16:37:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56FC5A27-F8D3-490B-866D-C536818A0D34@gmail.com> References: <20140128222615.27147.10919.idtracker@ietfa.amsl.com> <52E91413.6040808@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C7A106@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7EC01@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C7FB1F@dfweml701-chm.china.huawei.com> <3422a0ab800f4b858d0cbbfdd89723be@CO2PR05MB716.namprd05.prod.outlook.com> To: "Haeffner, Walter, Vodafone DE" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Q46yFHYXQLW5mgv3AiJRh49GmzQ X-Mailman-Approved-At: Fri, 21 Feb 2014 06:39:17 -0800 Cc: "sfc@ietf.org" , "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" , Linda Dunbar , Martin Stiemerling , "Jeffrey Napper \(jenapper\)" , Alla Goldner , "diego@tid.es" , Dave Dolson Subject: Re: [sfc] I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:38:07 -0000 Hi, While we are at this, correcting 3GPP details, few additional comments: The radio-based IP traffic between the UE and the eNB is encrypted according 3GPP standards. Between eNB, S-GW, P-GW user IP packets as Since control plane is referred below, I would add MME to the list. well as control plane packets are encapsulated in 3GPP-specific tunnels. In some mobile carrier networks the 3GPP specific tunnels Which control signalling is actually meant here that is both = 3GPP-specific tunnelled and between eNB & some other node? Do you mean control'ish = extension headers carried in GTP-U or something else? If S1-MME between eNB and MME is referred here that would be directly over SCTP (like X2 between eNBs). And whether GTP-C is actually "tunnelling" is debatable but lets not go there. between eNB and S-GW are even additionally IPSec-encrypted. For more Traffic is IPsec ESP encrypted between eNB and the Security Gateway, not SGW. details see [TS.29.281] and [TS.29.274]. A good reference for the security part would be NDS spec TS33.210. - JOuni On Feb 18, 2014, at 8:29 PM, "Haeffner, Walter, Vodafone DE" = wrote: > Hi Alla,=20 > Thanks for your support. We will correct the 3GPPP doc reference and = well, you are right, TDF came with Rel. 11 (as I remarked in an earlier = mail). > Regards,=20 > Walter =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Alla Goldner [mailto:agoldner@allot.com]=20 > Gesendet: Dienstag, 18. Februar 2014 19:23 > An: Jeffrey Napper (jenapper); Jerome Moisand; Linda Dunbar; Haeffner, = Walter, Vodafone DE; Dave Dolson; Martin Stiemerling; = draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org; = diego@tid.es > Betreff: RE: [sfc] Fwd: I-D Action: = draft-haeffner-sfc-use-case-mobility-00.txt >=20 > Hi, >=20 > Thanks a lot for this update! >=20 > There are two things which needs to be corrected: >=20 > 1. The related 3GPP specification should be TS 23.203 and not TS = 29.212 (29.212 is protocol level description only while TS 23.203 = defines general PCC architecture). >=20 > 2. The sentence "The Traffic Detection Function (TDF) [TS.29.212] is = currently under standardization within 3GPP." is not correct, as TDF was = standardized back in R11 of 3GPP and this is an existing entity for the = last couple of years thus should be described as a such. >=20 > Best regards, >=20 >=20 > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel = +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 = agoldner@allot.com www.allot.com >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com]=20 > Sent: Tuesday, February 18, 2014 8:16 PM > To: Jerome Moisand; Alla Goldner; Linda Dunbar; Haeffner, Walter, = Vodafone DE; Dave Dolson; Martin Stiemerling; = draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org; = diego@tid.es > Subject: Re: [sfc] Fwd: I-D Action: = draft-haeffner-sfc-use-case-mobility-00.txt >=20 > Hi guys, >=20 > Yes, we have submitted a revision that includes discussion of the TDF. >=20 > https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >=20 >=20 > The changes from the previous draft include a short comparison of = fixed networks that are similar to 3GPP, introduction of the TDF, = additional co-authors Martin and Diego, and some other tidying up. >=20 > I hope that the new text addresses your concerns. Please let us know = if there are still problems with the text. I think Walter will present = some slides over the draft in London. >=20 > Cheers, > Jeff >=20 > -----Original Message----- > From: Jerome Moisand > Date: Friday, February 14, 2014 at 4:28 PM > To: Alla Goldner , Linda Dunbar = , Jeffrey Napper , = "Haeffner, Walter, Vodafone DE" , Dave = Dolson , Martin Stiemerling , = "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" > , "sfc@ietf.org" > > Subject: RE: [sfc] Fwd: I-D > Action: draft-haeffner-sfc-use-case-mobility-00.txt >=20 >> Linda, >>=20 >> A PGW is a PCEF for sure (hence is more than a classifier). So this=20= >> part of your proposed drawing would have to be improved. >>=20 >> Now in the TDF case, a better drawing would show PGW(PCEF) and=20 >> TDF(PCEF) in sequence. As this is the reality of things, a TDF does = not=20 >> replace a PGW, it (optionally) complements it. >>=20 >> Anyhoo, I feel we're going a bit in circles here. Why not letting the=20= >> authors of this draft (who obviously know the 3GPP constructs very=20 >> well) improve it as they see fit based on the feedback? >>=20 >> Tx >> Jerome >>=20 >> -----Original Message----- >> From: Alla Goldner [mailto:agoldner@allot.com] >> Sent: Friday, February 14, 2014 1:43 AM >> To: Linda Dunbar; Jerome Moisand; Jeffrey Napper (jenapper); = Haeffner,=20 >> Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Dear Linda, all, >>=20 >> I think this presentation is more correct, thank you. >>=20 >> One thing though may need to be corrected: PCEF is an integral part = of=20 >> PGW as defined by 3GPP standards. Therefore, we may, as an option,=20 >> mention "PCEF/TDF" without "PGW", and then put a note that PCEF = resides=20 >> in PGW. >>=20 >> Best regards, >>=20 >>=20 >> Alla Goldner >> Director of Mobile Technologies and Standards Allot Communications = Tel >> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >> +agoldner@allot.com >> www.allot.com >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Friday, February 14, 2014 1:17 AM >> To: Jerome Moisand; Alla Goldner; Jeffrey Napper (jenapper); = Haeffner,=20 >> Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Alla, Jerome, >>=20 >> Since 3GPP has defined many components and are still involving, can = we=20 >> use a simplified box to represent an entity associated with P-GW that=20= >> classifies the traffic based on PCRF rules, TDF, and/or PCEF? Such = as: >>=20 >>=20 >> | Mobile backhaul Network >> +-----+ | +---+---+ >> |PCRF/| | |Network| >> |rules| < ---- > |Ctrller| >> +-----+ | +----+--+ >> | | >> V | >> +---------+ | +--------+ +----+ +---------+ >> -- >| P-GW | --> |LB |---| FW |--> | Web | ------> >> | | | | | | | | Proxy | >> --->| & or | | +--------+ +----+ +---------+ >> --->| | | +---------+ +----+ >> -- >| | --> |Video |---| FW |--> ----------- ------> >> |TDF/PCEF | | |Optimizer| | | >> | | | +---------+ +----+ >> --->| | | +--------+ +-----+ >> -- >| | --> |SBC |---| ACL |--> ----------- ------> >> | | | | | | | >> +---------+ | +--------+ +-----+ >>=20 >> Figure 1 Service Chain for Mobile Network >>=20 >>=20 >> As for the description of metadata used by Gi-LAN service function, = we=20 >> don't have to specifically say which elements defined by 3GPP encoded=20= >> them in. >>=20 >>=20 >> Linda >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Thursday, February 13, 2014 10:30 AM >> To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20= >> Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> I don't know if the whole PCC architecture is truly optional in 3GPP=20= >> theory (I've never seen it expressed that way, but I'll take your = word=20 >> for it), but one would be hard-pressed to find a 3G/LTE mobile=20 >> broadband network without it. So in practice my 100% statement = remains=20 >> true (I'll give you 99.9% if you wish!). >>=20 >> So I have a bit of an issue putting PGW and TDF at the same level. = This=20 >> simply doesn't reflect any reality, nor the spirit of the 3GPP specs. >>=20 >> And in the fixed-broadband world in BBF terms, yeah, the BNG IS=20 >> mandatory (I took a very active role in several of those specs, e.g.=20= >> TR-101). While a DPI function is truly optional (and not that many=20 >> subscribers in absolute % go through it in practice) and not = standardized. >>=20 >> Anyway, I agree with you that mobile use cases with or without TDF=20 >> should be considered. A case without PGW would seem much more dubious=20= >> to me. We may be saying more or the same thing, overall. >>=20 >> -----Original Message----- >> From: Alla Goldner [mailto:agoldner@allot.com] >> Sent: Thursday, February 13, 2014 11:15 AM >> To: Jerome Moisand; Linda Dunbar; Jeffrey Napper (jenapper); = Haeffner,=20 >> Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Dear Jerome, >>=20 >> Yes, TDF is an optional element in mobile networks. As a such, Sd=20 >> interface is also optional. However, the GGSN/PGW-PCRF (Gx) interface=20= >> is optional in exactly the same way. The whole 3GPP PCC architecture = is=20 >> optional. Therefore, the claim about 100% of mobile data subscribers=20= >> may not be fully correct. And with regards to the features required = for=20 >> service classification and service enforcement that you describe = below=20 >> - they are present at both GGSN/PGW and TDF. >>=20 >> The bottom line is that use cases where PGW is considered as = classifier=20 >> OF COURSE should be considered, same as use cases where TDF is=20 >> considered as a classifier. And, once describing those use cases, the=20= >> existing 3GPP architecture should be assumed. >>=20 >> Best regards, >>=20 >>=20 >> Alla Goldner >> Director of Mobile Technologies and Standards Allot Communications = Tel >> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >> +agoldner@allot.com >> www.allot.com >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Thursday, February 13, 2014 5:27 PM >> To: Alla Goldner; Linda Dunbar; Jeffrey Napper (jenapper); Haeffner,=20= >> Walter, Vodafone DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Alla & folks, >>=20 >> Well... I don't know... Getting deep in network architectures and the=20= >> role of the various network elements is indeed crucial. Both 3GPP and=20= >> BBF (Broadband Forum) did a lot of work in the past decade to define=20= >> architecture & nodal requirements, which shaped in turn the = deployment=20 >> of all major Service Providers worldwide. So quite clearly, service=20= >> chaining have to build on that and find a good way to insert itself=20= >> into such architectures while extending them. >>=20 >> Back to Linda's point, for sure, the GGSN/PGW is a powerful candidate=20= >> for service classification/enforcement, as it... already does it for=20= >> its own purpose! This is BY NATURE a highly scalable subscriber &=20 >> service management system, classifying and enforcing policies = (usually=20 >> L3, occasionally higher), and fully integrated with the HSS/PCRF = chain=20 >> which holds the subscriber/service authentication & authorization = data.=20 >> As such, service classification *and* service enforcement (and = service >> accounting) is already there. For 100% of the mobile (data) = subscribers. >> Sure enough, a TDF system may also do its own form of service=20 >> classification (and processing too), but let's not forget this is an=20= >> OPTIONAL system on the data path on the recently defined 3GPP=20 >> architectures you referred to. For many use cases, there is just no=20= >> point going through a DPI function. While for other use cases, there = is=20 >> clearly such a point, but only when it brings clear value for a given=20= >> service construct, only applicable to corresponding subscribers. >>=20 >> In the same vein, in fixed-broadband architectures, a BNG is the=20 >> primary subscriber management system on the data path, fully = integrated=20 >> with a AAA system, and already doing service classification *and*=20 >> service processing at scale for 100% of the subscribers. Any=20 >> classification/enforcement system behind it is optional and only=20 >> applicable to a subset of services & subscribers. >>=20 >> Bottomline: sure, use cases with TDF should be described, but=20 >> PGW-centric use cases remain the rule, not the exception. And=20 >> double-clicking on existing standardized network architectures (e.g.=20= >> 3GPP and BBF) and related deployments is crucial for our SFC = endeavor. >>=20 >> Jerome Moisand. >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Alla Goldner >> Sent: Thursday, February 13, 2014 1:18 AM >> To: Linda Dunbar; Jeffrey Napper (jenapper); Haeffner, Walter, = Vodafone=20 >> DE; Dave Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Deal Linda, >>=20 >> The 3GPP architecture picture described below is not accurate. >> Starting from R11, PCRF interacts also with TDF (Traffic Detection >> Function) for providing ADC (Application Detection and Control) Rules=20= >> for application detection, enforcement and also charging starting = from R12. >> Please see architecture diagram for your reference in the 3GPP TS = 23.203. >>=20 >> Therefore, we can't assume that "Since PCRF usually only interfaces=20= >> with the GGSN (via Diameter), not the service functions, do you mean=20= >> "for the GGSN (or the flow classifier) to carry the data passed down=20= >> from PCRF to packets' metadata field to service functions on the = chain"?" >>=20 >> Furthermore, also the claim that >> "The P-GW/PCEF (per 3GPP terminology) determines the desired service=20= >> treatment, i.e. desired sequence of service functions, to specific=20 >> flows based on the policies from PCRF. >> The P-GW in the figure acts as the Service Chain Classification Node. >> P-GW separates the traffic into different categories (or flows) based=20= >> on the policies from PCRF. The traffic in each category (or flow) is=20= >> mapped to a unique interface (a physical or virtual port) or a tunnel=20= >> that is connected to the needed sequence of service functions." is = not=20 >> correct as well as PGW/PCEF is not the only element which enforces=20 >> different support per different flows based on policies received from = PCRF, but also TDF! >>=20 >> My general feeling is that we are getting here deeply into 3GPP=20 >> architecture and make assumptions and conclusions about potential = 3GPP=20 >> elements functionality which are not in scope of IETF. If we want to=20= >> define use cases for 3GPP networks, then we should show correct=20 >> picture of 3GPP architecture without redesigning it and leave 3GPP=20 >> Network Elements functionality potential extensions to 3GPP. >>=20 >> Best regards, >>=20 >> Alla Goldner >> Director of Mobile Technologies and Standards Allot Communications = Tel >> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626=20 >> +agoldner@allot.com >> www.allot.com >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Thursday, February 13, 2014 12:13 AM >> To: Jeffrey Napper (jenapper); Haeffner, Walter, Vodafone DE; Dave=20 >> Dolson; Martin Stiemerling;=20 >> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Jeffrey and Walter, >>=20 >> Here are some suggestions to your draft: >>=20 >> Section 2.2:=20 >> - your draft states "The Gi-LAN service functions may use subscriber=20= >> and service related metadata delivered from mobile control plane=20 >> function like PCRF to process the flows according to service related = policies" >>=20 >> Since PCRF usually only interfaces with the GGSN (via Diameter), not=20= >> the service functions, do you mean "for the GGSN (or the flow=20 >> classifier) to carry the data passed down from PCRF to packets'=20 >> metadata field to service functions on the chain"? >> Since the policies passed down by PCRF usually can't be understood by=20= >> service functions, I suggest changing to the following text: >>=20 >> "The (S)Gi-LAN service functions may use subscriber and service = related=20 >> information, that are either embedded in packets as metadata or = passed=20 >> down from control plane, to process the flows according to service=20= >> related policies" >>=20 >>=20 >> Section 2.3 The most common classification scheme >>=20 >> I think this section is very confusing. How is "APN for P-GW IP = address" >> used in traffic classification? >>=20 >> Are you saying that traffic are grouped to specific P-GW? And each = APN=20 >> has a VLAN-ID? >>=20 >> I understand that some common classification scheme could be encoding = a=20 >> certain QoS to a specific flow, applying some security functions to=20= >> some flows, etc. The classification node can use simple VLAN-ID to = mark=20 >> different classification. >>=20 >> P-GW is the ingress node to the Gi-LAN Service Chain, isn't it? >>=20 >> I think the Wireless Service Chain example given by Walter at Berlin=20= >> SFC BOF is very good. >>=20 >> Walter's wireless example is described in the Section 3.2 of=20 >> = https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-ar >> chi >> tecture/ >>=20 >> Maybe you can use the text to replace your Section 2.3? Here is the=20= >> suggested text: >> ----------------- >> The P-GW/PCEF (per 3GPP terminology) determines the desired service=20= >> treatment, i.e. desired sequence of service functions, to specific=20 >> flows based on the policies from PCRF. >> The P-GW in the figure acts as the Service Chain Classification Node. >> P-GW separates the traffic into different categories (or flows) based=20= >> on the policies from PCRF. The traffic in each category (or flow) is=20= >> mapped to a unique interface (a physical or virtual port) or a tunnel=20= >> that is connected to the needed sequence of service functions. >>=20 >> | Mobile backhaul Network >> +-----+ | +---+---+ >> |PCRF | | |Network| >> | | < ---- > |Ctrller| >> +-----+ | +----+--+ >> | | >> | | >> +---------+ | +--------+ +----+ +---------+ >> -- >| P-GW | --> |LB |---| FW |--> | Web | ------> >> | | | | | | | | Proxy | >> --->| | | +--------+ +----+ +---------+ >> --->| | | +---------+ +----+ >> -- >| | --> |Video |---| FW |--> ----------- ------> >> | [PCEF]| | |Optimizer| | | >> | | | +---------+ +----+ >> --->| | | +--------+ +-----+ >> -- >| | --> |SBC |---| ACL |--> ----------- ------> >> | | | | | | | >> +---------+ | +--------+ +-----+ >>=20 >> Figure 1 Service Chain for Mobile Network >>=20 >> Linda >>=20 >> -----Original Message----- >> From: Jeffrey Napper (jenapper) [mailto:jenapper@cisco.com] >> Sent: Sunday, February 09, 2014 1:44 PM >> To: Linda Dunbar; Haeffner, Walter, Vodafone DE; Dave Dolson; Martin=20= >> Stiemerling; draft-haeffner-sfc-use-case-mobility@tools.ietf.org; >> sfc@ietf.org >> Subject: Re: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >> Hi Linda, >>=20 >> First, thanks for the feedback. While it may look like a lot of=20 >> components, we still have simplified 3GPP quite a lot. For example, = in=20 >> the first draft we left out the TDF that appears in recent standards. >> We=B9ll be adding that in response to other comments. I believe the=20= >> overview section is still quite short, but we will try to shorten it = a=20 >> bit further if it is too long. If you feel anything in particular is=20= >> missing or extraneous, please let us know. >>=20 >> Yes, it is probably overkill to have two example APNs. The User & = Pass=20 >> are important for example in cases of hot-lining where the user must=20= >> first be authenticated (for various reasons) before data services are=20= >> provided/continued. It is just another example of the important=20 >> relationship between Classification (in an SFC sense) and Policy and=20= >> Charging (in a 3GPP sense). >>=20 >> Cheers, >> Jeff >>=20 >> -----Original Message----- >> From: Linda Dunbar >> Date: Friday, February 7, 2014 at 11:14 PM >> To: "Haeffner, Walter, Vodafone DE" ,=20= >> Dave Dolson , Martin Stiemerling=20 >> , = "draft-haeffner-sfc-use-case-mobility@tools.ietf.org" >> , "sfc@ietf.org" >> >> Cc: Jeffrey Napper >> Subject: RE: [sfc] Fwd: I-D Action: >> draft-haeffner-sfc-use-case-mobility-00.txt >>=20 >>> Walter, et al, >>>=20 >>> While it is interesting to show all the components of 3GPP for = GiLAN,=20 >>> but I don't think it is necessary to have all of them in the SFC use=20= >>> case draft. >>>=20 >>> For example, on your Section 2.3 ("The Most common classification=20 >>> scheme"), it is very confusing to have the Table 1 & Table 2 listing=20= >>> "User name & Password". Does it mean that the "User Name & Password" >>> have to associated with data packets? Or to be detected by the=20 >>> Classification nodes? >>>=20 >>> Linda >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Haeffner, = Walter,=20 >>> Vodafone DE >>> Sent: Wednesday, February 05, 2014 7:21 PM >>> To: Dave Dolson; Martin Stiemerling; >>> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>> Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com) >>> Subject: Re: [sfc] Fwd: I-D Action: >>> draft-haeffner-sfc-use-case-mobility-00.txt >>>=20 >>> Hi Dave, >>> Thanks for your comment. We are going to include a Rel.11 TDF=20 >>> paragraph in -01. Possibly we will consider 2 sections: most simple=20= >>> case (with APN), actual most advanced case (with TDF). >>> Regards, >>> Walter >>>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Dave Dolson >>> Gesendet: Dienstag, 4. Februar 2014 20:23 >>> An: Martin Stiemerling; >>> draft-haeffner-sfc-use-case-mobility@tools.ietf.org; sfc@ietf.org >>> Betreff: Re: [sfc] Fwd: I-D Action: >>> draft-haeffner-sfc-use-case-mobility-00.txt >>>=20 >>> Although draft-haeffner-sfc-use-case-mobility-00 describes one=20 >>> arrangement of mobility architecture, it neglects to show the role = of=20 >>> the Traffic Detection Function (TDF), also described in the cited = 3GPP=20 >>> TS >>> 23.203 (Version 12). >>>=20 >>> I don't want to argue with the use cases, just the implied network=20= >>> architecture. >>>=20 >>> In all of the network diagrams and examples, it should be understood=20= >>> that the P-GW is not the only location from which a policy-based=20 >>> service chain could be initiated; the standard TDF function can also=20= >>> initiate service chains selected by policy and traffic type. >>>=20 >>> Section 2.1 should show an optional TDF element between the P-GW and=20= >>> the (S)Gi-LAN. >>>=20 >>> A TDF communicates with a PCRF using the Sd interface, from which it=20= >>> receives Application Detection and Control (ADC) rules, similar to = the=20 >>> rules deployed to the P-GW via the Gx interface. >>>=20 >>> Aside from the APN classification scheme mentioned in section 2.3 of=20= >>> the draft, ADC rules can cause decisions based on application type=20= >>> (not just based on APN or UDP/TCP port classification). >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Martin=20 >>> Stiemerling >>> Sent: Wednesday, January 29, 2014 9:46 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Fwd: I-D Action: >>> draft-haeffner-sfc-use-case-mobility-00.txt >>>=20 >>> Hi all, >>>=20 >>> I wanted to raise your attention to the below quoted draft, as it=20 >>> wasn't posted to the SFC list. >>>=20 >>> The draft outlines very well the use cases in mobile networks. >>>=20 >>> Thanks, >>>=20 >>> Martin >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: I-D Action: draft-haeffner-sfc-use-case-mobility-00.txt >>> Date: Tue, 28 Jan 2014 14:26:15 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20= >>> directories. >>>=20 >>>=20 >>> Title : Service Function Chaining Use Cases in = Mobile >>> Networks >>> Authors : Walter Haeffner >>> Jeffrey Napper >>> Filename : draft-haeffner-sfc-use-case-mobility-00.txt >>> Pages : 17 >>> Date : 2014-01-28 >>>=20 >>> 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 and framework = statements >>> of the working group. >>>=20 >>> 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 ensure a fair distribution of network >>> resources according to agreed service policies, enhance the >>> performance of service delivery, take care of security and privacy = or >>> support application and business support platforms. 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. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-haeffner-sfc-use-case-mobility-00 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at=20 >>> tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> = ####################################################################### >> ### >> #################### >> This message is intended only for the designated recipient(s).It may=20= >> contain confidential or proprietary information. >> If you are not the designated recipient, you may not review, copy or=20= >> distribute this message. >> If you have mistakenly received this message, please notify the = sender=20 >> by a reply e-mail and delete this message. >> Thank you. >> = ####################################################################### >> ### >> #################### >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >>=20 >>=20 >> = ####################################################################### >> ### >> #################### >> This message is intended only for the designated recipient(s).It may=20= >> contain confidential or proprietary information. >> If you are not the designated recipient, you may not review, copy or=20= >> distribute this message. >> If you have mistakenly received this message, please notify the = sender=20 >> by a reply e-mail and delete this message. >> Thank you. >> = ####################################################################### >> ### >> #################### >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> = ####################################################################### >> ### >> #################### >> This message is intended only for the designated recipient(s).It may=20= >> contain confidential or proprietary information. >> If you are not the designated recipient, you may not review, copy or=20= >> distribute this message. >> If you have mistakenly received this message, please notify the = sender=20 >> by a reply e-mail and delete this message. >> Thank you. >> = ####################################################################### >> ### >> #################### >>=20 >>=20 >>=20 >=20 > = ##########################################################################= #################### > This message is intended only for the designated recipient(s).It may = contain confidential or proprietary information. > If you are not the designated recipient, you may not review, copy or = distribute this message. > If you have mistakenly received this message, please notify the sender = by a reply e-mail and delete this message.=20 > Thank you. > = ##########################################################################= #################### >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 21 10:31:33 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC941A01ED for ; Fri, 21 Feb 2014 10:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRZjrI1nMMDR for ; Fri, 21 Feb 2014 10:31:29 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id CC66E1A0545 for ; Fri, 21 Feb 2014 10:31:22 -0800 (PST) Received: from mail17-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Feb 2014 18:31:18 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id 5E3F03403BA; Fri, 21 Feb 2014 18:31:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I936eIc85fh4015I1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL6d524h17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail17-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(164054003)(51914003)(189002)(199002)(377424004)(377454003)(83072002)(19300405004)(51856001)(15975445006)(81342001)(15202345003)(66066001)(74706001)(76796001)(74316001)(77982001)(94946001)(76786001)(19580405001)(74366001)(85852003)(81542001)(81816001)(74876001)(76576001)(54356001)(53806001)(56776001)(81686001)(94316002)(76482001)(46102001)(74662001)(80022001)(59766001)(31966008)(65816001)(56816005)(80976001)(19580395003)(87936001)(49866001)(18717965001)(83322001)(47446002)(63696002)(92566001)(93136001)(93516002)(69226001)(16236675002)(47736001)(33646001)(74502001)(50986001)(54316002)(90146001)(95416001)(4396001)(86362001)(79102001)(85306002)(47976001)(2656002)(87266001)(95666003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.239.11; FPR:DCEFFFF5.A492DF23.73E3357F.4AE5D27D.2049C; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 139300747633843_22892; Fri, 21 Feb 2014 18:31:16 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.236]) by mail17-am1.bigfish.com (Postfix) with ESMTP id 03E61600B6; Fri, 21 Feb 2014 18:31:16 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Feb 2014 18:31:15 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 21 Feb 2014 18:31:12 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 21 Feb 2014 18:31:11 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0878.008; Fri, 21 Feb 2014 18:31:10 +0000 From: Jerome Moisand To: chenycmx , meng.wei2 Thread-Topic: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 Thread-Index: AQHPLq7SGGQDWsovfEiGgH6SROmvupq/UOEMgAC1sXA= Date: Fri, 21 Feb 2014 18:31:10 +0000 Message-ID: References: <201402211532119627297@gmail.com> In-Reply-To: <201402211532119627297@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 01294F875B Content-Type: multipart/alternative; boundary="_000_df856d71e52f4d3eadeeb30e829c6143CO2PR05MB716namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/39v3w-wW5nLOjCDlBtU9EIy8qRY Cc: sfc Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 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, 21 Feb 2014 18:31:33 -0000 --_000_df856d71e52f4d3eadeeb30e829c6143CO2PR05MB716namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The Broadband Forum (BBF) just issued a liaison to IETF, providing a snapsh= ot of its activities on Service Chaining, and notably... (fixed) broadband = use cases! This is a work in progress, it takes time to identify scenarios = with proper level of support (notably from service providers), but we're ma= king progress. Broadband Forum Work on Flexible Service Chaining (SD-326) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-02-13-broadb= and-forum-sfc-broadband-forum-work-on-flexible-service-chaining-sd-326-atta= chment-1.pdf Somehow we need to consolidate those efforts. I am not entirely sure it mak= es sense to have two parallel initiatives between IETF and BBF in this resp= ect, two documents to maintain, etc. Hopefully, the point will be discussed= in London. As a side note, the next BBF meeting is scheduled the week after IETF (star= ting March 3rd, in Malta). Contributions to SD-326 would be very welcome. Cheers, Jerome (BBF SD-326 co-editor) PS. I believe there is a similar point to be made about 3GPP and its new "S= ervice Steering" activity in SA1. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Yuchi Chen Sent: Friday, February 21, 2014 2:32 AM To: meng.wei2 Cc: sfc Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 Hi Wei, Yes, thanks for the clarification. I think you mean that such a classi= fier is not responsible for forwarding packets, but only for packet process= ing, and once the procedure is done, the packet will be returned to the CPE= /BNAS for forwarding. If this is the case, my suggestion is to clarify this= point somewhere in the text if possible. Best regards! ________________________________ Yuchi Chen From: meng.wei2 Date: 2014-02-21 10:43 To: chenycmx CC: sfc Subject: Re:[sfc] Comments on draft-meng-sfc-broadband-usecases-00 Hi Yuchi, Thanks for your comments. IMO, classifier is a logical entity that can be located in some physical = apparatuses, and that includes CPEs/BNASes. For IPv6 transition use cases, there might be some different types of tec= hnology, such as DS-Lite/LW 4o6/MAP... That brings a problem that several demonds might = be made on CPEs. CPEs MUST support NAT/FIREWALL/SOFTWIRE. In this context, CPE might not be suited to implement all functions. In an actual deployment scenario, we can consider a cluster of CPEs with = a same associated service node to implement the service functions. Thus, it will simplified t= he functionality of CPEs and let CPEs unified. I hope these can address your questions and doubts. Thanks, Wei From: "Yuchi Chen" To: meng.wei2 Cc: sfc Date: Thu, 20 Feb 2014 13:27:06 +0800 List-id: Network Service Chaining Hi Wei, I've read the draft. IMHO this draft provides a new point of view that SFC = can be applied in the deployment of IPv6 transition mechanisms. Here is a question I have: what is the relationship between CPE/BNAS and t= he classifier? For now the classifier seems to be an individual device. If = I understand this correctly, I think it might be trival to implement such v= arious devices, as their specfications should quite depend on their actual = locations in the network. Is it possible to let CPE/BNAS perform the servic= e functions? Best regards! ---------------------------------------------------------------------------= ----- Yuchi Chen --_000_df856d71e52f4d3eadeeb30e829c6143CO2PR05MB716namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,<= /p>

The Broadband Forum (BBF)= just issued a liaison to IETF, providing a snapshot of its activities on S= ervice Chaining, and notably… (fixed) broadband use cases! This is a work in progress, it takes time to identify scenarios with prope= r level of support (notably from service providers), but we’re making= progress.

Broadband Forum Work on Fle= xible Service Chaining (SD-326)
   https://datatracker.ietf.org/docume= nts/LIAISON/liaison-2014-02-13-broadband-forum-sfc-broadband-forum-work-on-= flexible-service-chaining-sd-326-attachment-1.pdf

Somehow we need to consol= idate those efforts. I am not entirely sure it makes sense to have two para= llel initiatives between IETF and BBF in this respect, two documents to maintain, etc. Hopefully, the point will be discussed in Lond= on.

As a side note, the next = BBF meeting is scheduled the week after IETF (starting March 3rd= , in Malta). Contributions to SD-326 would be very welcome.

Cheers, Jerome  = ; (BBF SD-326 co-editor)

PS. I believe there is a = similar point to be made about 3GPP and its new “Service SteeringR= 21; activity in SA1.

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Yuchi Chen
Sent: Friday, February 21, 2014 2:32 AM
To: meng.wei2
Cc: sfc
Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00<= o:p>

 

Hi Wei,

     Yes, thanks for the cl= arification. I think you mean that such a classifier is not responsibl= e for forwarding packets, but only for packet processing, and once the procedure is done, t= he packet will be returned to the CPE/BNAS for forwarding. If this is the c= ase, my suggestion is to clarify this point somewhere in the text if p= ossible.

 

Best regards!

Yuchi Chen

 

From: meng.wei2

Date: 2014-02-21 10:43

To: chenycmx

CC: sfc

Subject: Re:[sfc] Comments on draft-meng-sfc-broadband-usecases-00<= o:p>


Hi Yuchi,

  Thanks for your comments.

  IMO, classifier is a logical entity th= at can be located in some physical apparatuses,
and that includes CPEs/BNASes.

  For IPv6 transition use cases, there might be some different types of technology, = such
as DS-Lite/LW 4o6/MAP...  That brings a = problem that several demonds might be made on
CPEs. CPEs MUST support NAT/FIREWALL/SOFTWIRE= .
  In this context, CPE might not be suit= ed to implement all functions.

  In an actual deployment scenario, we c= an consider a cluster of CPEs with a same associated
service node to implement the service functio= ns. Thus, it will simplified the functionality
of CPEs and let CPEs unified.
 
  I hope these can address your question= s and doubts.


Thanks,Wei




From: "Yuchi Chen" <chenycmx at = gmail.com>
To: meng.wei2 <meng.wei2 at zte.com.cn>
Cc: sfc <sfc at ietf.org>
Date: Thu, 20 Feb 2014 13:27:06 +0800
List-id: Network Service Chaining <sfc.iet= f.org>

Hi Wei, 
I've read the draft. IMHO this draft provides= a new point of view that SFC can be applied in the deployment of IPv6 tran= sition mechanisms.
 
Here is a question I have:  what is the = relationship between CPE/BNAS and the classifier? For now the classifier se= ems to be an individual device. If I understand this correctly, I think it might be trival to implement such various devices, as their spe= cfications should quite depend on their actual locations in the network. Is= it possible to let CPE/BNAS perform the service functions?
 
Best regards!

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

Yuchi Chen

--_000_df856d71e52f4d3eadeeb30e829c6143CO2PR05MB716namprd05pro_-- From nobody Fri Feb 21 16:04:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220801A02EF for ; Fri, 21 Feb 2014 16:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 d5ht_G0JDh9Y for ; Fri, 21 Feb 2014 16:03:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF8F81A02F5 for ; Fri, 21 Feb 2014 16:03:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBJ46588; Sat, 22 Feb 2014 00:03:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 00:03:29 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 00:03:45 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.21]) by dfweml702-chm.china.huawei.com ([169.254.4.231]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:03:39 -0800 From: Lucy yong To: "Paul Quinn (paulq)" , "andre.beliveau@ericsson.com" Thread-Topic: comments on sfc-arch-04 Thread-Index: Ac8vYYEESz2vV8pzQuahhxFqQJ2pag== Date: Sat, 22 Feb 2014 00:03:38 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453337C5@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.70] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453337C5dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/q_AmJ2ApA2rvTvTBXoGMH-4qBQU Cc: "sfc@ietf.org" Subject: [sfc] comments on sfc-arch-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 00:03:59 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453337C5dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, et al, I have some concerns on the service function chaining architecture illustra= ted in Figure 3. The numbered circle notation is used in figure 1 where it represents a SF n= ode in a SF graph. Figure 1 gives very abstract view of SFC without any assumption how it is b= e realized. Figure 3 is the reference architecture for service function chaining. It is= important for it to illustrate the key functional components and their rel= ationship. Section 3.2 describes fundamental components in SFC, but they a= re not shown in the figure 3 at all, and I don't see we can simply replace = each numbered circle in figure 3 with the draw in figure 2. One clarification question for SF, SFF, and SNF in figure 2: what is cardin= ality in between? Can one SNF have one or more SFFs? can one SFF have one o= r more SFs? I can't tell from their description and think that is important= for the architecture as well. Do we have one control plane to work with SF, SFF, SNF components or more t= han one? IMO: it is important to clarify them in the arch doc. Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D453337C5dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul, et al,

 

I have some concerns on the service function chainin= g architecture illustrated in Figure 3.

 

The numbered circle notation is used in figure 1 whe= re it represents a SF node in a SF graph.

Figure 1 gives very abstract view of SFC without any= assumption how it is be realized.

 

Figure 3 is the reference architecture for service f= unction chaining. It is important for it to illustrate the key functional c= omponents and their relationship.  Section 3.2 describes fundamental c= omponents in SFC, but they are not shown in the figure 3 at all, and I don’t see we can simply replace each n= umbered circle in figure 3 with the draw in figure 2.  

 

One clarification question for SF, SFF, and SNF in f= igure 2: what is cardinality in between? Can one SNF have one or more SFFs?= can one SFF have one or more SFs? I can’t tell from their descriptio= n and think that is important for the architecture as well.

 

Do we have one control plane to work with SF, SFF, S= NF components or more than one? IMO: it is important to clarify them in the= arch doc.

 

Regards,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D453337C5dfweml701chmchi_-- From nobody Fri Feb 21 23:38:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8941A03C6 for ; Fri, 21 Feb 2014 23:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIsBQ3iAL64R for ; Fri, 21 Feb 2014 23:37:57 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E41C11A03C1 for ; Fri, 21 Feb 2014 23:37:56 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D3B2E12694EC; Sat, 22 Feb 2014 15:37:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s1M7bgIY001681; Sat, 22 Feb 2014 15:37:42 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: chenycmx@gmail.com MIME-Version: 1.0 X-KeepSent: F63B5DD3:E669BE6C-48257C87:00251A1B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Sat, 22 Feb 2014 15:37:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-22 15:37:20, Serialize complete at 2014-02-22 15:37:20 Content-Type: multipart/alternative; boundary="=_alternative 002A0FBF48257C87_=" X-MAIL: mse01.zte.com.cn s1M7bgIY001681 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/seDwZYvzsPWOduxOserpeX5wySE Cc: sfc@ietf.org Subject: Re: [sfc] Comments on draft-meng-sfc-broadband-usecases-00 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, 22 Feb 2014 07:38:01 -0000 This is a multipart message in MIME format. --=_alternative 002A0FBF48257C87_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWXVuY2hpo6wNCg0KICAgUmlnaHQuIFJldHVybmluZyBwYWNrZXRzIHRvIHRoZSBvcmlnaW5h bCBDUEUvQk5BUyBmb3IgZm9yd2FyZGluZyBpcw0Kb25lIG9mIHRoZSBtb2RlcyBvZiBkZXBsb3lt ZW50IGNvbnNpZGVyYXRpb24uIEl0IG1pZ2h0IGJlIG1vcmUgcmVjb21tZW5kZWQNCmZvciBmYWN0 b3JzIG9mIHJlZHVjaW5nIGNvc3QuDQoNCiAgUExTIGhhdmUgYSBsb29rIGF0IHNlY3Rpb24gNC4x IGNvbnRleHQgYW5kIGZpZ3VyZS4NCg0KICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQog ICAgICAgICAgICAgICAgIHwgICAgSG9zdCAgIHwNCiAgICAgICAgICAgICAgICAgKy0tLS0tKy0t LS0tKw0KICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICArLS0tLS0tLS0tfC0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0rDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgIHwgICAgLS0tLS0tLS0t LS0tLSAgfA0KICAgICAgICAgICAgIHwgICAgICAgIENQRSAgICAgICAgLS0tLS0+ICAgfCAgICBT RlAgICAgICB8IHwNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIDwtLS0tLSAgIC0t LS0tLS0tLS0tLS0tICB8DQogICAgICAgICAgICAgKy0tLS0tLS0tLXwtLS0tLS0tLS0rICAgICst LS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogIFRoZXJlIGlzIGFub3RoZXIgbW9kZSB0byB0aGUgZGVw bG95bWVudCBjb25zaWRlcmF0aW9uLiBTZXJ2aWNlIG5vZGUgDQpuZWVkcyB0bw0KZm9yd2FyZCBw YWNrZXRzIHRvIG5leHQgaG9wIGluIHNvbWUgd2F5LiBJbiBzZWN0aW9uIDQuMSwNCg0KICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICB8LW91dC0+Y2xhc3NpZmllciBBIHwNCiAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICstLS0tLS18LS0tLS0tKw0KICAgICAgICAg ICAgIHwgICAgICAgIENQRSAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICBvdXQNCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLXYt LS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNGUCAg QSAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tfC0tLS0t LSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHYNCg0KICBUaGVzZSBjb25zaWRlcmF0 aW9ucyBzZWVtIHRvIGJlIHF1aXRlIGltcGxlbWVudGVkIHVuZGVyIHRyYWRpdGlvbmFsIA0KYnJv YWRiYW5kDQpuZXR3b3JrLiBIb3cgd2lsbCBpdCBwZXJmb3JtIGluIGNlbnRyYWxpemVkIG1hbmFn ZW1lbnQgb2YgYnJvYWRiYW5kIA0KbmV0d29yaz8gSQ0KdGhpbmsgaXQgaXMgYW4gaW50ZXJlc3Rp bmcgdG9waWMgbWFueSBwZW9wbGUgY29uY2VybiBhYm91dC4gDQoNClRoYW5rcywNCldlaQ0KDQoN Cg0KDQpGcm9tOiAiWXVjaGkgQ2hlbiIgPGNoZW55Y214IGF0IGdtYWlsLmNvbT4gDQpUbzogbWVu Zy53ZWkyIDxtZW5nLndlaTIgYXQgenRlLmNvbS5jbj4gDQpDYzogc2ZjIDxzZmMgYXQgaWV0Zi5v cmc+IA0KRGF0ZTogRnJpLCAyMSBGZWIgMjAxNCAxNTozMjoxNiArMDgwMCANClJlZmVyZW5jZXM6 IA0KPE9GOUI2NDBEQTIuQTM0MjkxNTktT040ODI1N0M4Ni4wMDBBN0RDMS00ODI1N0M4Ni4wMDBG MkUxMEB6dGUuY29tLmNuPiANCkxpc3QtaWQ6IE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyA8c2Zj LmlldGYub3JnPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhpIFdlaSwNCiAgICAgWWVz LCB0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBJIHRoaW5rIHlvdSBtZWFuIHRoYXQgc3Vj aCBhIA0KY2xhc3NpZmllciBpcyBub3QgcmVzcG9uc2libGUgZm9yIGZvcndhcmRpbmcgcGFja2V0 cywgYnV0IG9ubHkgZm9yIHBhY2tldCANCnByb2Nlc3NpbmcsIGFuZCBvbmNlIHRoZSBwcm9jZWR1 cmUgaXMgZG9uZSwgdGhlIHBhY2tldCB3aWxsIGJlIHJldHVybmVkIHRvIA0KdGhlIENQRS9CTkFT IGZvciBmb3J3YXJkaW5nLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCBteSBzdWdnZXN0aW9uIGlzIHRv IA0KY2xhcmlmeSB0aGlzIHBvaW50IHNvbWV3aGVyZSBpbiB0aGUgdGV4dCBpZiBwb3NzaWJsZS4N CiANCkJlc3QgcmVnYXJkcyENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KWXVjaGkgQ2hl bg0KIA0KRnJvbTogbWVuZy53ZWkyDQpEYXRlOiAyMDE0LTAyLTIxIDEwOjQzDQpUbzogY2hlbnlj bXgNCkNDOiBzZmMNClN1YmplY3Q6IFJlOltzZmNdIENvbW1lbnRzIG9uIGRyYWZ0LW1lbmctc2Zj LWJyb2FkYmFuZC11c2VjYXNlcy0wMA0KDQpIaSBZdWNoaSwgDQoNCiAgVGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLiANCg0KICBJTU8sIGNsYXNzaWZpZXIgaXMgYSBsb2dpY2FsIGVudGl0eSB0aGF0 IGNhbiBiZSBsb2NhdGVkIGluIHNvbWUgcGh5c2ljYWwgDQphcHBhcmF0dXNlcywgDQphbmQgdGhh dCBpbmNsdWRlcyBDUEVzL0JOQVNlcy4gDQoNCiAgRm9yIElQdjYgdHJhbnNpdGlvbiB1c2UgY2Fz ZXMsIHRoZXJlIG1pZ2h0IGJlIHNvbWUgZGlmZmVyZW50IHR5cGVzIG9mIA0KdGVjaG5vbG9neSwg c3VjaCANCmFzIERTLUxpdGUvTFcgNG82L01BUC4uLiAgVGhhdCBicmluZ3MgYSBwcm9ibGVtIHRo YXQgc2V2ZXJhbCBkZW1vbmRzIG1pZ2h0IA0KYmUgbWFkZSBvbiANCkNQRXMuIENQRXMgTVVTVCBz dXBwb3J0IE5BVC9GSVJFV0FMTC9TT0ZUV0lSRS4gDQogIEluIHRoaXMgY29udGV4dCwgQ1BFIG1p Z2h0IG5vdCBiZSBzdWl0ZWQgdG8gaW1wbGVtZW50IGFsbCBmdW5jdGlvbnMuIA0KDQogIEluIGFu IGFjdHVhbCBkZXBsb3ltZW50IHNjZW5hcmlvLCB3ZSBjYW4gY29uc2lkZXIgYSBjbHVzdGVyIG9m IENQRXMgd2l0aCANCmEgc2FtZSBhc3NvY2lhdGVkIA0Kc2VydmljZSBub2RlIHRvIGltcGxlbWVu dCB0aGUgc2VydmljZSBmdW5jdGlvbnMuIFRodXMsIGl0IHdpbGwgc2ltcGxpZmllZCANCnRoZSBm dW5jdGlvbmFsaXR5IA0Kb2YgQ1BFcyBhbmQgbGV0IENQRXMgdW5pZmllZC4gDQogDQogIEkgaG9w ZSB0aGVzZSBjYW4gYWRkcmVzcyB5b3VyIHF1ZXN0aW9ucyBhbmQgZG91YnRzLiANCg0KDQpUaGFu a3MsIA0KV2VpIA0KDQoNCg0KDQpGcm9tOiAiWXVjaGkgQ2hlbiIgPGNoZW55Y214IGF0IGdtYWls LmNvbT4gDQpUbzogbWVuZy53ZWkyIDxtZW5nLndlaTIgYXQgenRlLmNvbS5jbj4gDQpDYzogc2Zj IDxzZmMgYXQgaWV0Zi5vcmc+IA0KRGF0ZTogVGh1LCAyMCBGZWIgMjAxNCAxMzoyNzowNiArMDgw MCANCkxpc3QtaWQ6IE5ldHdvcmsgU2VydmljZSBDaGFpbmluZyA8c2ZjLmlldGYub3JnPiANCg0K SGkgV2VpLCANCiANCkkndmUgcmVhZCB0aGUgZHJhZnQuIElNSE8gdGhpcyBkcmFmdCBwcm92aWRl cyBhIG5ldyBwb2ludCBvZiB2aWV3IHRoYXQgU0ZDIA0KY2FuIGJlIGFwcGxpZWQgaW4gdGhlIGRl cGxveW1lbnQgb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbXMuIA0KIA0KSGVyZSBpcyBhIHF1 ZXN0aW9uIEkgaGF2ZTogIHdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIENQRS9CTkFT IGFuZCANCnRoZSBjbGFzc2lmaWVyPyBGb3Igbm93IHRoZSBjbGFzc2lmaWVyIHNlZW1zIHRvIGJl IGFuIGluZGl2aWR1YWwgZGV2aWNlLiANCklmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwg SSB0aGluayBpdCBtaWdodCBiZSB0cml2YWwgdG8gaW1wbGVtZW50IA0Kc3VjaCB2YXJpb3VzIGRl dmljZXMsIGFzIHRoZWlyIHNwZWNmaWNhdGlvbnMgc2hvdWxkIHF1aXRlIGRlcGVuZCBvbiB0aGVp ciANCmFjdHVhbCBsb2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuIElzIGl0IHBvc3NpYmxlIHRvIGxl dCBDUEUvQk5BUyBwZXJmb3JtIA0KdGhlIHNlcnZpY2UgZnVuY3Rpb25zPyANCiANCkJlc3QgcmVn YXJkcyEgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQoNCll1Y2hpIENoZW4gDQo= --=_alternative 002A0FBF48257C87_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFl1bmNoaaOsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Umln aHQuIFJldHVybmluZyBwYWNrZXRzDQp0byB0aGUgb3JpZ2luYWwgQ1BFL0JOQVMgZm9yIGZvcndh cmRpbmcgaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9uZSBv ZiB0aGUgbW9kZXMgb2YgZGVwbG95bWVudCBjb25zaWRlcmF0aW9uLg0KSXQgbWlnaHQgYmUgbW9y ZSByZWNvbW1lbmRlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Zm9yIGZhY3RvcnMgb2YgcmVkdWNpbmcgY29zdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBQTFMgaGF2ZSBhIGxvb2sgYXQgc2VjdGlvbiA0 LjENCmNvbnRleHQgYW5kIGZpZ3VyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLS0tLS0tLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO0hvc3QgJm5ic3A7IHw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLSst LS0tLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsrLS0tLS0tLS0tfC0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOystLS0tLS0t LS0tLS0tLS0tLS0tKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CnwgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOy0tLS0tLS0tLS0tLS0gJm5ic3A7fDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Q1BFICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tLS0tJmd0Ow0KJm5ic3A7IHwgJm5i c3A7ICZuYnNwO1NGUCAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgfDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZsdDstLS0tLSAmbmJzcDsgLS0tLS0tLS0tLS0tLS0g Jm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOystLS0tLS0tLS18LS0t LS0tLS0tKyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0rPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgVGhlcmUgaXMgYW5vdGhl ciBtb2RlIHRvIHRoZQ0KZGVwbG95bWVudCBjb25zaWRlcmF0aW9uLiBTZXJ2aWNlIG5vZGUgbmVl ZHMgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvcndhcmQg cGFja2V0cyB0byBuZXh0IGhvcCBpbiBzb21lDQp3YXkuIEluIHNlY3Rpb24gNC4xLDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOystLS0tLS0tLS0tLS0tLS0tLS0tKyAm bmJzcDsgJm5ic3A7ICstLS0tLS0tLS0tLS0tKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCnwtb3V0LSZndDtjbGFzc2lmaWVyIEEgfDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7ICZuYnNwOyArLS0tLS0tfC0tLS0t LSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0NQRSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQp8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnwgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvdXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7Ky0tLS0tLXYtLS0tLS0rPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyBTRlAgJm5ic3A7QSAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLS18LS0tLS0tKzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoZXNlIGNv bnNpZGVyYXRpb25zIHNlZW0gdG8NCmJlIHF1aXRlIGltcGxlbWVudGVkIHVuZGVyIHRyYWRpdGlv bmFsIGJyb2FkYmFuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ bmV0d29yay4gSG93IHdpbGwgaXQgcGVyZm9ybSBpbiBjZW50cmFsaXplZA0KbWFuYWdlbWVudCBv ZiBicm9hZGJhbmQgbmV0d29yaz8gSTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+dGhpbmsgaXQgaXMgYW4gaW50ZXJlc3RpbmcgdG9waWMgbWFueQ0KcGVvcGxlIGNv bmNlcm4gYWJvdXQuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ V2VpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5Gcm9tOiAmcXVvdDtZdWNoaSBDaGVuJnF1b3Q7ICZsdDtjaGVueWNteA0K YXQgZ21haWwuY29tJmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRvOiBtZW5nLndlaTIgJmx0O21lbmcud2VpMiBhdCB6dGUuY29tLmNuJmd0Ow0KPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5DYzogc2ZjICZsdDtzZmMgYXQg aWV0Zi5vcmcmZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ RGF0ZTogRnJpLCAyMSBGZWIgMjAxNCAxNTozMjoxNiArMDgwMA0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWZlcmVuY2VzOiAmbHQ7T0Y5QjY0MERBMi5BMzQy OTE1OS1PTjQ4MjU3Qzg2LjAwMEE3REMxLTQ4MjU3Qzg2LjAwMEYyRTEwQHp0ZS5jb20uY24mZ3Q7 DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpc3QtaWQ6IE5l dHdvcmsgU2VydmljZSBDaGFpbmluZyAmbHQ7c2ZjLmlldGYub3JnJmd0Ow0KPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGkgV2VpLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDtZZXMsIHRoYW5rcyBmb3INCnRoZSBjbGFyaWZpY2F0aW9uLiBJIHRoaW5rIHlvdSBtZWFu IHRoYXQgc3VjaCBhIGNsYXNzaWZpZXIgaXMgbm90IHJlc3BvbnNpYmxlDQpmb3IgZm9yd2FyZGlu ZyBwYWNrZXRzLCBidXQgb25seSBmb3IgcGFja2V0IHByb2Nlc3NpbmcsIGFuZCBvbmNlIHRoZSBw cm9jZWR1cmUNCmlzIGRvbmUsIHRoZSBwYWNrZXQgd2lsbCBiZSByZXR1cm5lZCB0byB0aGUgQ1BF L0JOQVMgZm9yIGZvcndhcmRpbmcuIElmDQp0aGlzIGlzIHRoZSBjYXNlLCBteSBzdWdnZXN0aW9u IGlzIHRvIGNsYXJpZnkgdGhpcyBwb2ludCBzb21ld2hlcmUgaW4gdGhlDQp0ZXh0IGlmIHBvc3Np YmxlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHMhPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+WXVjaGkgQ2hlbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9t OiBtZW5nLndlaTI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRh dGU6IDIwMTQtMDItMjEgMTA6NDM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRvOiBjaGVueWNteDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Q0M6IHNmYzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ U3ViamVjdDogUmU6W3NmY10gQ29tbWVudHMgb24gZHJhZnQtbWVuZy1zZmMtYnJvYWRiYW5kLXVz ZWNhc2VzLTAwPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5IaSBZdWNoaSwgPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJTU8sIGNsYXNzaWZpZXIgaXMg YSBsb2dpY2FsDQplbnRpdHkgdGhhdCBjYW4gYmUgbG9jYXRlZCBpbiBzb21lIHBoeXNpY2FsIGFw cGFyYXR1c2VzLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFu ZCB0aGF0IGluY2x1ZGVzIENQRXMvQk5BU2VzLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBGb3IgSVB2NiB0cmFuc2l0aW9uIHVzZSBjYXNl cywNCnRoZXJlIG1pZ2h0IGJlIHNvbWUgZGlmZmVyZW50IHR5cGVzIG9mIHRlY2hub2xvZ3ksIHN1 Y2ggPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcyBEUy1MaXRl L0xXIDRvNi9NQVAuLi4gJm5ic3A7VGhhdA0KYnJpbmdzIGEgcHJvYmxlbSB0aGF0IHNldmVyYWwg ZGVtb25kcyBtaWdodCBiZSBtYWRlIG9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Q1BFcy4gQ1BFcyBNVVNUIHN1cHBvcnQgTkFUL0ZJUkVXQUxML1NPRlRXSVJF Lg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSW4g dGhpcyBjb250ZXh0LCBDUEUgbWlnaHQgbm90DQpiZSBzdWl0ZWQgdG8gaW1wbGVtZW50IGFsbCBm dW5jdGlvbnMuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7IEluIGFuIGFjdHVhbCBkZXBsb3ltZW50IHNjZW5hcmlvLA0Kd2UgY2FuIGNvbnNp ZGVyIGEgY2x1c3RlciBvZiBDUEVzIHdpdGggYSBzYW1lIGFzc29jaWF0ZWQgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZXJ2aWNlIG5vZGUgdG8gaW1wbGVtZW50 IHRoZSBzZXJ2aWNlDQpmdW5jdGlvbnMuIFRodXMsIGl0IHdpbGwgc2ltcGxpZmllZCB0aGUgZnVu Y3Rpb25hbGl0eSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9m IENQRXMgYW5kIGxldCBDUEVzIHVuaWZpZWQuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7IEkgaG9wZSB0aGVzZSBjYW4gYWRkcmVzcyB5b3VyDQpxdWVzdGlvbnMg YW5kIGRvdWJ0cy4gPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGFua3MsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+V2VpIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTogJnF1b3Q7WXVjaGkgQ2hlbiZxdW90OyAmbHQ7Y2hl bnljbXgNCmF0IGdtYWlsLmNvbSZndDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UbzogbWVuZy53ZWkyICZsdDttZW5nLndlaTIgYXQgenRlLmNvbS5jbiZndDsN CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2M6IHNmYyAmbHQ7 c2ZjIGF0IGlldGYub3JnJmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkRhdGU6IFRodSwgMjAgRmViIDIwMTQgMTM6Mjc6MDYgKzA4MDANCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGlzdC1pZDogTmV0d29yayBTZXJ2aWNl IENoYWluaW5nICZsdDtzZmMuaWV0Zi5vcmcmZ3Q7DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFdlaSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5JJ3ZlIHJlYWQgdGhlIGRyYWZ0LiBJTUhPIHRoaXMgZHJhZnQNCnByb3Zp ZGVzIGEgbmV3IHBvaW50IG9mIHZpZXcgdGhhdCBTRkMgY2FuIGJlIGFwcGxpZWQgaW4gdGhlIGRl cGxveW1lbnQNCm9mIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc21zLiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlcmUgaXMgYSBxdWVzdGlvbiBJIGhhdmU6ICZuYnNwO3do YXQNCmlzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBDUEUvQk5BUyBhbmQgdGhlIGNsYXNzaWZp ZXI/IEZvciBub3cgdGhlIGNsYXNzaWZpZXINCnNlZW1zIHRvIGJlIGFuIGluZGl2aWR1YWwgZGV2 aWNlLiBJZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIEkgdGhpbmsNCml0IG1pZ2h0IGJl IHRyaXZhbCB0byBpbXBsZW1lbnQgc3VjaCB2YXJpb3VzIGRldmljZXMsIGFzIHRoZWlyIHNwZWNm aWNhdGlvbnMNCnNob3VsZCBxdWl0ZSBkZXBlbmQgb24gdGhlaXIgYWN0dWFsIGxvY2F0aW9ucyBp biB0aGUgbmV0d29yay4gSXMgaXQgcG9zc2libGUNCnRvIGxldCBDUEUvQk5BUyBwZXJmb3JtIHRo ZSBzZXJ2aWNlIGZ1bmN0aW9ucz8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5CZXN0IHJlZ2FyZHMhIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WXVjaGkgQ2hlbiAmbmJzcDs8L2ZvbnQ+DQo= --=_alternative 002A0FBF48257C87_=-- From nobody Sun Feb 23 19:04:26 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791BF1A0259 for ; Sun, 23 Feb 2014 19:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.06 X-Spam-Level: *** X-Spam-Status: No, score=3.06 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 6u_nEilY-e5w for ; Sun, 23 Feb 2014 19:04:22 -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 F1AA31A0273 for ; Sun, 23 Feb 2014 19:04:21 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1O34KGZ011162; Mon, 24 Feb 2014 12:04:20 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BF21AE0133; Mon, 24 Feb 2014 12:04:20 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B3198E0132; Mon, 24 Feb 2014 12:04:20 +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 s1O34CNt019118; Mon, 24 Feb 2014 12:04:20 +0900 Message-ID: <530AB6ED.5000006@lab.ntt.co.jp> Date: Mon, 24 Feb 2014 12:05:17 +0900 From: =?UTF-8?B?5pys6ZaT5L+K5LuL?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: mohamed.boucadair@orange.com, "sfc@ietf.org" X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qdoIaXwO1JXNrmIsZl9GZay5lEo Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 03:04:24 -0000 Hi Med, In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. 1. The case that the types of SF increase: I assumed that the unit of applying SFC to traffic is following; - grouping: traffic is applied with specific SFC for each service, enterprise customer or region, - per-subscriber: traffic is applied with specific SFC for each　 subscriber (e.g. per IP address, VLAN ID et.al), - per-flow: traffic is applied with specific SFC for each subscriber, 　　and objective (e.g. pre URL, application et.al). Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). 2. The case that there are some SFs that must be classified for each instance: In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). IMHO,requirements for scalability will affect SFC architecture and header format. Thanks, Shunsuke (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: > Dear all, > > This new version integrates inputs from NTT representatives. > > The diff can be tracked here: http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01&difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 > > Cheers, > Med > > -----Message d'origine----- > De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org > Envoyé : mercredi 12 février 2014 10:46 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-sfc-requirements-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Requirements for Service Function Chaining > Authors : Mohamed Boucadair > Christian Jacquenet > Yuanlong Jiang > Ron Parker > Carlos Pignataro > Kengo Naito > Filename : draft-boucadair-sfc-requirements-03.txt > Pages : 14 > Date : 2014-02-12 > > Abstract: > This document identifies the requirements for the Service Function > Chaining (SFC). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ******************************************** 本間 俊介 (Homma Shunsuke) 日本電信電話株å¼ä¼šç¤¾ ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト 転é€ã‚µãƒ¼ãƒ“ス制御DP 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 TEL: 0422-59-3486 E-MAIL: homma.shunsuke@lab.ntt.co.jp ******************************************** From nobody Sun Feb 23 19:39:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67DA1A0286 for ; Sun, 23 Feb 2014 19:39:06 -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_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 QjQIf0QOnhFV for ; Sun, 23 Feb 2014 19:39:04 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC41A027D for ; Sun, 23 Feb 2014 19:39:04 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Sun, 23 Feb 2014 19:39:04 -0800 From: Ron Parker To: =?utf-8?B?5pys6ZaT5L+K5LuL?= Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKy Date: Mon, 24 Feb 2014 03:39:03 +0000 Message-ID: <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> In-Reply-To: <530AB6ED.5000006@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gRSrRCkaZ8Xn7jVOKgBCMp5JJ8o Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 03:39:07 -0000 U2h1bnN1a2Utc2FuLA0KDQpXaGlsZSBhIHRoZW9yZXRpY2FsIGNhc2UgY2FuIGJlIG1hZGUgZm9y IG9uZSBvciBtb3JlIFNGQ3MgcGVyIHN1YnNjcmliZXIsIGZvciByZWFzb25zIHlvdSBzdGF0ZSwg aXQgaXNuJ3QgcHJhY3RpY2FsLiAgQnV0LCB0aGVyZSBpcyBhbm90aGVyIHdheSB0byB2aWV3IHRo aXMgYXNwZWN0IG9mIHRoZSBwcm9ibGVtLiAgTGV0J3MgdGFrZSB5b3VyIHBlci1zdWJzY3JpYmVy IGN1c3RvbWl6ZWQgZmlyZXdhbGwgYXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4gIElmIHRoZXJl IHdlcmUgb25seSBvbmUgZmlyZXdhbGwsIGluc3RlYWQsIGFuZCBpdCB3YXMgY2FwYWJsZSBvZiBs b2NhbCBwb2xpY3kgZXZhbHVhdGlvbiBiYXNlZCBvbiBzdWJzY3JpYmVyLCB0aGUgbnVtYmVyIG9m IFNGQ3Mgd291bGQgYmUgdmFzdGx5IHJlZHVjZWQuICAgT25lIHdheSBmb3IgdGhhdCB0byBoYXBw ZW4gd291bGQgYmUgdG8gc2ltcGx5IHVzZSB0aGUgc291cmNlL2Rlc3RpbmF0aW9uIElQIGFkZHJl c3MgZnJvbSB0aGUgcGFja2V0IGFuZCBzb21lIG91dCBvZiBiYW5kIGxvb2t1cCBtZWNoYW5pc20g bGlrZSBMREFQIG9yIFJBRElVUyBhdCB0aGUgZmlyZXdhbGwuICAgIEFub3RoZXIgYXBwcm9hY2gg dG8gZGV0ZXJtaW5lIHdobyB0aGUgc3Vic2NyaWJlciBpcyB3b3VsZCBiZSBmb3IgdGhlIFNGQyBj bGFzc2lmaWVyIHRvIGFkZCBhIGRpc3RpbmN0IHN1YnNjcmliZXIgaWQgYXMgbWV0YWRhdGEgdG8g dGhlIHNlcnZpY2UgaGVhZGVyIChlZywgYW4gSU1TSSkgYW5kIHN0aWxsIHVzZSBMREFQLCBldGMu IGF0IHRoZSBmaXJld2FsbC4gDQoNCklmIHRoZSBwcm9ibGVtIGlzIGNoYW5nZWQgc2xpZ2h0bHkg c28gdGhhdCB0aGUgZmlyZXdhbGwgcG9saWN5IGlzIHBlciBncm91cCBvZiBzdWJzY3JpYmVycywg d2hlcmUgdGhlcmUgYXJlIHBlcmhhcHMgMTBzIG9mIGdyb3VwcywgdGhlbiB5ZXQgYW5vdGhlciBh cHByb2FjaCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwgYXMgYSBkaXN0aW5jdCBsb2dpY2FsIGZp cmV3YWxsIHBlciBmaXJld2FsbCBwb2xpY3kgc2V0ICh0aGV5IGNvdWxkIGFsbCByZXNpZGUgaW4g dGhlIHNhbWUgbWFjaGluZSBvciBWTSkgYW5kIHRvIGNvb3JkaW5hdGUgdGhlIGNsYXNzaWZpZXIn cyBwb2xpY3kgYWNjb3JkaW5nbHkuIA0KDQogICBSb24NCg0KDQo+IE9uIEZlYiAyMywgMjAxNCwg YXQgMTA6MDQgUE0sICLmnKzplpPkv4rku4siIDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpw PiB3cm90ZToNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IEluIHRlcm1zIG9mIHlvdXIgY29tbWVudCwg SSBhc3N1bWVkIHNvbWUgdXNlIGNhc2VzIGFib3V0IHNjYWxhYmlsaXR5IHNvIHRoYXQgd2UgY2Fu IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFib3V0IHNjYWxhYmlsaXR5IGNvbnNpZGVyYXRpb25z Lg0KPiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0aG9yIG9mIHJlcXVpcmVtZW50IGRyYWZ0 IGFuZCB0aGluayBzY2FsYWJpbGl0eSBpcyBvbmUgb2YgaW1wb3J0YW50IHRoaW5ncyB0byBjb25z aWRlci4NCj4gDQo+IEFzc3VtaW5nIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGZvbGxvd2luZywgdGhl IG1hbmFnZW1lbnQgbWVjaGFuaXNtIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIG1pZ2h0IHJl cXVpcmUgaGlnaCBzY2FsYWJpbGl0eS4NCj4gDQo+IDEuIFRoZSBjYXNlIHRoYXQgdGhlIHR5cGVz IG9mIFNGIGluY3JlYXNlOg0KPiBJIGFzc3VtZWQgdGhhdCB0aGUgdW5pdCBvZiBhcHBseWluZyBT RkMgdG8gdHJhZmZpYyBpcyBmb2xsb3dpbmc7DQo+ICAtIGdyb3VwaW5nOiB0cmFmZmljIGlzIGFw cGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc2VydmljZSwNCj4gICAgZW50ZXJwcmlz ZSBjdXN0b21lciBvciByZWdpb24sDQo+ICAtIHBlci1zdWJzY3JpYmVyOiB0cmFmZmljIGlzIGFw cGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2jjgIANCj4gICAgc3Vic2NyaWJlciAoZS5n LiBwZXIgSVAgYWRkcmVzcywgVkxBTiBJRCBldC5hbCksDQo+ICAtIHBlci1mbG93OiB0cmFmZmlj IGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc3Vic2NyaWJlciwNCj4g44CA 44CAYW5kIG9iamVjdGl2ZSAoZS5nLiBwcmUgVVJMLCBhcHBsaWNhdGlvbiBldC5hbCkuDQo+IA0K PiBTb21lIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBoYXZlIGVub3Jtb3VzIG51bWJlciBvZiBz dWJzY3JpYmVycywgYW5kIHRoZSBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgaXMgdXAgdG8gc2V2ZXJh bCB0ZW5zIG9yIGh1bmRyZWRzIG9mIG1pbGxpb24uIFRoZXJlZm9yZSwgaW4gY2FzZXMgb2YgcGVy LXN1YnNjcmliZXIgYW5kIHBlci1mbG93LCB0aGUgbnVtYmVyIG9mIFNGQ3MgbWlnaHQgaW5jcmVh c2UgZXhwbG9zaXZlbHkuIFBlci1zdWJzY3JpYmVyIFNGQ3Mgd291bGQgYmUgbmVlZGVkIGluIHRo ZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIGRlZGljYXRlZCB0byBlYWNoIHVzZXIoZS5n LiB2Q1BFIGFzIHVzZXIgY3VzdG9taXplZCkuDQo+IA0KPiBBbHNvLCBpbiBjYXNlIG9mIGdyb3Vw aW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3NlIHBvbGljaWVzIGFyZSBkaWZm ZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIgYW5kIHBlciByZWdpb24sIHRo ZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBGaXJld2FsbHMgaGF2ZSBkaWZm ZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9tZXIpLg0KPiANCj4gMi4gVGhl IGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgdGhhdCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9y IGVhY2ggaW5zdGFuY2U6DQo+IEluIGNhc2UgdGhhdCB0aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNh bWUgZnVuY3Rpb24gaW4gdGhlIG5ldHdvcmsgYW5kIHRoZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVk IGZvciBlYWNoIGluc3RhbmNlLCB0aGUgY29tYmluYXRpb24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNl Lg0KPiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBzdGF0ZWZ1bCB0cmFmZmljIGFyZSBuZWVkZWQgdG8g YmUgZGlmZmVyZW50aWF0ZWQgcGVyIGluc3RhbmNlIChlLmcuIEZpcmV3YWxsLCBDb250ZW50cy1D YWNoZSwgYW5kIFZpZGVvLU9wdGltaXplcikuDQo+IA0KPiBJTUhPLHJlcXVpcmVtZW50cyBmb3Ig c2NhbGFiaWxpdHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1h dC4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IFNodW5zdWtlDQo+IA0KPiAoMjAxNC8wMi8xMiAxODo0 OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+PiBEZWFyIGFsbCwNCj4+ IA0KPj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVzIGlucHV0cyBmcm9tIE5UVCByZXByZXNl bnRhdGl2ZXMuDQo+PiANCj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFja2VkIGhlcmU6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRz LTAxJmRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1y ZXF1aXJlbWVudHMtMDMNCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+PiANCj4+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5u b3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcNCj4+IEVudm95w6kgOiBtZXJjcmVkaSAxMiBmw6l2cmllciAyMDE0IDEwOjQ2DQo+PiDD gCA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPj4gT2JqZXQgOiBJLUQgQWN0aW9uOiBkcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+IA0KPj4gDQo+PiBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQo+PiANCj4+IA0KPj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1 aXJlbWVudHMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCj4+ICAgICAgICAgQXV0aG9y cyAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFu bG9uZyBKaWFuZw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4gICAgUGFnZXMgICAgICAgICAg IDogMTQNCj4+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDItMTINCj4+IA0KPj4gQWJzdHJh Y3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3Ig dGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+ICAgIENoYWluaW5nIChTRkMpLg0KPj4gDQo+PiANCj4+ IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItc2Zj LXJlcXVpcmVtZW50cy8NCj4+IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRh aXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiANCj4+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2ll dGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQo+IA0K PiAtLSANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4g 5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+IA0KPiDml6XmnKzpm7vkv6Hpm7voqbHm oKrlvI/kvJrnpL4NCj4g44ON44OD44OI44Ov44O844Kv44K144O844OT44K544K344K544OG44Og 56CU56m25omADQo+IOi7oumAgeOCteODvOODk+OCueWfuuebpOODl+ODreOCuOOCp+OCr+ODiA0K PiDou6LpgIHjgrXjg7zjg5PjgrnliLblvqFEUA0KPiANCj4g44CSMTgwLTg1ODXjgIDmnbHkuqzp g73mrabolLXph47luILnt5HnlLozLTktMTENCj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4gRS1NQUlM OiBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwDQo+ICoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Feb 24 09:38:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3567D1A0239 for ; Mon, 24 Feb 2014 09:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.347 X-Spam-Level: X-Spam-Status: No, score=-7.347 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_b2EGL_DZxZ for ; Mon, 24 Feb 2014 09:38:24 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D61A015B for ; Mon, 24 Feb 2014 09:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9007; q=dns/txt; s=iport; t=1393263504; x=1394473104; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XwcGc5ZWiEXUK4PKIpnMTE1RduLwb0FG430eW37KNBQ=; b=mI3Z5+fgRUbnK2dY/rtL/Ic455z0Pe9wWZBoLgjvgpw7wEYGC9+wMogz IUxl4OdRDcNUaefYCRqLltnxI/zugD8GI0kaIHmh52uIZE3/ADeytnr5I 0q8hwmumdDpvKXvWw+YIlWEardebcAtJNSXoDvU6crlhlZf48JlC+BUX+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAF2CC1OtJV2d/2dsb2JhbABZgkJEgRLBAIEaFnSCJgEBBHIHEAIBCBItBzIUAw4BAQQOBYgFxXYXjgFjB4MkgRQElAWEL5Ingy2CKg X-IronPort-AV: E=Sophos; i="4.97,535,1389744000"; d="scan'208,217"; a="22776774" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 24 Feb 2014 17:38:23 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1OHcNU3015042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 17:38:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 11:38:23 -0600 From: "Paul Quinn (paulq)" To: Lucy yong Thread-Topic: [sfc] comments on sfc-arch-04 Thread-Index: Ac8vYYEESz2vV8pzQuahhxFqQJ2pagCV/luA Date: Mon, 24 Feb 2014 17:38:22 +0000 Message-ID: <13D0C263-CC36-438F-A8FD-63B3BEFC8548@cisco.com> References: <2691CE0099834E4A9C5044EEC662BB9D453337C5@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453337C5@dfweml701-chm.china.huawei.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: multipart/alternative; boundary="_000_13D0C263CC36438FA8FD63B3BEFC8548ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yj4retBJysolUMol4k69GwIFRl8 Cc: "andre.beliveau@ericsson.com" , "sfc@ietf.org" Subject: Re: [sfc] comments on sfc-arch-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 17:38:27 -0000 --_000_13D0C263CC36438FA8FD63B3BEFC8548ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Lucy, Thanks for your comments! Please see inline. Paul On Feb 21, 2014, at 7:03 PM, Lucy yong > wrote: Hi Paul, et al, I have some concerns on the service function chaining architecture illustra= ted in Figure 3. The numbered circle notation is used in figure 1 where it represents a SF n= ode in a SF graph. Figure 1 gives very abstract view of SFC without any assumption how it is b= e realized. The goal of figure 1 is simply to introduce the concept that what we call a= "chain" is really a graph. It isn't intended to depict any architectural = component. Figure 3 is the reference architecture for service function chaining. It is= important for it to illustrate the key functional components and their rel= ationship. Section 3.2 describes fundamental components in SFC, but they a= re not shown in the figure 3 at all, and I don=92t see we can simply replac= e each numbered circle in figure 3 with the draw in figure 2. I will update figure 3 to depict each component in more detail so avoid any= confusion between 2 and 3. Thank you. One clarification question for SF, SFF, and SNF in figure 2: what is cardin= ality in between? Can one SNF have one or more SFFs? can one SFF have one o= r more SFs? I can=92t tell from their description and think that is importa= nt for the architecture as well. Yes, in general it is a n:m relationship. Version -05 of the document will= include this required specificity. Do we have one control plane to work with SF, SFF, SNF components or more t= han one? IMO: it is important to clarify them in the arch doc. We generalize control and policy plane into an abstraction given the possib= le breadth of control/policy planes that might be in use. Having said tha= t, we plan to bolster the control and policy plane discussion going forward= . Do you have suggested text or concepts you'd like to convey? --_000_13D0C263CC36438FA8FD63B3BEFC8548ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5BBE2B5D735B904A915569F2BFFE1A29@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Lucy,

Thanks for your comments!  Please see inline.

Paul

On Feb 21, 2014, at 7:03 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Hi Paul, et al,
 
I have some concerns on the service function chaining architecture illustra= ted in Figure 3.
 
The numbered circle notation is used in figure 1 where it represents a SF n= ode in a SF graph.
Figure 1 gives very abstract view of SFC without any assumption how it is b= e realized.


The goal of figure 1 is simply to introduce the concept that what we c= all a "chain" is really a graph.  It isn't intended to depic= t any architectural component.

 
Figure 3 is the reference architecture for service function chaining. It is= important for it to illustrate the key functional components and their rel= ationship.  Section 3.2 describes fundamental components in SFC, but t= hey are not shown in the figure 3 at all, and I don=92t see we can simply replace each numbered circle in figur= e 3 with the draw in figure 2.  

I will update figure 3 to depict each component in more detail so avoi= d any confusion between 2 and 3.  Thank you.


 
One clarification question for SF, SFF, and SNF in figure 2: what is cardin= ality in between? Can one SNF have one or more SFFs? can one SFF have one o= r more SFs? I can=92t tell from their description and think that is importa= nt for the architecture as well.

Yes, in general it is a n:m relationship.  Version -05 of the doc= ument will include this required specificity.


 
Do we have one control plane to work with SF, SFF, SNF components or more t= han one? IMO: it is important to clarify them in the arch doc.


We generalize control and policy plane into an abstraction given the possib= le breadth of control/policy planes that might be in use.   Having sai= d that, we plan to bolster the control and policy plane discussion going fo= rward.  Do you have suggested text or concepts you'd like to convey?


--_000_13D0C263CC36438FA8FD63B3BEFC8548ciscocom_-- From nobody Mon Feb 24 12:30:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01141A02C6 for ; Mon, 24 Feb 2014 12:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 KOJfBr1_imRM for ; Mon, 24 Feb 2014 12:30:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 003321A02C4 for ; Mon, 24 Feb 2014 12:30:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBL78525; Mon, 24 Feb 2014 20:30:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 20:30:28 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 20:30:33 +0000 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.173]) by dfweml705-chm.china.huawei.com ([169.254.7.50]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 12:30:27 -0800 From: Lucy yong To: "Paul Quinn (paulq)" Thread-Topic: [sfc] comments on sfc-arch-04 Thread-Index: Ac8vYYEESz2vV8pzQuahhxFqQJ2pagCV/luAAAd34AA= Date: Mon, 24 Feb 2014 20:30:27 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4533EB73@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D453337C5@dfweml701-chm.china.huawei.com> <13D0C263-CC36-438F-A8FD-63B3BEFC8548@cisco.com> In-Reply-To: <13D0C263-CC36-438F-A8FD-63B3BEFC8548@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.47] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4533EB73dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XwVrC4acl1m2URzzmK2bMEL75Zc Cc: "andre.beliveau@ericsson.com" , "sfc@ietf.org" Subject: Re: [sfc] comments on sfc-arch-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 20:30:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4533EB73dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see in-line below. From: Paul Quinn (paulq) [mailto:paulq@cisco.com] Sent: Monday, February 24, 2014 11:38 AM To: Lucy yong Cc: andre.beliveau@ericsson.com; sfc@ietf.org Subject: Re: [sfc] comments on sfc-arch-04 Hi Lucy, Thanks for your comments! Please see inline. Paul On Feb 21, 2014, at 7:03 PM, Lucy yong > wrote: Hi Paul, et al, I have some concerns on the service function chaining architecture illustra= ted in Figure 3. The numbered circle notation is used in figure 1 where it represents a SF n= ode in a SF graph. Figure 1 gives very abstract view of SFC without any assumption how it is b= e realized. The goal of figure 1 is simply to introduce the concept that what we call a= "chain" is really a graph. It isn't intended to depict any architectural = component. [Lucy] The goal is achieved well in figure 1. But please not use the same n= umbered circle notation in other architecture draw. It causes confusion eas= ily. Figure 3 is the reference architecture for service function chaining. It is= important for it to illustrate the key functional components and their rel= ationship. Section 3.2 describes fundamental components in SFC, but they a= re not shown in the figure 3 at all, and I don't see we can simply replace = each numbered circle in figure 3 with the draw in figure 2. I will update figure 3 to depict each component in more detail so avoid any= confusion between 2 and 3. Thank you. [Lucy] good. One clarification question for SF, SFF, and SNF in figure 2: what is cardin= ality in between? Can one SNF have one or more SFFs? can one SFF have one o= r more SFs? I can't tell from their description and think that is important= for the architecture as well. Yes, in general it is a n:m relationship. Version -05 of the document will= include this required specificity. [Lucy] Do we need that general relationship? Can one SFF work with more tha= n one SNF in a SFC? IMO: We should architect what is reasonable and valuabl= e to do. Do we have one control plane to work with SF, SFF, SNF components or more t= han one? IMO: it is important to clarify them in the arch doc. We generalize control and policy plane into an abstraction given the possib= le breadth of control/policy planes that might be in use. Having said tha= t, we plan to bolster the control and policy plane discussion going forward= . Do you have suggested text or concepts you'd like to convey? [Lucy] the architecture doc is to facilitate the possible solution developm= ent. We have several key components in the architecture and each key elemen= t serves different purpose. If SFC WG does not want to work on any control/= policy plane related protocol, it is fine to model it as one abstracted pie= ce. If SFC WG also want to work on control plane requirements and protocol = between some interfaces in control/policy plane, such abstraction model can= 't serve the purpose. We need further break it down. Could you clarify what= is the goal on the control/policy plane in SFC WG? (this may be question t= o chair too). Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D4533EB73dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see in-line below.=

 <= /p>

From: Paul Qui= nn (paulq) [mailto:paulq@cisco.com]
Sent: Monday, February 24, 2014 11:38 AM
To: Lucy yong
Cc: andre.beliveau@ericsson.com; sfc@ietf.org
Subject: Re: [sfc] comments on sfc-arch-04

 

Hi Lucy,

 

Thanks for your comments!  Please see inline.

 

Paul

 

On Feb 21, 2014, at 7:03 PM, Lucy yong <lucy.yong@huawei.com> wrote:



Hi Paul, et al,

 

I have some concerns on the service fun= ction chaining architecture illustrated in Figure 3.

 

The numbered circle notation is used in= figure 1 where it represents a SF node in a SF graph.

Figure 1 gives very abstract view of SF= C without any assumption how it is be realized.

 

 

The goal of figure 1 is simply to introduce the conc= ept that what we call a "chain" is really a graph.  It isn't= intended to depict any architectural component.

[Lucy] The goal is = achieved well in figure 1. But please not use the same numbered circle nota= tion in other architecture draw. It causes confusion easily.=



 

Figure 3 is the reference architecture = for service function chaining. It is important for it to illustrate the key= functional components and their relationship.  Section 3.2 describes fundamental components in SFC, but they are not shown in the= figure 3 at all, and I don’t see we can simply replace each numbered= circle in figure 3 with the draw in figure 2.  

 

I will update figure 3 to depict each component in m= ore detail so avoid any confusion between 2 and 3.  Thank you.

[Lucy] good.=

 



 

One clarification question for SF, SFF,= and SNF in figure 2: what is cardinality in between? Can one SNF have one = or more SFFs? can one SFF have one or more SFs? I can’t tell from their description and think that is important for the architectu= re as well.

 

Yes, in general it is a n:m relationship.  Vers= ion -05 of the document will include this required specificity.<= /p>

[Lucy] Do we need t= hat general relationship? Can one SFF work with more than one SNF in a SFC?= IMO: We should architect what is reasonable and valuable to do.

 



 

Do we have one control plane to work wi= th SF, SFF, SNF components or more than one? IMO: it is important to clarif= y them in the arch doc.

 

 

We generalize control and policy plane into an abstr= action given the possible breadth of control/policy planes that might be in= use.   Having said that, we plan to bolster the control and policy pl= ane discussion going forward.  Do you have suggested text or concepts you'd like to convey?

[Lucy] the architec= ture doc is to facilitate the possible solution development. We have severa= l key components in the architecture and each key element serves different purpose. If SFC WG does not want to work on any control/p= olicy plane related protocol, it is fine to model it as one abstracted piec= e. If SFC WG also want to work on control plane requirements and protocol b= etween some interfaces in control/policy plane, such abstraction model can’t serve the purpose. We need furth= er break it down. Could you clarify what is the goal on the control/policy = plane in SFC WG? (this may be question to chair too).

 

Regards,=

Lucy

 

<= /i>

 <= /p>

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D4533EB73dfweml701chmchi_-- From nobody Mon Feb 24 14:25:46 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DBF1A02FE for ; Mon, 24 Feb 2014 14:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 bibbPVXB6MlK for ; Mon, 24 Feb 2014 14:25:41 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5E1A02FB for ; Mon, 24 Feb 2014 14:25:41 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Mon, 24 Feb 2014 17:25:40 -0500 From: Chris Frederick To: Ron Parker , =?utf-8?B?5pys6ZaT5L+K5LuL?= Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSA Date: Mon, 24 Feb 2014 22:25:39 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> In-Reply-To: <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uK70vF-zxppoNxTbP54bnHRV6tA Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 22:25:44 -0000 QWdyZWVkLg0KVG8gcmVzdGF0ZSB0aGlzIHNsaWdodGx5LCBpZiB0aGUgU0ZDIHN0ZWVyaW5nL2Rl Y2lzaW9uIGxvY3VzIGlzIGNhcGFibGUgb2YgZXZhbHVhdGluZyBtdWx0aXBsZSBvcnRob2dvbmFs IHBvbGljeSBjb25kaXRpb25zIHRoZW4gdGhpcyBpc3N1ZSBpcyBvYnZpYXRlZDsgc3Vic2NyaWJl cnMgYmVjb21lIGFuIGFnZ3JlZ2F0ZSBvZiAnd2hhdCB0aGV5IGFyZScgKyBhcmUgbm90IHNpbXBs eSAnd2hvIHRoZXkgYXJlJy4gDQpBcyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkgYmUg ZGVyaXZlZCBmcm9tIExEQVAgbG9va3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQgcnVs ZXMsIGV0Yy4NClRvIGlsbHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5IHNvbWV0 aGluZyBsaWtlIHRoaXM6DQpJZiBzdWJzY3JpYmVyIFggaXMgdXNpbmcgeW91dHViZSwgYW5kIGlz IG9uIGEgY29uZ2VzdGVkIGNlbGwsIGFuZCBpcyBvbiBhbiBpUGhvbmUsIGFuZCBpcyBpbiB0aGUg IkdvbGQgVGllciIsIGFuZCwgYW5kLCBhbmQsIGFuZCwgZXRjLCB0aGVuIHRoZSBjaGFpbiBjb25z aXN0cyBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyBhLCBiLCBhbmQgYy4NClRoZXJlJ3Mgbm8gbmVlZCB0 byBlbnRlciBhIHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChvciBhbnkg c3Vic2NyaWJlcikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVjYXVzZSBh bGwgb2YgdGhlIGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNhdmUgb25l ICgiaXMgb24gYSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFpbiBtaWdo dCBiZSBhbHRlcmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlvbiBzZXJ2 aWNlIGZ1bmN0aW9uKS4NClRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJsaWVyIGNvbW1lbnRzIFJv biArIEkgbWFkZSBhYm91dCBjb25zb2xpZGF0aW5nIHRoZSBmbG93IHJlY29nbml0aW9uICsgZGVj aXNpb24tbWFraW5nIGVudGl0eSBpbiBhIHNpbmdsZSAoc3VpdGFibHkgcG9saWN5LWF3YXJlKSBu b2RlIHRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSArIHRvIHNjYWxlIHByb3Blcmx5LiBUaHgsDQov Yw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQpTZW50OiBTdW5kYXksIEZl YnJ1YXJ5IDIzLCAyMDE0IDEwOjM5IFBNDQpUbzog5pys6ZaT5L+K5LuLDQpDYzogbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gVFI6 IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpT aHVuc3VrZS1zYW4sDQoNCldoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Ig b25lIG9yIG1vcmUgU0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBp dCBpc24ndCBwcmFjdGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhp cyBhc3BlY3Qgb2YgdGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIg Y3VzdG9taXplZCBmaXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUg d2VyZSBvbmx5IG9uZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxv Y2FsIHBvbGljeSBldmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2Yg U0ZDcyB3b3VsZCBiZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBl biB3b3VsZCBiZSB0byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVz cyBmcm9tIHRoZSBwYWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBs aWtlIExEQVAgb3IgUkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0 byBkZXRlcm1pbmUgd2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNs YXNzaWZpZXIgdG8gYWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0 aGUgc2VydmljZSBoZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4g YXQgdGhlIGZpcmV3YWxsLiANCg0KSWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBz byB0aGF0IHRoZSBmaXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3 aGVyZSB0aGVyZSBhcmUgcGVyaGFwcyAxMHMgb2YgZ3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFw cHJvYWNoIGlzIHRvIG1vZGVsIHRoZSBmaXJld2FsbCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmly ZXdhbGwgcGVyIGZpcmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0 aGUgc2FtZSBtYWNoaW5lIG9yIFZNKSBhbmQgdG8gY29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidz IHBvbGljeSBhY2NvcmRpbmdseS4gDQoNCiAgIFJvbg0KDQoNCj4gT24gRmViIDIzLCAyMDE0LCBh dCAxMDowNCBQTSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+ IHdyb3RlOg0KPiANCj4gSGkgTWVkLA0KPiANCj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJ IGFzc3VtZWQgc29tZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4g Y29udGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMu DQo+ICNJIHdvcmsgd2l0aCBLLk5haXRvLCBjby1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQg YW5kIHRoaW5rIHNjYWxhYmlsaXR5IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNp ZGVyLg0KPiANCj4gQXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0aGUg bWFuYWdlbWVudCBtZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQgcmVx dWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPiANCj4gMS4gVGhlIGNhc2UgdGhhdCB0aGUgdHlwZXMg b2YgU0YgaW5jcmVhc2U6DQo+IEkgYXNzdW1lZCB0aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNG QyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4gIC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBw bGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzZXJ2aWNlLA0KPiAgICBlbnRlcnByaXNl IGN1c3RvbWVyIG9yIHJlZ2lvbiwNCj4gIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBw bGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPiAgICBzdWJzY3JpYmVyIChlLmcu IHBlciBJUCBhZGRyZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4gIC0gcGVyLWZsb3c6IHRyYWZmaWMg aXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPiDjgIDj gIBhbmQgb2JqZWN0aXZlIChlLmcuIHByZSBVUkwsIGFwcGxpY2F0aW9uIGV0LmFsKS4NCj4gDQo+ IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVyIG9mIHN1 YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBzZXZlcmFs IHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBvZiBwZXIt c3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBpbmNyZWFz ZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQgaW4gdGhl IGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNlcihlLmcu IHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4gDQo+IEFsc28sIGluIGNhc2Ugb2YgZ3JvdXBp bmcsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMgYXJlIGRpZmZl cmVudCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJlZ2lvbiwgdGhl IG51bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZl cmVudCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+IA0KPiAyLiBUaGUg Y2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyB0aGF0IG11c3QgYmUgY2xhc3NpZmllZCBmb3Ig ZWFjaCBpbnN0YW5jZToNCj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2Ft ZSBmdW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQg Zm9yIGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2Uu DQo+IFRoZSBTRnMgdGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBi ZSBkaWZmZXJlbnRpYXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNh Y2hlLCBhbmQgVmlkZW8tT3B0aW1pemVyKS4NCj4gDQo+IElNSE8scmVxdWlyZW1lbnRzIGZvciBz Y2FsYWJpbGl0eSB3aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIgZm9ybWF0 Lg0KPiANCj4gVGhhbmtzLA0KPiANCj4gU2h1bnN1a2UNCj4gDQo+ICgyMDE0LzAyLzEyIDE4OjQ5 KSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+IERlYXIgYWxsLA0KPj4g DQo+PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2Vu dGF0aXZlcy4NCj4+IA0KPj4gVGhlIGRpZmYgY2FuIGJlIHRyYWNrZWQgaGVyZTogDQo+PiBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVt ZW50cy0wMSYNCj4+IGRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2Fk YWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+PiANCj4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBJLUQtQW5ub3VuY2UgW21haWx0 bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCANCj4+IGRlIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTIgZsOpdnJpZXIgMjAxNCAx MDo0NiDDgCANCj4+IDogaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlvbjog DQo+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+IA0KPj4gDQo+ PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiANCj4+IA0KPj4gICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCj4+ICAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBZdWFubG9uZyBKaWFuZw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBSb24g UGFya2VyDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+ICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4gICAgUGFn ZXMgICAgICAgICAgIDogMTQNCj4+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDItMTINCj4+ IA0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgdGhlIHJlcXVp cmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+ICAgIENoYWluaW5nIChTRkMpLg0K Pj4gDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4g DQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4gSW50ZXJuZXQtRHJhZnQgZGly ZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4gDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiANCj4gDQo+IC0tDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQo+IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0KPiANCj4g5pel5pys 6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+IOODjeODg+ODiOODr+ODvOOCr+OCteODvOODk+OC ueOCt+OCueODhuODoOeglOeptuaJgA0KPiDou6LpgIHjgrXjg7zjg5Pjgrnln7rnm6Tjg5fjg63j grjjgqfjgq/jg4gNCj4g6Lui6YCB44K144O844OT44K55Yi25b6hRFANCj4gDQo+IOOAkjE4MC04 NTg144CA5p2x5Lqs6YO95q2m6JS16YeO5biC57eR55S6My05LTExDQo+IFRFTDogMDQyMi01OS0z NDg2DQo+IEUtTUFJTDogaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcA0KPiAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBz ZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo= From nobody Mon Feb 24 15:12:29 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B151A0307 for ; Mon, 24 Feb 2014 15:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.197 X-Spam-Level: *** X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCpA9mT0jfMB for ; Mon, 24 Feb 2014 15:12:24 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 98F881A02E4 for ; Mon, 24 Feb 2014 15:12:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,537,1389704400"; d="scan'208";a="185368171" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 25 Feb 2014 10:12:09 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7359"; a="254422755" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 25 Feb 2014 10:12:08 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 25 Feb 2014 10:12:00 +1100 From: "Pham, Chuong D" To: Ron Parker , =?utf-8?B?5pys6ZaT5L+K5LuL?= Date: Tue, 25 Feb 2014 10:11:59 +1100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8xh0FGxlIHvY6jRfaEniTWM93LqQAK5MVg Message-ID: <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> In-Reply-To: <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qhn2J2oG2RvuLLSxd2LZZQ6LZbE Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 23:12:27 -0000 SGkgYWxsLA0KDQpJbiBNb2JpbGUsIHBlci1zdWJzY3JpYmVyIHZhbHVlLWFkZGVkLXNlcnZpY2Ug KFZBUykgaXMgdmFsdWFibGUgYW5kIGlzIGEgY3VsdHVyZSBvZiBwZXJzb25hbGlzYXRpb24gaS5l LiBhIHVzZXIgaXMgYSBzb2xlIG93bmVyIG9mIGEgZGV2aWNlLiBUbyBkYXRlIHdpdGggdGhlIGxl Z2FjeSBjaXJjdWl0LXN3aXRjaGVkIHZvaWNlLWNlbnRyaWMgbmV0d29yayBha2EgQ1Mgdm9pY2Us IHdlIGFscmVhZHkgaGF2ZSBwZXItc3Vic2NyaWJlciBWQVMgaW4gdGhlIGZvcm0gb2Ygc3VwcGxl bWVudGFyeSBzZXJ2aWNlcyBpLmUuIHZvaWNlIG1haWwsIGRpdmVyc2lvbiBldGMuIGFuZCBpbiB0 aGUgUGFja2V0IERhdGEgd29ybGQsIHRoZSBQQ1JGIGFyY2hpdGVjdHVyZSB3YXMgZGV2ZWxvcGVk IHdpdGggdGhhdCAocGVyLXN1YnNjcmliZXIgc2VydmljZSkgaW4gbWluZC4gV2hhdCBpcyBsYWNr aW5nIGF0IHRoZSBtb21lbnQgaXMgdGhlIHBlci1zdWJzY3JpYmVyIFNGQyBvbiB0aGUgR2kvU0dp IHVzZXIgcGxhbmUgY2FwYWJpbGl0eSB0byBtb25ldGl6ZSB3aXRoIFZBUyBhcyB3aGF0IHdlIGhh dmUgYmVlbiBkb2luZyB3aXRoIENTLg0KDQpJbiBteSBvcGluaW9uLCBpdCBpcyBhIHZlcnkgaW1w b3J0YW50IGFzcGVjdCBvZiBTRkMuIEkgYWdyZWUgdGhlcmUgd2lsbCBiZSBzY2FsYWJpbGl0eSBj aGFsbGVuZ2UgYnV0IHRoZSB2YWx1ZSBvZiB0aGlzIGNhcGFiaWxpdHkganVzdGlmaWVzIHRoZSBj aGFsbGVuZ2UuIFRoZSBzY2FsYWJpbGl0eSBhcyBSb24gaGFzIGluZGljYXRlZCwgd2lsbCBiZSBt b3JlIG9uIHRoZSAiY29udHJvbCBwbGFuZSIgd2hpY2ggbmVlZHMgdG8gYSkgaWRlbnRpZnkgdGhl IHVzZXIgYW5kIGIpZGV0ZXJtaW5lIHRoZSBTRnMgcmVxdWlyZWQgYW5kIGMpc2lnbmFsIHRoZSBu ZXR3b3JrIGFuZCB0aGUgU0ZzIGZvciBTRkMuIFRoZSBNb2JpbGUgbmV0d29yayB3aXRoIHBlcnNv bmFsaXNhdGlvbiBjdWx0dXJlIGluIG1pbmQgaGFzIHBsZW50eSBvZiByZXNvdXJjZXMgZm9yIHRo ZSBTRkMgdG8gbGV2ZXJhZ2UgZm9yIHBlci1zdWJzY3JpYmVycyBzZXJ2aWNlLg0KDQpUaGUgbnVt YmVyIG9mIFNGQ3MgbWF5IG5vdCBiZSBoaWdoIGFzIHRoZSBudW1iZXIgb2YgVkFTZXMgbm9ybWFs bHkgd2lsbCBiZSBsaW1pdGVkIHRvIGEgc21hbGwgbnVtYmVyLiBXZSBkb24ndCBuZWVkIHBlci1z dWJzY3JpYmVyIFNGQyBidXQgYSBjYXBhYmlsaXR5IHRvIG1hcCBlYWNoIHN1YnNjcmliZXIgdG8g b25lIG9mIHRoZSBTRkMgaW4gdGhlIFZBUyBjYXRhbG9ndWUuIFRha2UgUm9uJ3MgZXhhbXBsZSBv ZiBhIHBlci1zdWJzY3JpYmVyJ3MgZmlyZXdhbGwuIEEgc2VydmljZSBwcm92aWRlciB3b3VsZCBu b3QgbGlrZWx5IHRvIG9mZmVyIGEgcGVyLXN1YnNjcmliZXIgbmV0d29yay1iYXNlZCBGVyB3aGVy ZSBhIHN1YnNjcmliZXIgY2FuIHVzZSBhIHBvcnRhbCB0byBjb25maWd1cmUgdGhlIHdheSB0aGV5 IGNhbiBkbyBvbiBhIFJHIG9yIGEgc29mdHdhcmUgRlcgb24gYSBQQy4gSXQgd291bGQgbGlrZWx5 IG9mZmVyIGEgZ2VuZXJpYyBHaSBzdGF0ZWZ1bCBmaXJld2FsbCBzbyB0aGF0IHVuc29saWNpdGVk IHRyYWZmaWMgY2Fubm90IGJlIHNlbnQgdG8gdGhlIFVFLiAgDQoNCkFzIHdlIGFyZSBsb29raW5n IGF0IGEgUmVxdWlyZW1lbnRzIGRvY3VtZW50IGhlcmUsIHdlIHNob3VsZCBmb2N1cyBtb3JlIG9u IHRoZSByZXF1aXJlbWVudHMgKGluIHRoaXMgZG9jdW1lbnQpIHJhdGhlciB0aGFuIGdvIGludG8g c29sdXRpb24gbW9kZSBhbmQgcGVyaGFwcyB0aGluayBhaGVhZCB0aGF0IGl0IG1heSBiZSB0b28g aGFyZCB0aGVuIGJhY2sgb3V0IHRoZSByZXF1aXJlbWVudHMuDQoNCkkgZnVsbHkgYWdyZWUsIHNj YWxhYmlsaXR5IHdpbGwgbGlrZWx5IGluZmx1ZW5jZSBhcmNoaXRlY3R1cmUgKHNvbHV0aW9uIG1v ZGUpIHNvIGl0IG5lZWRzIHRvIGJlIGluY2x1ZGVkLg0KDQpSZWdhcmRzLA0KQ2h1b25nDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXSANClNlbnQ6IE1vbmRheSwgMjQgRmVicnVhcnkg MjAxNCAyOjM5IFBNDQpUbzog5pys6ZaT5L+K5LuLDQpDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246 IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpTaHVuc3VrZS1zYW4s DQoNCldoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9yIG1vcmUg U0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBpc24ndCBwcmFj dGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBhc3BlY3Qgb2Yg dGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3VzdG9taXplZCBm aXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBvbmx5IG9u ZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2FsIHBvbGljeSBl dmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBi ZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3b3VsZCBiZSB0 byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9tIHRoZSBw YWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtlIExEQVAgb3Ig UkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBkZXRlcm1pbmUg d2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNzaWZpZXIgdG8g YWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2VydmljZSBo ZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQgdGhlIGZpcmV3 YWxsLiANCg0KSWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0aGF0IHRoZSBm aXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3aGVyZSB0aGVyZSBh cmUgcGVyaGFwcyAxMHMgb2YgZ3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFwcHJvYWNoIGlzIHRv IG1vZGVsIHRoZSBmaXJld2FsbCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmlyZXdhbGwgcGVyIGZp cmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUgc2FtZSBtYWNo aW5lIG9yIFZNKSBhbmQgdG8gY29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidzIHBvbGljeSBhY2Nv cmRpbmdseS4gDQoNCiAgIFJvbg0KDQoNCj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDowNCBQTSwg IuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPiAN Cj4gSGkgTWVkLA0KPiANCj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJIGFzc3VtZWQgc29t ZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4gY29udGludWUgdGhl IGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMuDQo+ICNJIHdvcmsg d2l0aCBLLk5haXRvLCBjby1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQgYW5kIHRoaW5rIHNj YWxhYmlsaXR5IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNpZGVyLg0KPiANCj4g QXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0aGUgbWFuYWdlbWVudCBt ZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQgcmVxdWlyZSBoaWdoIHNj YWxhYmlsaXR5Lg0KPiANCj4gMS4gVGhlIGNhc2UgdGhhdCB0aGUgdHlwZXMgb2YgU0YgaW5jcmVh c2U6DQo+IEkgYXNzdW1lZCB0aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmlj IGlzIGZvbGxvd2luZzsNCj4gIC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNw ZWNpZmljIFNGQyBmb3IgZWFjaCBzZXJ2aWNlLA0KPiAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9y IHJlZ2lvbiwNCj4gIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNw ZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPiAgICBzdWJzY3JpYmVyIChlLmcuIHBlciBJUCBhZGRy ZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4gIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMgYXBwbGllZCB3 aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPiDjgIDjgIBhbmQgb2JqZWN0 aXZlIChlLmcuIHByZSBVUkwsIGFwcGxpY2F0aW9uIGV0LmFsKS4NCj4gDQo+IFNvbWUgb2YgdGhl IHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVyIG9mIHN1YnNjcmliZXJzLCBh bmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBzZXZlcmFsIHRlbnMgb3IgaHVu ZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBvZiBwZXItc3Vic2NyaWJlciBh bmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBpbmNyZWFzZSBleHBsb3NpdmVs eS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQgaW4gdGhlIGNhc2UgdGhhdCB0 aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNlcihlLmcuIHZDUEUgYXMgdXNl ciBjdXN0b21pemVkKS4NCj4gDQo+IEFsc28sIGluIGNhc2Ugb2YgZ3JvdXBpbmcsIGlmIHRoZXJl IGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMgYXJlIGRpZmZlcmVudCwgc3VjaCBh cyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJlZ2lvbiwgdGhlIG51bWJlciBvZiBT RkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBwb2xpY3kg Zm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+IA0KPiAyLiBUaGUgY2FzZSB0aGF0IHRo ZXJlIGFyZSBzb21lIFNGcyB0aGF0IG11c3QgYmUgY2xhc3NpZmllZCBmb3IgZWFjaCBpbnN0YW5j ZToNCj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBmdW5jdGlvbiBp biB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5z dGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+IFRoZSBTRnMg dGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBiZSBkaWZmZXJlbnRp YXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNhY2hlLCBhbmQgVmlk ZW8tT3B0aW1pemVyKS4NCj4gDQo+IElNSE8scmVxdWlyZW1lbnRzIGZvciBzY2FsYWJpbGl0eSB3 aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIgZm9ybWF0Lg0KPiANCj4gVGhh bmtzLA0KPiANCj4gU2h1bnN1a2UNCj4gDQo+ICgyMDE0LzAyLzEyIDE4OjQ5KSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+IERlYXIgYWxsLA0KPj4gDQo+PiBUaGlzIG5l dyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2VudGF0aXZlcy4NCj4+ IA0KPj4gVGhlIGRpZmYgY2FuIGJlIHRyYWNrZWQgaGVyZTogDQo+PiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMSYNCj4+ IGRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1 aXJlbWVudHMtMDMNCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+PiANCj4+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCANCj4+IGRlIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTIgZsOpdnJpZXIgMjAxNCAxMDo0NiDDgCANCj4+ IDogaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlvbjogDQo+PiBkcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+IA0KPj4gDQo+PiBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQo+PiANCj4+IA0KPj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1 aXJlbWVudHMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCj4+ICAgICAgICAgQXV0aG9y cyAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFu bG9uZyBKaWFuZw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4gICAgUGFnZXMgICAgICAgICAg IDogMTQNCj4+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDItMTINCj4+IA0KPj4gQWJzdHJh Y3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3Ig dGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+ICAgIENoYWluaW5nIChTRkMpLg0KPj4gDQo+PiANCj4+ IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItc2Zj LXJlcXVpcmVtZW50cy8NCj4+IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRh aXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiANCj4+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIA0KPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0K Pj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiANCj4g DQo+IC0tDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0KPiANCj4g5pel5pys6Zu75L+h6Zu76Kmx 5qCq5byP5Lya56S+DQo+IOODjeODg+ODiOODr+ODvOOCr+OCteODvOODk+OCueOCt+OCueODhuOD oOeglOeptuaJgA0KPiDou6LpgIHjgrXjg7zjg5Pjgrnln7rnm6Tjg5fjg63jgrjjgqfjgq/jg4gN Cj4g6Lui6YCB44K144O844OT44K55Yi25b6hRFANCj4gDQo+IOOAkjE4MC04NTg144CA5p2x5Lqs 6YO95q2m6JS16YeO5biC57eR55S6My05LTExDQo+IFRFTDogMDQyMi01OS0zNDg2DQo+IEUtTUFJ TDogaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcA0KPiAqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Mon Feb 24 15:36:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B575A1A02CC for ; Mon, 24 Feb 2014 15:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.497 X-Spam-Level: * X-Spam-Status: No, score=1.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, 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 7efhqkvbX_KE for ; Mon, 24 Feb 2014 15:36:10 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E71A01C0 for ; Mon, 24 Feb 2014 15:36:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C26611C06A8; Mon, 24 Feb 2014 15:36:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-121.clppva.east.verizon.net [70.106.134.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 35A151C0545; Mon, 24 Feb 2014 15:36:08 -0800 (PST) Message-ID: <530BD76B.709@joelhalpern.com> Date: Mon, 24 Feb 2014 18:36:11 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Pham, Chuong D" , Ron Parker , =?UTF-8?B?5pys6ZaT5L+K5LuL?= References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0o6ffgNa4mxiQiKWEq-fjkHAI58 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 23:36:11 -0000 Being able to give each subscriber the services they want is clearly necessary for any mobile, residential, or even business service in this environment. But that does not mean we should want or expect that the number of different service chains is on the same order as the number of users. One of the advantages of ingress classification is that many users can use the same service chain. Yours, Joel On 2/24/14, 6:11 PM, Pham, Chuong D wrote: > Hi all, > > In Mobile, per-subscriber value-added-service (VAS) is valuable and is a culture of personalisation i.e. a user is a sole owner of a device. To date with the legacy circuit-switched voice-centric network aka CS voice, we already have per-subscriber VAS in the form of supplementary services i.e. voice mail, diversion etc. and in the Packet Data world, the PCRF architecture was developed with that (per-subscriber service) in mind. What is lacking at the moment is the per-subscriber SFC on the Gi/SGi user plane capability to monetize with VAS as what we have been doing with CS. > > In my opinion, it is a very important aspect of SFC. I agree there will be scalability challenge but the value of this capability justifies the challenge. The scalability as Ron has indicated, will be more on the "control plane" which needs to a) identify the user and b)determine the SFs required and c)signal the network and the SFs for SFC. The Mobile network with personalisation culture in mind has plenty of resources for the SFC to leverage for per-subscribers service. > > The number of SFCs may not be high as the number of VASes normally will be limited to a small number. We don't need per-subscriber SFC but a capability to map each subscriber to one of the SFC in the VAS catalogue. Take Ron's example of a per-subscriber's firewall. A service provider would not likely to offer a per-subscriber network-based FW where a subscriber can use a portal to configure the way they can do on a RG or a software FW on a PC. It would likely offer a generic Gi stateful firewall so that unsolicited traffic cannot be sent to the UE. > > As we are looking at a Requirements document here, we should focus more on the requirements (in this document) rather than go into solution mode and perhaps think ahead that it may be too hard then back out the requirements. > > I fully agree, scalability will likely influence architecture (solution mode) so it needs to be included. > > Regards, > Chuong > > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, 24 February 2014 2:39 PM > To: 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Shunsuke-san, > > While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. > > If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. > > Ron > > >> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >> >> Hi Med, >> >> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >> >> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >> >> 1. The case that the types of SF increase: >> I assumed that the unit of applying SFC to traffic is following; >> - grouping: traffic is applied with specific SFC for each service, >> enterprise customer or region, >> - per-subscriber: traffic is applied with specific SFC for each　 >> subscriber (e.g. per IP address, VLAN ID et.al), >> - per-flow: traffic is applied with specific SFC for each subscriber, >> 　　and objective (e.g. pre URL, application et.al). >> >> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >> >> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >> >> 2. The case that there are some SFs that must be classified for each instance: >> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >> >> IMHO,requirements for scalability will affect SFC architecture and header format. >> >> Thanks, >> >> Shunsuke >> >> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>> Dear all, >>> >>> This new version integrates inputs from NTT representatives. >>> >>> The diff can be tracked here: >>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01& >>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 À >>> : i-d-announce@ietf.org Objet : I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Ron Parker >>> Carlos Pignataro >>> Kengo Naito >>> Filename : draft-boucadair-sfc-requirements-03.txt >>> Pages : 14 >>> Date : 2014-02-12 >>> >>> Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining (SFC). >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> -- >> ******************************************** >> 本間 俊介 (Homma Shunsuke) >> >> 日本電信電話株å¼ä¼šç¤¾ >> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >> 転é€ã‚µãƒ¼ãƒ“ス制御DP >> >> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >> TEL: 0422-59-3486 >> E-MAIL: homma.shunsuke@lab.ntt.co.jp >> ******************************************** >> >> _______________________________________________ >> 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 Feb 24 15:41:17 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9EA1A030E for ; Mon, 24 Feb 2014 15:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.197 X-Spam-Level: *** X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j91Om0YA1axX for ; Mon, 24 Feb 2014 15:41:13 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id D97C21A01D5 for ; Mon, 24 Feb 2014 15:41:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,537,1389704400"; d="scan'208";a="175938422" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 25 Feb 2014 10:41:13 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7359"; a="201213016" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 25 Feb 2014 10:41:11 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 25 Feb 2014 10:41:11 +1100 From: "Pham, Chuong D" To: "Joel M. Halpern" , Ron Parker , =?utf-8?B?5pys6ZaT5L+K5LuL?= Date: Tue, 25 Feb 2014 10:41:09 +1100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8xuTZtYGm+Y+DdR8OZsDXcLO6XTAAAFR7A Message-ID: <5602569641FB314FB4D9AD5659D41B9C2C14E78FF8@WSMSG3154V.srv.dir.telstra.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> <530BD76B.709@joelhalpern.com> In-Reply-To: <530BD76B.709@joelhalpern.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1yILUz9_qqOLm6ZXt-FOUw9DuzY Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 23:41:16 -0000 Sm9lbCwNCkZ1bGx5IGFncmVlLiBJIHNhaWQgdGhlIHNhbWUgYnV0IHJlYWRpbmcgbXkgbWVzc2Fn ZSBhZ2FpbiwgSSByZWFsaXNlZCB0aGF0IEkgbWlnaHQgaGF2ZSBjYXVzZWQgY29uZnVzaW9uLiBB Z3JlZSB0aGF0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBjaGFpbnMgaXMgbmVlZGVkIHRvIGJlIGxp bWl0ZWQgYnV0IGNsYXNzaWZ5aW5nIGVhY2ggc3Vic2NyaWJlciBpbnRvIHRoZXNlIHNlcnZpY2Ug Y2hhaW5zIGlzIGFuIGltcG9ydGFudCByZXF1aXJlbWVudC4NClJlZ2FyZHMsDQpDaHVvbmcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRv OmptaEBqb2VsaGFscGVybi5jb21dIA0KU2VudDogVHVlc2RheSwgMjUgRmVicnVhcnkgMjAxNCAx MDozNiBBTQ0KVG86IFBoYW0sIENodW9uZyBEOyBSb24gUGFya2VyOyDmnKzplpPkv4rku4sNCkNj OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMt MDMudHh0DQoNCkJlaW5nIGFibGUgdG8gZ2l2ZSBlYWNoIHN1YnNjcmliZXIgdGhlIHNlcnZpY2Vz IHRoZXkgd2FudCBpcyBjbGVhcmx5IG5lY2Vzc2FyeSBmb3IgYW55IG1vYmlsZSwgcmVzaWRlbnRp YWwsIG9yIGV2ZW4gYnVzaW5lc3Mgc2VydmljZSBpbiB0aGlzIGVudmlyb25tZW50Lg0KDQpCdXQg dGhhdCBkb2VzIG5vdCBtZWFuIHdlIHNob3VsZCB3YW50IG9yIGV4cGVjdCB0aGF0IHRoZSBudW1i ZXIgb2YgZGlmZmVyZW50IHNlcnZpY2UgY2hhaW5zIGlzIG9uIHRoZSBzYW1lIG9yZGVyIGFzIHRo ZSBudW1iZXIgb2YgdXNlcnMuIA0KT25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIGluZ3Jlc3MgY2xh c3NpZmljYXRpb24gaXMgdGhhdCBtYW55IHVzZXJzIGNhbiB1c2UgdGhlIHNhbWUgc2VydmljZSBj aGFpbi4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDIvMjQvMTQsIDY6MTEgUE0sIFBoYW0sIENodW9u ZyBEIHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IEluIE1vYmlsZSwgcGVyLXN1YnNjcmliZXIgdmFs dWUtYWRkZWQtc2VydmljZSAoVkFTKSBpcyB2YWx1YWJsZSBhbmQgaXMgYSBjdWx0dXJlIG9mIHBl cnNvbmFsaXNhdGlvbiBpLmUuIGEgdXNlciBpcyBhIHNvbGUgb3duZXIgb2YgYSBkZXZpY2UuIFRv IGRhdGUgd2l0aCB0aGUgbGVnYWN5IGNpcmN1aXQtc3dpdGNoZWQgdm9pY2UtY2VudHJpYyBuZXR3 b3JrIGFrYSBDUyB2b2ljZSwgd2UgYWxyZWFkeSBoYXZlIHBlci1zdWJzY3JpYmVyIFZBUyBpbiB0 aGUgZm9ybSBvZiBzdXBwbGVtZW50YXJ5IHNlcnZpY2VzIGkuZS4gdm9pY2UgbWFpbCwgZGl2ZXJz aW9uIGV0Yy4gYW5kIGluIHRoZSBQYWNrZXQgRGF0YSB3b3JsZCwgdGhlIFBDUkYgYXJjaGl0ZWN0 dXJlIHdhcyBkZXZlbG9wZWQgd2l0aCB0aGF0IChwZXItc3Vic2NyaWJlciBzZXJ2aWNlKSBpbiBt aW5kLiBXaGF0IGlzIGxhY2tpbmcgYXQgdGhlIG1vbWVudCBpcyB0aGUgcGVyLXN1YnNjcmliZXIg U0ZDIG9uIHRoZSBHaS9TR2kgdXNlciBwbGFuZSBjYXBhYmlsaXR5IHRvIG1vbmV0aXplIHdpdGgg VkFTIGFzIHdoYXQgd2UgaGF2ZSBiZWVuIGRvaW5nIHdpdGggQ1MuDQo+DQo+IEluIG15IG9waW5p b24sIGl0IGlzIGEgdmVyeSBpbXBvcnRhbnQgYXNwZWN0IG9mIFNGQy4gSSBhZ3JlZSB0aGVyZSB3 aWxsIGJlIHNjYWxhYmlsaXR5IGNoYWxsZW5nZSBidXQgdGhlIHZhbHVlIG9mIHRoaXMgY2FwYWJp bGl0eSBqdXN0aWZpZXMgdGhlIGNoYWxsZW5nZS4gVGhlIHNjYWxhYmlsaXR5IGFzIFJvbiBoYXMg aW5kaWNhdGVkLCB3aWxsIGJlIG1vcmUgb24gdGhlICJjb250cm9sIHBsYW5lIiB3aGljaCBuZWVk cyB0byBhKSBpZGVudGlmeSB0aGUgdXNlciBhbmQgYilkZXRlcm1pbmUgdGhlIFNGcyByZXF1aXJl ZCBhbmQgYylzaWduYWwgdGhlIG5ldHdvcmsgYW5kIHRoZSBTRnMgZm9yIFNGQy4gVGhlIE1vYmls ZSBuZXR3b3JrIHdpdGggcGVyc29uYWxpc2F0aW9uIGN1bHR1cmUgaW4gbWluZCBoYXMgcGxlbnR5 IG9mIHJlc291cmNlcyBmb3IgdGhlIFNGQyB0byBsZXZlcmFnZSBmb3IgcGVyLXN1YnNjcmliZXJz IHNlcnZpY2UuDQo+DQo+IFRoZSBudW1iZXIgb2YgU0ZDcyBtYXkgbm90IGJlIGhpZ2ggYXMgdGhl IG51bWJlciBvZiBWQVNlcyBub3JtYWxseSB3aWxsIGJlIGxpbWl0ZWQgdG8gYSBzbWFsbCBudW1i ZXIuIFdlIGRvbid0IG5lZWQgcGVyLXN1YnNjcmliZXIgU0ZDIGJ1dCBhIGNhcGFiaWxpdHkgdG8g bWFwIGVhY2ggc3Vic2NyaWJlciB0byBvbmUgb2YgdGhlIFNGQyBpbiB0aGUgVkFTIGNhdGFsb2d1 ZS4gVGFrZSBSb24ncyBleGFtcGxlIG9mIGEgcGVyLXN1YnNjcmliZXIncyBmaXJld2FsbC4gQSBz ZXJ2aWNlIHByb3ZpZGVyIHdvdWxkIG5vdCBsaWtlbHkgdG8gb2ZmZXIgYSBwZXItc3Vic2NyaWJl ciBuZXR3b3JrLWJhc2VkIEZXIHdoZXJlIGEgc3Vic2NyaWJlciBjYW4gdXNlIGEgcG9ydGFsIHRv IGNvbmZpZ3VyZSB0aGUgd2F5IHRoZXkgY2FuIGRvIG9uIGEgUkcgb3IgYSBzb2Z0d2FyZSBGVyBv biBhIFBDLiBJdCB3b3VsZCBsaWtlbHkgb2ZmZXIgYSBnZW5lcmljIEdpIHN0YXRlZnVsIGZpcmV3 YWxsIHNvIHRoYXQgdW5zb2xpY2l0ZWQgdHJhZmZpYyBjYW5ub3QgYmUgc2VudCB0byB0aGUgVUUu DQo+DQo+IEFzIHdlIGFyZSBsb29raW5nIGF0IGEgUmVxdWlyZW1lbnRzIGRvY3VtZW50IGhlcmUs IHdlIHNob3VsZCBmb2N1cyBtb3JlIG9uIHRoZSByZXF1aXJlbWVudHMgKGluIHRoaXMgZG9jdW1l bnQpIHJhdGhlciB0aGFuIGdvIGludG8gc29sdXRpb24gbW9kZSBhbmQgcGVyaGFwcyB0aGluayBh aGVhZCB0aGF0IGl0IG1heSBiZSB0b28gaGFyZCB0aGVuIGJhY2sgb3V0IHRoZSByZXF1aXJlbWVu dHMuDQo+DQo+IEkgZnVsbHkgYWdyZWUsIHNjYWxhYmlsaXR5IHdpbGwgbGlrZWx5IGluZmx1ZW5j ZSBhcmNoaXRlY3R1cmUgKHNvbHV0aW9uIG1vZGUpIHNvIGl0IG5lZWRzIHRvIGJlIGluY2x1ZGVk Lg0KPg0KPiBSZWdhcmRzLA0KPiBDaHVvbmcNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3 b3Jrcy5jb21dDQo+IFNlbnQ6IE1vbmRheSwgMjQgRmVicnVhcnkgMjAxNCAyOjM5IFBNDQo+IFRv OiDmnKzplpPkv4rku4sNCj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IA0KPiBkcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4NCj4gU2h1bnN1a2Utc2FuLA0KPg0K PiBXaGlsZSBhIHRoZW9yZXRpY2FsIGNhc2UgY2FuIGJlIG1hZGUgZm9yIG9uZSBvciBtb3JlIFNG Q3MgcGVyIHN1YnNjcmliZXIsIGZvciByZWFzb25zIHlvdSBzdGF0ZSwgaXQgaXNuJ3QgcHJhY3Rp Y2FsLiAgQnV0LCB0aGVyZSBpcyBhbm90aGVyIHdheSB0byB2aWV3IHRoaXMgYXNwZWN0IG9mIHRo ZSBwcm9ibGVtLiAgTGV0J3MgdGFrZSB5b3VyIHBlci1zdWJzY3JpYmVyIGN1c3RvbWl6ZWQgZmly ZXdhbGwgYXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4gIElmIHRoZXJlIHdlcmUgb25seSBvbmUg ZmlyZXdhbGwsIGluc3RlYWQsIGFuZCBpdCB3YXMgY2FwYWJsZSBvZiBsb2NhbCBwb2xpY3kgZXZh bHVhdGlvbiBiYXNlZCBvbiBzdWJzY3JpYmVyLCB0aGUgbnVtYmVyIG9mIFNGQ3Mgd291bGQgYmUg dmFzdGx5IHJlZHVjZWQuICAgT25lIHdheSBmb3IgdGhhdCB0byBoYXBwZW4gd291bGQgYmUgdG8g c2ltcGx5IHVzZSB0aGUgc291cmNlL2Rlc3RpbmF0aW9uIElQIGFkZHJlc3MgZnJvbSB0aGUgcGFj a2V0IGFuZCBzb21lIG91dCBvZiBiYW5kIGxvb2t1cCBtZWNoYW5pc20gbGlrZSBMREFQIG9yIFJB RElVUyBhdCB0aGUgZmlyZXdhbGwuICAgIEFub3RoZXIgYXBwcm9hY2ggdG8gZGV0ZXJtaW5lIHdo byB0aGUgc3Vic2NyaWJlciBpcyB3b3VsZCBiZSBmb3IgdGhlIFNGQyBjbGFzc2lmaWVyIHRvIGFk ZCBhIGRpc3RpbmN0IHN1YnNjcmliZXIgaWQgYXMgbWV0YWRhdGEgdG8gdGhlIHNlcnZpY2UgaGVh ZGVyIChlZywgYW4gSU1TSSkgYW5kIHN0aWxsIHVzZSBMREFQLCBldGMuIGF0IHRoZSBmaXJld2Fs bC4NCj4NCj4gSWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0aGF0IHRoZSBm aXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3aGVyZSB0aGVyZSBh cmUgcGVyaGFwcyAxMHMgb2YgZ3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFwcHJvYWNoIGlzIHRv IG1vZGVsIHRoZSBmaXJld2FsbCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmlyZXdhbGwgcGVyIGZp cmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUgc2FtZSBtYWNo aW5lIG9yIFZNKSBhbmQgdG8gY29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidzIHBvbGljeSBhY2Nv cmRpbmdseS4NCj4NCj4gICAgIFJvbg0KPg0KPg0KPj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDow NCBQTSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3Rl Og0KPj4NCj4+IEhpIE1lZCwNCj4+DQo+PiBJbiB0ZXJtcyBvZiB5b3VyIGNvbW1lbnQsIEkgYXNz dW1lZCBzb21lIHVzZSBjYXNlcyBhYm91dCBzY2FsYWJpbGl0eSBzbyB0aGF0IHdlIGNhbiBjb250 aW51ZSB0aGUgZGlzY3Vzc2lvbiBhYm91dCBzY2FsYWJpbGl0eSBjb25zaWRlcmF0aW9ucy4NCj4+ ICNJIHdvcmsgd2l0aCBLLk5haXRvLCBjby1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQgYW5k IHRoaW5rIHNjYWxhYmlsaXR5IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNpZGVy Lg0KPj4NCj4+IEFzc3VtaW5nIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGZvbGxvd2luZywgdGhlIG1h bmFnZW1lbnQgbWVjaGFuaXNtIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIG1pZ2h0IHJlcXVp cmUgaGlnaCBzY2FsYWJpbGl0eS4NCj4+DQo+PiAxLiBUaGUgY2FzZSB0aGF0IHRoZSB0eXBlcyBv ZiBTRiBpbmNyZWFzZToNCj4+IEkgYXNzdW1lZCB0aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNG QyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4+ICAgLSBncm91cGluZzogdHJhZmZpYyBpcyBh cHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBlYWNoIHNlcnZpY2UsDQo+PiAgICAgZW50ZXJw cmlzZSBjdXN0b21lciBvciByZWdpb24sDQo+PiAgIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMg aXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPj4gICAgIHN1YnNjcmli ZXIgKGUuZy4gcGVyIElQIGFkZHJlc3MsIFZMQU4gSUQgZXQuYWwpLA0KPj4gICAtIHBlci1mbG93 OiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc3Vic2NyaWJl ciwNCj4+IOOAgOOAgGFuZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQu YWwpLg0KPj4NCj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMg bnVtYmVyIG9mIHN1YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1 cCB0byBzZXZlcmFsIHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBj YXNlcyBvZiBwZXItc3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBt aWdodCBpbmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBu ZWVkZWQgaW4gdGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVh Y2ggdXNlcihlLmcuIHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4+DQo+PiBBbHNvLCBpbiBj YXNlIG9mIGdyb3VwaW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3NlIHBvbGlj aWVzIGFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIgYW5kIHBl ciByZWdpb24sIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBGaXJld2Fs bHMgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9tZXIpLg0K Pj4NCj4+IDIuIFRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIHRoYXQgbXVzdCBiZSBj bGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlOg0KPj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBT RnMgd2l0aCB0aGUgc2FtZSBmdW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0 IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMg bWlnaHQgaW5jcmVhc2UuDQo+PiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBzdGF0ZWZ1bCB0cmFmZmlj IGFyZSBuZWVkZWQgdG8gYmUgZGlmZmVyZW50aWF0ZWQgcGVyIGluc3RhbmNlIChlLmcuIEZpcmV3 YWxsLCBDb250ZW50cy1DYWNoZSwgYW5kIFZpZGVvLU9wdGltaXplcikuDQo+Pg0KPj4gSU1ITyxy ZXF1aXJlbWVudHMgZm9yIHNjYWxhYmlsaXR5IHdpbGwgYWZmZWN0IFNGQyBhcmNoaXRlY3R1cmUg YW5kIGhlYWRlciBmb3JtYXQuDQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IFNodW5zdWtlDQo+Pg0K Pj4gKDIwMTQvMDIvMTIgMTg6NDkpLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3Rl Og0KPj4+IERlYXIgYWxsLA0KPj4+DQo+Pj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVzIGlu cHV0cyBmcm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+Pj4NCj4+PiBUaGUgZGlmZiBjYW4gYmUg dHJhY2tlZCBoZXJlOg0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAxDQo+Pj4gJg0KPj4+IGRpZmZ0eXBlPS0taHRt bCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+ Pg0KPj4+IENoZWVycywNCj4+PiBNZWQNCj4+Pg0KPj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPj4+IERlIDogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgDQo+Pj4gZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVu dm95w6kgOiBtZXJjcmVkaSAxMiBmw6l2cmllciAyMDE0IDEwOjQ2IA0KPj4+IMOADQo+Pj4gOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0KPj4+IGRyYWZ0LWJvdWNh ZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+DQo+Pj4NCj4+PiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQo+Pj4NCj4+Pg0KPj4+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJlcXVp cmVtZW50cyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZw0KPj4+ICAgICAgICAgIEF1dGhv cnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IFl1YW5sb25nIEppYW5nDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtl cg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBLZW5nbyBOYWl0bw0KPj4+ICAgICBGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+PiAgICAg UGFnZXMgICAgICAgICAgIDogMTQNCj4+PiAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMi0x Mg0KPj4+DQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0 aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgU2VydmljZSBGdW5jdGlvbg0KPj4+ICAgICBDaGFpbmlu ZyAoU0ZDKS4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+Pg0KPj4+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+Pj4NCj4+ PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4g aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1 aXJlbWVudHMtMDMNCj4+Pg0KPj4+DQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+Pj4gc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPj4+DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZQ0KPj4+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sIG9yIA0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu dHh0DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5vcmcNCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+DQo+PiAtLQ0KPj4gKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IOacrOmWkyDkv4rk u4sgKEhvbW1hIFNodW5zdWtlKQ0KPj4NCj4+IOaXpeacrOmbu+S/oembu+ipseagquW8j+S8muek vg0KPj4g44ON44OD44OI44Ov44O844Kv44K144O844OT44K544K344K544OG44Og56CU56m25omA DQo+PiDou6LpgIHjgrXjg7zjg5Pjgrnln7rnm6Tjg5fjg63jgrjjgqfjgq/jg4gNCj4+IOi7oumA geOCteODvOODk+OCueWItuW+oURQDQo+Pg0KPj4g44CSMTgwLTg1ODXjgIDmnbHkuqzpg73mrabo lLXph47luILnt5HnlLozLTktMTENCj4+IFRFTDogMDQyMi01OS0zNDg2DQo+PiBFLU1BSUw6IGhv bW1hLnNodW5zdWtlQGxhYi5udHQuY28uanANCj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlz dA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4NCg== From nobody Mon Feb 24 15:45:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E571A0320 for ; Mon, 24 Feb 2014 15:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 P2W67HhsPXxV for ; Mon, 24 Feb 2014 15:45:23 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF491A031D for ; Mon, 24 Feb 2014 15:45:23 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 15:45:23 -0800 From: Ron Parker To: Chris Frederick , =?utf-8?B?5pys6ZaT5L+K5LuL?= Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYA== Date: Mon, 24 Feb 2014 23:45:22 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qGzqf2SZkNGumhJKEnIFY5PmiGw Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 23:45:26 -0000 VGhhbmtzLCBDaHJpcy4NCg0KSSBkbyB0aGluayB0aGVyZSBhcmUgbG90cyBvZiBlZmZpY2llbmNp ZXMgd2hlbiB0aGUgZmxvdyBsZWFybmVyIChjbGFzc2lmaWVyKSBhbmQgcG9saWN5IGV2YWx1YXRv ciAoUERQKSBhcmUgY28tbG9jYXRlZC4gICBIb3dldmVyLCBhcmNoaXRlY3R1cmFsbHksIEkgd291 bGRuJ3QgbWFuZGF0ZSB0aGF0IHRoZXkgYmUgY28tbG9jYXRlZC4gICANCg0KICAgIFJvbg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0 bzpjZnJlZGVyaWNrQHNhbmR2aW5lLmNvbV0gDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAy MDE0IDU6MjYgUE0NClRvOiBSb24gUGFya2VyOyDmnKzplpPkv4rku4sNCkNjOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbc2ZjXSBUUjog SS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQoNCkFn cmVlZC4NClRvIHJlc3RhdGUgdGhpcyBzbGlnaHRseSwgaWYgdGhlIFNGQyBzdGVlcmluZy9kZWNp c2lvbiBsb2N1cyBpcyBjYXBhYmxlIG9mIGV2YWx1YXRpbmcgbXVsdGlwbGUgb3J0aG9nb25hbCBw b2xpY3kgY29uZGl0aW9ucyB0aGVuIHRoaXMgaXNzdWUgaXMgb2J2aWF0ZWQ7IHN1YnNjcmliZXJz IGJlY29tZSBhbiBhZ2dyZWdhdGUgb2YgJ3doYXQgdGhleSBhcmUnICsgYXJlIG5vdCBzaW1wbHkg J3dobyB0aGV5IGFyZScuIA0KQXMgUm9uIHN0YXRlcywgdGhpcyBhd2FyZW5lc3MgbWF5IGJlIGRl cml2ZWQgZnJvbSBMREFQIGxvb2t1cCwgUkFESVVTLCBHeCwgcHJlLXByb3Zpc2lvbmVkIHJ1bGVz LCBldGMuDQpUbyBpbGx1c3RyYXRlIHcvIGFuIGV4YW1wbGUsIHdlIG1pZ2h0IHNheSBzb21ldGhp bmcgbGlrZSB0aGlzOg0KSWYgc3Vic2NyaWJlciBYIGlzIHVzaW5nIHlvdXR1YmUsIGFuZCBpcyBv biBhIGNvbmdlc3RlZCBjZWxsLCBhbmQgaXMgb24gYW4gaVBob25lLCBhbmQgaXMgaW4gdGhlICJH b2xkIFRpZXIiLCBhbmQsIGFuZCwgYW5kLCBhbmQsIGV0YywgdGhlbiB0aGUgY2hhaW4gY29uc2lz dHMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYSwgYiwgYW5kIGMuDQpUaGVyZSdzIG5vIG5lZWQgdG8g ZW50ZXIgYSBzdGF0aWMgU0ZDIHJ1bGUvY2hhaW4gZm9yIHN1YnNjcmliZXIgWCAob3IgYW55IHN1 YnNjcmliZXIpLiBJbiBmYWN0LCBpdCdzIG5vdCBkZXNpcmFibGUgYW55d2F5IGJlY2F1c2UgYWxs IG9mIHRoZSBhYm92ZSBjb25kaXRpb25zIG1heSBldmFsdWF0ZSB0byBUcnVlLCBzYXZlIG9uZSAo ImlzIG9uIGEgY29uZ2VzdGVkIGNlbGwiKSwgYW5kIHRoZSByZXN1bHRhbnQgY2hhaW4gbWlnaHQg YmUgYWx0ZXJlZCAocGVyaGFwcyB0byBieXBhc3MgYSB2aWRlbyBvcHRpbWl6YXRpb24gc2Vydmlj ZSBmdW5jdGlvbikuDQpUaGlzIGFsc28gZ29lcyB0byB0aGUgZWFybGllciBjb21tZW50cyBSb24g KyBJIG1hZGUgYWJvdXQgY29uc29saWRhdGluZyB0aGUgZmxvdyByZWNvZ25pdGlvbiArIGRlY2lz aW9uLW1ha2luZyBlbnRpdHkgaW4gYSBzaW5nbGUgKHN1aXRhYmx5IHBvbGljeS1hd2FyZSkgbm9k ZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgKyB0byBzY2FsZSBwcm9wZXJseS4gVGh4LCAvYw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQpTZW50OiBTdW5kYXksIEZlYnJ1 YXJ5IDIzLCAyMDE0IDEwOjM5IFBNDQpUbzog5pys6ZaT5L+K5LuLDQpDYzogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gVFI6IEkt RCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpTaHVu c3VrZS1zYW4sDQoNCldoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25l IG9yIG1vcmUgU0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBp c24ndCBwcmFjdGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBh c3BlY3Qgb2YgdGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3Vz dG9taXplZCBmaXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2Vy ZSBvbmx5IG9uZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2Fs IHBvbGljeSBldmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZD cyB3b3VsZCBiZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3 b3VsZCBiZSB0byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBm cm9tIHRoZSBwYWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtl IExEQVAgb3IgUkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBk ZXRlcm1pbmUgd2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNz aWZpZXIgdG8gYWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUg c2VydmljZSBoZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQg dGhlIGZpcmV3YWxsLiANCg0KSWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0 aGF0IHRoZSBmaXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3aGVy ZSB0aGVyZSBhcmUgcGVyaGFwcyAxMHMgb2YgZ3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFwcHJv YWNoIGlzIHRvIG1vZGVsIHRoZSBmaXJld2FsbCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmlyZXdh bGwgcGVyIGZpcmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUg c2FtZSBtYWNoaW5lIG9yIFZNKSBhbmQgdG8gY29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidzIHBv bGljeSBhY2NvcmRpbmdseS4gDQoNCiAgIFJvbg0KDQoNCj4gT24gRmViIDIzLCAyMDE0LCBhdCAx MDowNCBQTSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdy b3RlOg0KPiANCj4gSGkgTWVkLA0KPiANCj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJIGFz c3VtZWQgc29tZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4gY29u dGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMuDQo+ ICNJIHdvcmsgd2l0aCBLLk5haXRvLCBjby1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQgYW5k IHRoaW5rIHNjYWxhYmlsaXR5IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNpZGVy Lg0KPiANCj4gQXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0aGUgbWFu YWdlbWVudCBtZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQgcmVxdWly ZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPiANCj4gMS4gVGhlIGNhc2UgdGhhdCB0aGUgdHlwZXMgb2Yg U0YgaW5jcmVhc2U6DQo+IEkgYXNzdW1lZCB0aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0 byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4gIC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGll ZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzZXJ2aWNlLA0KPiAgICBlbnRlcnByaXNlIGN1 c3RvbWVyIG9yIHJlZ2lvbiwNCj4gIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGll ZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPiAgICBzdWJzY3JpYmVyIChlLmcuIHBl ciBJUCBhZGRyZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4gIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMg YXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPiDjgIDjgIBh bmQgb2JqZWN0aXZlIChlLmcuIHByZSBVUkwsIGFwcGxpY2F0aW9uIGV0LmFsKS4NCj4gDQo+IFNv bWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVyIG9mIHN1YnNj cmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBzZXZlcmFsIHRl bnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBvZiBwZXItc3Vi c2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBpbmNyZWFzZSBl eHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQgaW4gdGhlIGNh c2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNlcihlLmcuIHZD UEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4gDQo+IEFsc28sIGluIGNhc2Ugb2YgZ3JvdXBpbmcs IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMgYXJlIGRpZmZlcmVu dCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJlZ2lvbiwgdGhlIG51 bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZlcmVu dCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+IA0KPiAyLiBUaGUgY2Fz ZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyB0aGF0IG11c3QgYmUgY2xhc3NpZmllZCBmb3IgZWFj aCBpbnN0YW5jZToNCj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9y IGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+ IFRoZSBTRnMgdGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBiZSBk aWZmZXJlbnRpYXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNhY2hl LCBhbmQgVmlkZW8tT3B0aW1pemVyKS4NCj4gDQo+IElNSE8scmVxdWlyZW1lbnRzIGZvciBzY2Fs YWJpbGl0eSB3aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIgZm9ybWF0Lg0K PiANCj4gVGhhbmtzLA0KPiANCj4gU2h1bnN1a2UNCj4gDQo+ICgyMDE0LzAyLzEyIDE4OjQ5KSwg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+IERlYXIgYWxsLA0KPj4gDQo+ PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2VudGF0 aXZlcy4NCj4+IA0KPj4gVGhlIGRpZmYgY2FuIGJlIHRyYWNrZWQgaGVyZTogDQo+PiBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50 cy0wMSYNCj4+IGRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWly LXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+PiANCj4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBJLUQtQW5ub3VuY2UgW21haWx0bzpp LWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCANCj4+IGRlIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTIgZsOpdnJpZXIgMjAxNCAxMDo0 NiDDgA0KPj4gOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOiANCj4+ IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4gDQo+PiANCj4+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+IA0KPj4gDQo+PiAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IFJlcXVpcmVtZW50cyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZw0KPj4gICAgICAg ICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBDaHJpc3RpYW4gSmFjcXVlbmV0DQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIFl1YW5sb25nIEppYW5nDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbiBQYXJr ZXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybG9zIFBpZ25hdGFybw0KPj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBLZW5nbyBOYWl0bw0KPj4gICAgRmlsZW5hbWUgICAgICAg IDogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+PiAgICBQYWdlcyAg ICAgICAgICAgOiAxNA0KPj4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMi0xMg0KPj4gDQo+ PiBBYnN0cmFjdDoNCj4+ICAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUgcmVxdWlyZW1l bnRzIGZvciB0aGUgU2VydmljZSBGdW5jdGlvbg0KPj4gICAgQ2hhaW5pbmcgKFNGQykuDQo+PiAN Cj4+IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNh ZGFpci1zZmMtcmVxdWlyZW1lbnRzLw0KPj4gDQo+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+PiANCj4+IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+PiANCj4+ IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YgDQo+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+IEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQo+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciANCj4+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBz ZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+IA0KPiANCj4gLS0NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCj4g5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+IA0KPiDml6XmnKzpm7vk v6Hpm7voqbHmoKrlvI/kvJrnpL4NCj4g44ON44OD44OI44Ov44O844Kv44K144O844OT44K544K3 44K544OG44Og56CU56m25omADQo+IOi7oumAgeOCteODvOODk+OCueWfuuebpOODl+ODreOCuOOC p+OCr+ODiA0KPiDou6LpgIHjgrXjg7zjg5PjgrnliLblvqFEUA0KPiANCj4g44CSMTgwLTg1ODXj gIDmnbHkuqzpg73mrabolLXph47luILnt5HnlLozLTktMTENCj4gVEVMOiAwNDIyLTU5LTM0ODYN Cj4gRS1NQUlMOiBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwDQo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5n IGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg== From nobody Mon Feb 24 15:46:50 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583781A01D5 for ; Mon, 24 Feb 2014 15:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 2VRIZQYPVT_j for ; Mon, 24 Feb 2014 15:46:45 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3223C1A031E for ; Mon, 24 Feb 2014 15:46:45 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Mon, 24 Feb 2014 18:46:44 -0500 From: Chris Frederick To: Ron Parker , =?utf-8?B?5pys6ZaT5L+K5LuL?= Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSAAA3T7AAACnDhIA== Date: Mon, 24 Feb 2014 23:46:43 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FRiHVsCuPTxyAYjt29M0gpxBeMw Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 24 Feb 2014 23:46:48 -0000 WWVzLCBhZ3JlZWQgb24gdGhhdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXSANClNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNjo0NSBQTQ0KVG86IENocmlzIEZyZWRlcmlj azsg5pys6ZaT5L+K5LuLDQpDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFp ci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpUaGFua3MsIENocmlzLg0KDQpJIGRvIHRoaW5r IHRoZXJlIGFyZSBsb3RzIG9mIGVmZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNs YXNzaWZpZXIpIGFuZCBwb2xpY3kgZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhv d2V2ZXIsIGFyY2hpdGVjdHVyYWxseSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBj by1sb2NhdGVkLiAgIA0KDQogICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IENocmlzIEZyZWRlcmljayBbbWFpbHRvOmNmcmVkZXJpY2tAc2FuZHZpbmUuY29tXQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1OjI2IFBNDQpUbzogUm9uIFBhcmtlcjsg 5pys6ZaT5L+K5LuLDQpDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1z ZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpBZ3JlZWQuDQpUbyByZXN0YXRlIHRoaXMgc2xpZ2h0 bHksIGlmIHRoZSBTRkMgc3RlZXJpbmcvZGVjaXNpb24gbG9jdXMgaXMgY2FwYWJsZSBvZiBldmFs dWF0aW5nIG11bHRpcGxlIG9ydGhvZ29uYWwgcG9saWN5IGNvbmRpdGlvbnMgdGhlbiB0aGlzIGlz c3VlIGlzIG9idmlhdGVkOyBzdWJzY3JpYmVycyBiZWNvbWUgYW4gYWdncmVnYXRlIG9mICd3aGF0 IHRoZXkgYXJlJyArIGFyZSBub3Qgc2ltcGx5ICd3aG8gdGhleSBhcmUnLiANCkFzIFJvbiBzdGF0 ZXMsIHRoaXMgYXdhcmVuZXNzIG1heSBiZSBkZXJpdmVkIGZyb20gTERBUCBsb29rdXAsIFJBRElV UywgR3gsIHByZS1wcm92aXNpb25lZCBydWxlcywgZXRjLg0KVG8gaWxsdXN0cmF0ZSB3LyBhbiBl eGFtcGxlLCB3ZSBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2UgdGhpczoNCklmIHN1YnNjcmliZXIg WCBpcyB1c2luZyB5b3V0dWJlLCBhbmQgaXMgb24gYSBjb25nZXN0ZWQgY2VsbCwgYW5kIGlzIG9u IGFuIGlQaG9uZSwgYW5kIGlzIGluIHRoZSAiR29sZCBUaWVyIiwgYW5kLCBhbmQsIGFuZCwgYW5k LCBldGMsIHRoZW4gdGhlIGNoYWluIGNvbnNpc3RzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGEsIGIs IGFuZCBjLg0KVGhlcmUncyBubyBuZWVkIHRvIGVudGVyIGEgc3RhdGljIFNGQyBydWxlL2NoYWlu IGZvciBzdWJzY3JpYmVyIFggKG9yIGFueSBzdWJzY3JpYmVyKS4gSW4gZmFjdCwgaXQncyBub3Qg ZGVzaXJhYmxlIGFueXdheSBiZWNhdXNlIGFsbCBvZiB0aGUgYWJvdmUgY29uZGl0aW9ucyBtYXkg ZXZhbHVhdGUgdG8gVHJ1ZSwgc2F2ZSBvbmUgKCJpcyBvbiBhIGNvbmdlc3RlZCBjZWxsIiksIGFu ZCB0aGUgcmVzdWx0YW50IGNoYWluIG1pZ2h0IGJlIGFsdGVyZWQgKHBlcmhhcHMgdG8gYnlwYXNz IGEgdmlkZW8gb3B0aW1pemF0aW9uIHNlcnZpY2UgZnVuY3Rpb24pLg0KVGhpcyBhbHNvIGdvZXMg dG8gdGhlIGVhcmxpZXIgY29tbWVudHMgUm9uICsgSSBtYWRlIGFib3V0IGNvbnNvbGlkYXRpbmcg dGhlIGZsb3cgcmVjb2duaXRpb24gKyBkZWNpc2lvbi1tYWtpbmcgZW50aXR5IGluIGEgc2luZ2xl IChzdWl0YWJseSBwb2xpY3ktYXdhcmUpIG5vZGUgdG8gcmVkdWNlIHRoZSBjb21wbGV4aXR5ICsg dG8gc2NhbGUgcHJvcGVybHkuIFRoeCwgL2MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9u IFBhcmtlcg0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAyMywgMjAxNCAxMDozOSBQTQ0KVG86IOac rOmWk+S/iuS7iw0KQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2Zj LXJlcXVpcmVtZW50cy0wMy50eHQNCg0KU2h1bnN1a2Utc2FuLA0KDQpXaGlsZSBhIHRoZW9yZXRp Y2FsIGNhc2UgY2FuIGJlIG1hZGUgZm9yIG9uZSBvciBtb3JlIFNGQ3MgcGVyIHN1YnNjcmliZXIs IGZvciByZWFzb25zIHlvdSBzdGF0ZSwgaXQgaXNuJ3QgcHJhY3RpY2FsLiAgQnV0LCB0aGVyZSBp cyBhbm90aGVyIHdheSB0byB2aWV3IHRoaXMgYXNwZWN0IG9mIHRoZSBwcm9ibGVtLiAgTGV0J3Mg dGFrZSB5b3VyIHBlci1zdWJzY3JpYmVyIGN1c3RvbWl6ZWQgZmlyZXdhbGwgYXMgYSBoeXBvdGhl dGljYWwgZXhhbXBsZS4gIElmIHRoZXJlIHdlcmUgb25seSBvbmUgZmlyZXdhbGwsIGluc3RlYWQs IGFuZCBpdCB3YXMgY2FwYWJsZSBvZiBsb2NhbCBwb2xpY3kgZXZhbHVhdGlvbiBiYXNlZCBvbiBz dWJzY3JpYmVyLCB0aGUgbnVtYmVyIG9mIFNGQ3Mgd291bGQgYmUgdmFzdGx5IHJlZHVjZWQuICAg T25lIHdheSBmb3IgdGhhdCB0byBoYXBwZW4gd291bGQgYmUgdG8gc2ltcGx5IHVzZSB0aGUgc291 cmNlL2Rlc3RpbmF0aW9uIElQIGFkZHJlc3MgZnJvbSB0aGUgcGFja2V0IGFuZCBzb21lIG91dCBv ZiBiYW5kIGxvb2t1cCBtZWNoYW5pc20gbGlrZSBMREFQIG9yIFJBRElVUyBhdCB0aGUgZmlyZXdh bGwuICAgIEFub3RoZXIgYXBwcm9hY2ggdG8gZGV0ZXJtaW5lIHdobyB0aGUgc3Vic2NyaWJlciBp cyB3b3VsZCBiZSBmb3IgdGhlIFNGQyBjbGFzc2lmaWVyIHRvIGFkZCBhIGRpc3RpbmN0IHN1YnNj cmliZXIgaWQgYXMgbWV0YWRhdGEgdG8gdGhlIHNlcnZpY2UgaGVhZGVyIChlZywgYW4gSU1TSSkg YW5kIHN0aWxsIHVzZSBMREFQLCBldGMuIGF0IHRoZSBmaXJld2FsbC4gDQoNCklmIHRoZSBwcm9i bGVtIGlzIGNoYW5nZWQgc2xpZ2h0bHkgc28gdGhhdCB0aGUgZmlyZXdhbGwgcG9saWN5IGlzIHBl ciBncm91cCBvZiBzdWJzY3JpYmVycywgd2hlcmUgdGhlcmUgYXJlIHBlcmhhcHMgMTBzIG9mIGdy b3VwcywgdGhlbiB5ZXQgYW5vdGhlciBhcHByb2FjaCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwg YXMgYSBkaXN0aW5jdCBsb2dpY2FsIGZpcmV3YWxsIHBlciBmaXJld2FsbCBwb2xpY3kgc2V0ICh0 aGV5IGNvdWxkIGFsbCByZXNpZGUgaW4gdGhlIHNhbWUgbWFjaGluZSBvciBWTSkgYW5kIHRvIGNv b3JkaW5hdGUgdGhlIGNsYXNzaWZpZXIncyBwb2xpY3kgYWNjb3JkaW5nbHkuIA0KDQogICBSb24N Cg0KDQo+IE9uIEZlYiAyMywgMjAxNCwgYXQgMTA6MDQgUE0sICLmnKzplpPkv4rku4siIDxob21t YS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IElu IHRlcm1zIG9mIHlvdXIgY29tbWVudCwgSSBhc3N1bWVkIHNvbWUgdXNlIGNhc2VzIGFib3V0IHNj YWxhYmlsaXR5IHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFib3V0IHNj YWxhYmlsaXR5IGNvbnNpZGVyYXRpb25zLg0KPiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0 aG9yIG9mIHJlcXVpcmVtZW50IGRyYWZ0IGFuZCB0aGluayBzY2FsYWJpbGl0eSBpcyBvbmUgb2Yg aW1wb3J0YW50IHRoaW5ncyB0byBjb25zaWRlci4NCj4gDQo+IEFzc3VtaW5nIHRoZSB1c2UgY2Fz ZXMgbGlzdGVkIGZvbGxvd2luZywgdGhlIG1hbmFnZW1lbnQgbWVjaGFuaXNtIG9mIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5zIG1pZ2h0IHJlcXVpcmUgaGlnaCBzY2FsYWJpbGl0eS4NCj4gDQo+IDEu IFRoZSBjYXNlIHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPiBJIGFzc3VtZWQgdGhh dCB0aGUgdW5pdCBvZiBhcHBseWluZyBTRkMgdG8gdHJhZmZpYyBpcyBmb2xsb3dpbmc7DQo+ICAt IGdyb3VwaW5nOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2gg c2VydmljZSwNCj4gICAgZW50ZXJwcmlzZSBjdXN0b21lciBvciByZWdpb24sDQo+ICAtIHBlci1z dWJzY3JpYmVyOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2jj gIANCj4gICAgc3Vic2NyaWJlciAoZS5nLiBwZXIgSVAgYWRkcmVzcywgVkxBTiBJRCBldC5hbCks DQo+ICAtIHBlci1mbG93OiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9y IGVhY2ggc3Vic2NyaWJlciwNCj4g44CA44CAYW5kIG9iamVjdGl2ZSAoZS5nLiBwcmUgVVJMLCBh cHBsaWNhdGlvbiBldC5hbCkuDQo+IA0KPiBTb21lIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBo YXZlIGVub3Jtb3VzIG51bWJlciBvZiBzdWJzY3JpYmVycywgYW5kIHRoZSBudW1iZXIgb2Ygc3Vi c2NyaWJlcnMgaXMgdXAgdG8gc2V2ZXJhbCB0ZW5zIG9yIGh1bmRyZWRzIG9mIG1pbGxpb24uIFRo ZXJlZm9yZSwgaW4gY2FzZXMgb2YgcGVyLXN1YnNjcmliZXIgYW5kIHBlci1mbG93LCB0aGUgbnVt YmVyIG9mIFNGQ3MgbWlnaHQgaW5jcmVhc2UgZXhwbG9zaXZlbHkuIFBlci1zdWJzY3JpYmVyIFNG Q3Mgd291bGQgYmUgbmVlZGVkIGluIHRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIGRl ZGljYXRlZCB0byBlYWNoIHVzZXIoZS5nLiB2Q1BFIGFzIHVzZXIgY3VzdG9taXplZCkuDQo+IA0K PiBBbHNvLCBpbiBjYXNlIG9mIGdyb3VwaW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBz IHdob3NlIHBvbGljaWVzIGFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3Vz dG9tZXIgYW5kIHBlciByZWdpb24sIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAo ZS5nLiBGaXJld2FsbHMgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2Ug Y3VzdG9tZXIpLg0KPiANCj4gMi4gVGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgdGhh dCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5zdGFuY2U6DQo+IEluIGNhc2UgdGhhdCB0 aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNhbWUgZnVuY3Rpb24gaW4gdGhlIG5ldHdvcmsgYW5kIHRo ZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlLCB0aGUgY29tYmluYXRp b24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNlLg0KPiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBzdGF0ZWZ1 bCB0cmFmZmljIGFyZSBuZWVkZWQgdG8gYmUgZGlmZmVyZW50aWF0ZWQgcGVyIGluc3RhbmNlIChl LmcuIEZpcmV3YWxsLCBDb250ZW50cy1DYWNoZSwgYW5kIFZpZGVvLU9wdGltaXplcikuDQo+IA0K PiBJTUhPLHJlcXVpcmVtZW50cyBmb3Igc2NhbGFiaWxpdHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hp dGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1hdC4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IFNodW5zdWtl DQo+IA0KPiAoMjAxNC8wMi8xMiAxODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20g d3JvdGU6DQo+PiBEZWFyIGFsbCwNCj4+IA0KPj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVz IGlucHV0cyBmcm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+PiANCj4+IFRoZSBkaWZmIGNhbiBi ZSB0cmFja2VkIGhlcmU6IA0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJh ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDEmDQo+PiBkaWZmdHlwZT0tLWh0bWwmc3Vi bWl0PUdvISZ1cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+PiANCj4+ IENoZWVycywNCj4+IE1lZA0KPj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ IERlIDogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgDQo+PiBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1l cmNyZWRpIDEyIGbDqXZyaWVyIDIwMTQgMTA6NDYgw4ANCj4+IDogaS1kLWFubm91bmNlQGlldGYu b3JnIE9iamV0IDogSS1EIEFjdGlvbjogDQo+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVt ZW50cy0wMy50eHQNCj4+IA0KPj4gDQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiANCj4+ IA0KPj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcNCj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9oYW1lZCBC b3VjYWRhaXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5l dA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFubG9uZyBKaWFuZw0KPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIENhcmxvcyBQaWduYXRhcm8NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgS2VuZ28g TmFpdG8NCj4+ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWly ZW1lbnRzLTAzLnR4dA0KPj4gICAgUGFnZXMgICAgICAgICAgIDogMTQNCj4+ICAgIERhdGUgICAg ICAgICAgICA6IDIwMTQtMDItMTINCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGlzIGRvY3Vt ZW50IGlkZW50aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24N Cj4+ICAgIENoYWluaW5nIChTRkMpLg0KPj4gDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+IA0K Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0w Mw0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXIt c2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPj4gSS1ELUFubm91bmNlQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZQ0KPj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwgb3IgDQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4 dA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiANCj4gDQo+IC0tDQo+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IOacrOmWkyDkv4rku4sgKEhvbW1h IFNodW5zdWtlKQ0KPiANCj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+IOODjeOD g+ODiOODr+ODvOOCr+OCteODvOODk+OCueOCt+OCueODhuODoOeglOeptuaJgA0KPiDou6LpgIHj grXjg7zjg5Pjgrnln7rnm6Tjg5fjg63jgrjjgqfjgq/jg4gNCj4g6Lui6YCB44K144O844OT44K5 5Yi25b6hRFANCj4gDQo+IOOAkjE4MC04NTg144CA5p2x5Lqs6YO95q2m6JS16YeO5biC57eR55S6 My05LTExDQo+IFRFTDogMDQyMi01OS0zNDg2DQo+IEUtTUFJTDogaG9tbWEuc2h1bnN1a2VAbGFi Lm50dC5jby5qcA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon Feb 24 17:33:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD51A037C for ; Mon, 24 Feb 2014 17:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 6l_tsaN_v9qn for ; Mon, 24 Feb 2014 17:33:03 -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 E0B651A0369 for ; Mon, 24 Feb 2014 17:33:02 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P1Wtig020794; Tue, 25 Feb 2014 10:32:55 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id CB554E0145; Tue, 25 Feb 2014 10:32:55 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BF55DE0142; Tue, 25 Feb 2014 10:32:55 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P1WtB6023868; Tue, 25 Feb 2014 10:32:55 +0900 Message-ID: <530BF244.6080000@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 10:30:44 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Chris Frederick , Ron Parker References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7vtI_HRBZxw7kDlHpZlC03h5PQM Cc: "mohamed.boucadair@orange.com" , =?UTF-8?B?IuacrOmWk+S/iuS7iyhob21tYSBzaHVuc3VrZSki?= , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 01:33:06 -0000 Hello Ron, Chris, I also understood that evaluating policy conditions is an efficient function for recognizing subscribers. Do you think this should be one of the requirements? If there is no statements (or definitions), there would be SFs that may not co-operate with sfc evaluated policies. Thanks, Kengo (2014/02/25 8:46), Chris Frederick wrote: > Yes, agreed on that. > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, February 24, 2014 6:45 PM > To: Chris Frederick; 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Thanks, Chris. > > I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. > > Ron > > > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Monday, February 24, 2014 5:26 PM > To: Ron Parker; 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Agreed. > To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. > As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. > To illustrate w/ an example, we might say something like this: > If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. > There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). > This also goes to the earlier comments Ron + I made about consolidating the flow recognition + decision-making entity in a single (suitably policy-aware) node to reduce the complexity + to scale properly. Thx, /c > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Sunday, February 23, 2014 10:39 PM > To: 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Shunsuke-san, > > While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. > > If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. > > Ron > > >> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >> >> Hi Med, >> >> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >> >> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >> >> 1. The case that the types of SF increase: >> I assumed that the unit of applying SFC to traffic is following; >> - grouping: traffic is applied with specific SFC for each service, >> enterprise customer or region, >> - per-subscriber: traffic is applied with specific SFC for each　 >> subscriber (e.g. per IP address, VLAN ID et.al), >> - per-flow: traffic is applied with specific SFC for each subscriber, >> 　　and objective (e.g. pre URL, application et.al). >> >> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >> >> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >> >> 2. The case that there are some SFs that must be classified for each instance: >> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >> >> IMHO,requirements for scalability will affect SFC architecture and header format. >> >> Thanks, >> >> Shunsuke >> >> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>> Dear all, >>> >>> This new version integrates inputs from NTT representatives. >>> >>> The diff can be tracked here: >>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01& >>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 À >>> : i-d-announce@ietf.org Objet : I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Ron Parker >>> Carlos Pignataro >>> Kengo Naito >>> Filename : draft-boucadair-sfc-requirements-03.txt >>> Pages : 14 >>> Date : 2014-02-12 >>> >>> Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining (SFC). >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> -- >> ******************************************** >> 本間 俊介 (Homma Shunsuke) >> >> 日本電信電話株å¼ä¼šç¤¾ >> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >> 転é€ã‚µãƒ¼ãƒ“ス制御DP >> >> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >> TEL: 0422-59-3486 >> E-MAIL: homma.shunsuke@lab.ntt.co.jp >> ******************************************** >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From nobody Mon Feb 24 17:43:29 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BBC1A0393 for ; Mon, 24 Feb 2014 17:43:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bib8a9xutfGk for ; Mon, 24 Feb 2014 17:43:25 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14A671A037F for ; Mon, 24 Feb 2014 17:43:25 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 17:43:24 -0800 From: Ron Parker To: Kengo Naito , Chris Frederick Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAdEAD//3vt4A== Date: Tue, 25 Feb 2014 01:43:24 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF244.6080000@lab.ntt.co.jp> In-Reply-To: <530BF244.6080000@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ea00_LtakbxHVtnAJFhTu_FSMxU Cc: "mohamed.boucadair@orange.com" , =?utf-8?B?IuacrOmWk+S/iuS7iyhob21tYSBzaHVuc3VrZSki?= , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 01:43:28 -0000 S2VuZ28tc2FuLA0KDQpXZSd2ZSB0cmllZCB0byBsZWF2ZSBpdCB1cCB0byB0aGUgaW5ub3ZhdGlv biBvZiB0aGUgaW1wbGVtZW50ZXIgdG8gZGV0ZXJtaW5lIHdoYXQgbWV0YWRhdGEgdG8gY29sbGVj dCwgaG93IHRvIGNvbGxlY3QgaXQsIGFuZCBob3cgdG8gaW1wbGVtZW50IHBvbGljeSBldmFsdWF0 aW9uIHRoYXQgZXhhbWluZXMgdGhlIG1ldGFkYXRhIGFsb25nIHdpdGggdGhlIGZsb3cgcHJvcGVy dGllcy4gICBJbiBwcmFjdGljZSwgdGhpcyBtZWFucyB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb25z IGNvdWxkIGNvbWJpbmUsIGZvciBleGFtcGxlLCBhIDNncHAgUEROLUdhdGV3YXksIFNGQyBjbGFz c2lmaWVyLCBhbmQgU0ZDIFBEUCwgYnJpbmdpbmcgdG9nZXRoZXIgc3Vic2NyaWJlciBpbmZvcm1h dGlvbiwgZmxvdyBpbmZvcm1hdGlvbiwgYW5kIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiB0byBvbmUg cGxhY2UuICAgSG93ZXZlciwgYWxsIG9mIHRob3NlIGZ1bmN0aW9ucyBhcmUgbG9naWNhbGx5IHNl cGFyYXRlIGFuZCBvdGhlciBpbXBsZW1lbnRlcnMgbWF5IGZpbmQgcmVhc29uIHRvIG5vdCBjby1s b2NhdGUgdGhlbS4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEtlbmdvIE5haXRvIFttYWlsdG86bmFpdG8ua2VuZ29AbGFiLm50dC5jby5qcF0gDQpTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDg6MzEgUE0NClRvOiBDaHJpcyBGcmVkZXJpY2s7 IFJvbiBQYXJrZXINCkNjOiAi5pys6ZaT5L+K5LuLKGhvbW1hIHNodW5zdWtlKSI7IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFRS OiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCg0K SGVsbG8gUm9uLCBDaHJpcywNCg0KSSBhbHNvIHVuZGVyc3Rvb2QgdGhhdCBldmFsdWF0aW5nIHBv bGljeSBjb25kaXRpb25zIGlzIGFuIGVmZmljaWVudCBmdW5jdGlvbiBmb3IgcmVjb2duaXppbmcg c3Vic2NyaWJlcnMuDQpEbyB5b3UgdGhpbmsgdGhpcyBzaG91bGQgYmUgb25lIG9mIHRoZSByZXF1 aXJlbWVudHM/DQoNCklmIHRoZXJlIGlzIG5vIHN0YXRlbWVudHMgKG9yIGRlZmluaXRpb25zKSwg dGhlcmUgd291bGQgYmUgU0ZzIHRoYXQgbWF5IG5vdCBjby1vcGVyYXRlIHdpdGggc2ZjIGV2YWx1 YXRlZCBwb2xpY2llcy4NCg0KVGhhbmtzLA0KS2VuZ28NCg0KKDIwMTQvMDIvMjUgODo0NiksIENo cmlzIEZyZWRlcmljayB3cm90ZToNCj4gWWVzLCBhZ3JlZWQgb24gdGhhdC4NCj4NCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIw MTQgNjo0NSBQTQ0KPiBUbzogQ2hyaXMgRnJlZGVyaWNrOyDmnKzplpPkv4rku4sNCj4gQ2M6IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog W3NmY10gVFI6IEktRCBBY3Rpb246IA0KPiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50 cy0wMy50eHQNCj4NCj4gVGhhbmtzLCBDaHJpcy4NCj4NCj4gSSBkbyB0aGluayB0aGVyZSBhcmUg bG90cyBvZiBlZmZpY2llbmNpZXMgd2hlbiB0aGUgZmxvdyBsZWFybmVyIChjbGFzc2lmaWVyKSBh bmQgcG9saWN5IGV2YWx1YXRvciAoUERQKSBhcmUgY28tbG9jYXRlZC4gICBIb3dldmVyLCBhcmNo aXRlY3R1cmFsbHksIEkgd291bGRuJ3QgbWFuZGF0ZSB0aGF0IHRoZXkgYmUgY28tbG9jYXRlZC4N Cj4NCj4gICAgICBSb24NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0BzYW5kdmluZS5jb21dDQo+IFNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNToyNiBQTQ0KPiBUbzogUm9uIFBhcmtlcjsg 5pys6ZaT5L+K5LuLDQo+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiANCj4gZHJhZnQtYm91 Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+DQo+IEFncmVlZC4NCj4gVG8gcmVzdGF0 ZSB0aGlzIHNsaWdodGx5LCBpZiB0aGUgU0ZDIHN0ZWVyaW5nL2RlY2lzaW9uIGxvY3VzIGlzIGNh cGFibGUgb2YgZXZhbHVhdGluZyBtdWx0aXBsZSBvcnRob2dvbmFsIHBvbGljeSBjb25kaXRpb25z IHRoZW4gdGhpcyBpc3N1ZSBpcyBvYnZpYXRlZDsgc3Vic2NyaWJlcnMgYmVjb21lIGFuIGFnZ3Jl Z2F0ZSBvZiAnd2hhdCB0aGV5IGFyZScgKyBhcmUgbm90IHNpbXBseSAnd2hvIHRoZXkgYXJlJy4N Cj4gQXMgUm9uIHN0YXRlcywgdGhpcyBhd2FyZW5lc3MgbWF5IGJlIGRlcml2ZWQgZnJvbSBMREFQ IGxvb2t1cCwgUkFESVVTLCBHeCwgcHJlLXByb3Zpc2lvbmVkIHJ1bGVzLCBldGMuDQo+IFRvIGls bHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5IHNvbWV0aGluZyBsaWtlIHRoaXM6 DQo+IElmIHN1YnNjcmliZXIgWCBpcyB1c2luZyB5b3V0dWJlLCBhbmQgaXMgb24gYSBjb25nZXN0 ZWQgY2VsbCwgYW5kIGlzIG9uIGFuIGlQaG9uZSwgYW5kIGlzIGluIHRoZSAiR29sZCBUaWVyIiwg YW5kLCBhbmQsIGFuZCwgYW5kLCBldGMsIHRoZW4gdGhlIGNoYWluIGNvbnNpc3RzIG9mIHNlcnZp Y2UgZnVuY3Rpb25zIGEsIGIsIGFuZCBjLg0KPiBUaGVyZSdzIG5vIG5lZWQgdG8gZW50ZXIgYSBz dGF0aWMgU0ZDIHJ1bGUvY2hhaW4gZm9yIHN1YnNjcmliZXIgWCAob3IgYW55IHN1YnNjcmliZXIp LiBJbiBmYWN0LCBpdCdzIG5vdCBkZXNpcmFibGUgYW55d2F5IGJlY2F1c2UgYWxsIG9mIHRoZSBh Ym92ZSBjb25kaXRpb25zIG1heSBldmFsdWF0ZSB0byBUcnVlLCBzYXZlIG9uZSAoImlzIG9uIGEg Y29uZ2VzdGVkIGNlbGwiKSwgYW5kIHRoZSByZXN1bHRhbnQgY2hhaW4gbWlnaHQgYmUgYWx0ZXJl ZCAocGVyaGFwcyB0byBieXBhc3MgYSB2aWRlbyBvcHRpbWl6YXRpb24gc2VydmljZSBmdW5jdGlv bikuDQo+IFRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJsaWVyIGNvbW1lbnRzIFJvbiArIEkgbWFk ZSBhYm91dCANCj4gY29uc29saWRhdGluZyB0aGUgZmxvdyByZWNvZ25pdGlvbiArIGRlY2lzaW9u LW1ha2luZyBlbnRpdHkgaW4gYSANCj4gc2luZ2xlIChzdWl0YWJseSBwb2xpY3ktYXdhcmUpIG5v ZGUgdG8gcmVkdWNlIHRoZSBjb21wbGV4aXR5ICsgdG8gDQo+IHNjYWxlIHByb3Blcmx5LiBUaHgs IC9jDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPiBTZW50OiBT dW5kYXksIEZlYnJ1YXJ5IDIzLCAyMDE0IDEwOjM5IFBNDQo+IFRvOiDmnKzplpPkv4rku4sNCj4g Q2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IA0KPiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVp cmVtZW50cy0wMy50eHQNCj4NCj4gU2h1bnN1a2Utc2FuLA0KPg0KPiBXaGlsZSBhIHRoZW9yZXRp Y2FsIGNhc2UgY2FuIGJlIG1hZGUgZm9yIG9uZSBvciBtb3JlIFNGQ3MgcGVyIHN1YnNjcmliZXIs IGZvciByZWFzb25zIHlvdSBzdGF0ZSwgaXQgaXNuJ3QgcHJhY3RpY2FsLiAgQnV0LCB0aGVyZSBp cyBhbm90aGVyIHdheSB0byB2aWV3IHRoaXMgYXNwZWN0IG9mIHRoZSBwcm9ibGVtLiAgTGV0J3Mg dGFrZSB5b3VyIHBlci1zdWJzY3JpYmVyIGN1c3RvbWl6ZWQgZmlyZXdhbGwgYXMgYSBoeXBvdGhl dGljYWwgZXhhbXBsZS4gIElmIHRoZXJlIHdlcmUgb25seSBvbmUgZmlyZXdhbGwsIGluc3RlYWQs IGFuZCBpdCB3YXMgY2FwYWJsZSBvZiBsb2NhbCBwb2xpY3kgZXZhbHVhdGlvbiBiYXNlZCBvbiBz dWJzY3JpYmVyLCB0aGUgbnVtYmVyIG9mIFNGQ3Mgd291bGQgYmUgdmFzdGx5IHJlZHVjZWQuICAg T25lIHdheSBmb3IgdGhhdCB0byBoYXBwZW4gd291bGQgYmUgdG8gc2ltcGx5IHVzZSB0aGUgc291 cmNlL2Rlc3RpbmF0aW9uIElQIGFkZHJlc3MgZnJvbSB0aGUgcGFja2V0IGFuZCBzb21lIG91dCBv ZiBiYW5kIGxvb2t1cCBtZWNoYW5pc20gbGlrZSBMREFQIG9yIFJBRElVUyBhdCB0aGUgZmlyZXdh bGwuICAgIEFub3RoZXIgYXBwcm9hY2ggdG8gZGV0ZXJtaW5lIHdobyB0aGUgc3Vic2NyaWJlciBp cyB3b3VsZCBiZSBmb3IgdGhlIFNGQyBjbGFzc2lmaWVyIHRvIGFkZCBhIGRpc3RpbmN0IHN1YnNj cmliZXIgaWQgYXMgbWV0YWRhdGEgdG8gdGhlIHNlcnZpY2UgaGVhZGVyIChlZywgYW4gSU1TSSkg YW5kIHN0aWxsIHVzZSBMREFQLCBldGMuIGF0IHRoZSBmaXJld2FsbC4NCj4NCj4gSWYgdGhlIHBy b2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0aGF0IHRoZSBmaXJld2FsbCBwb2xpY3kgaXMg cGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3aGVyZSB0aGVyZSBhcmUgcGVyaGFwcyAxMHMgb2Yg Z3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFwcHJvYWNoIGlzIHRvIG1vZGVsIHRoZSBmaXJld2Fs bCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmlyZXdhbGwgcGVyIGZpcmV3YWxsIHBvbGljeSBzZXQg KHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUgc2FtZSBtYWNoaW5lIG9yIFZNKSBhbmQgdG8g Y29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidzIHBvbGljeSBhY2NvcmRpbmdseS4NCj4NCj4gICAg IFJvbg0KPg0KPg0KPj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDowNCBQTSwgIuacrOmWk+S/iuS7 iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPj4NCj4+IEhpIE1lZCwN Cj4+DQo+PiBJbiB0ZXJtcyBvZiB5b3VyIGNvbW1lbnQsIEkgYXNzdW1lZCBzb21lIHVzZSBjYXNl cyBhYm91dCBzY2FsYWJpbGl0eSBzbyB0aGF0IHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lv biBhYm91dCBzY2FsYWJpbGl0eSBjb25zaWRlcmF0aW9ucy4NCj4+ICNJIHdvcmsgd2l0aCBLLk5h aXRvLCBjby1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQgYW5kIHRoaW5rIHNjYWxhYmlsaXR5 IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNpZGVyLg0KPj4NCj4+IEFzc3VtaW5n IHRoZSB1c2UgY2FzZXMgbGlzdGVkIGZvbGxvd2luZywgdGhlIG1hbmFnZW1lbnQgbWVjaGFuaXNt IG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIG1pZ2h0IHJlcXVpcmUgaGlnaCBzY2FsYWJpbGl0 eS4NCj4+DQo+PiAxLiBUaGUgY2FzZSB0aGF0IHRoZSB0eXBlcyBvZiBTRiBpbmNyZWFzZToNCj4+ IEkgYXNzdW1lZCB0aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmljIGlzIGZv bGxvd2luZzsNCj4+ICAgLSBncm91cGluZzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lm aWMgU0ZDIGZvciBlYWNoIHNlcnZpY2UsDQo+PiAgICAgZW50ZXJwcmlzZSBjdXN0b21lciBvciBy ZWdpb24sDQo+PiAgIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNw ZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPj4gICAgIHN1YnNjcmliZXIgKGUuZy4gcGVyIElQIGFk ZHJlc3MsIFZMQU4gSUQgZXQuYWwpLA0KPj4gICAtIHBlci1mbG93OiB0cmFmZmljIGlzIGFwcGxp ZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc3Vic2NyaWJlciwNCj4+IOOAgOOAgGFuZCBv YmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0KPj4NCj4+IFNvbWUg b2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVyIG9mIHN1YnNjcmli ZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBzZXZlcmFsIHRlbnMg b3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBvZiBwZXItc3Vic2Ny aWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBpbmNyZWFzZSBleHBs b3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQgaW4gdGhlIGNhc2Ug dGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNlcihlLmcuIHZDUEUg YXMgdXNlciBjdXN0b21pemVkKS4NCj4+DQo+PiBBbHNvLCBpbiBjYXNlIG9mIGdyb3VwaW5nLCBp ZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3NlIHBvbGljaWVzIGFyZSBkaWZmZXJlbnQs IHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIgYW5kIHBlciByZWdpb24sIHRoZSBudW1i ZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBGaXJld2FsbHMgaGF2ZSBkaWZmZXJlbnQg cG9saWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9tZXIpLg0KPj4NCj4+IDIuIFRoZSBjYXNl IHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIHRoYXQgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNo IGluc3RhbmNlOg0KPj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9y IGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+ PiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBzdGF0ZWZ1bCB0cmFmZmljIGFyZSBuZWVkZWQgdG8gYmUg ZGlmZmVyZW50aWF0ZWQgcGVyIGluc3RhbmNlIChlLmcuIEZpcmV3YWxsLCBDb250ZW50cy1DYWNo ZSwgYW5kIFZpZGVvLU9wdGltaXplcikuDQo+Pg0KPj4gSU1ITyxyZXF1aXJlbWVudHMgZm9yIHNj YWxhYmlsaXR5IHdpbGwgYWZmZWN0IFNGQyBhcmNoaXRlY3R1cmUgYW5kIGhlYWRlciBmb3JtYXQu DQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IFNodW5zdWtlDQo+Pg0KPj4gKDIwMTQvMDIvMTIgMTg6 NDkpLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+IERlYXIgYWxsLA0K Pj4+DQo+Pj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVzIGlucHV0cyBmcm9tIE5UVCByZXBy ZXNlbnRhdGl2ZXMuDQo+Pj4NCj4+PiBUaGUgZGlmZiBjYW4gYmUgdHJhY2tlZCBoZXJlOg0KPj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVx dWlyZW1lbnRzLTAxDQo+Pj4gJg0KPj4+IGRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9 ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+Pg0KPj4+IENoZWVycywNCj4+ PiBNZWQNCj4+Pg0KPj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+IERlIDogSS1E LUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgDQo+Pj4gZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVudm95w6kgOiBtZXJjcmVkaSAx MiBmw6l2cmllciAyMDE0IDEwOjQ2IA0KPj4+IMOADQo+Pj4gOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0KPj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1l bnRzLTAzLnR4dA0KPj4+DQo+Pj4NCj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4NCj4+ Pg0KPj4+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJlcXVpcmVtZW50cyBmb3IgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZw0KPj4+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFt ZWQgQm91Y2FkYWlyDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEph Y3F1ZW5ldA0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1YW5sb25nIEppYW5nDQo+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtlcg0KPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBLZW5nbyBOYWl0bw0KPj4+ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1ib3Vj YWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+PiAgICAgUGFnZXMgICAgICAgICAgIDog MTQNCj4+PiAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMi0xMg0KPj4+DQo+Pj4gQWJzdHJh Y3Q6DQo+Pj4gICAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZv ciB0aGUgU2VydmljZSBGdW5jdGlvbg0KPj4+ICAgICBDaGFpbmluZyAoU0ZDKS4NCj4+Pg0KPj4+ DQo+Pj4NCj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRh aXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+Pg0KPj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+Pj4NCj4+PiBBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+Pg0K Pj4+DQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YgDQo+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+DQo+Pj4g SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4NCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEktRC1Bbm5vdW5j ZSBtYWlsaW5nIGxpc3QNCj4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+IEludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIA0KPj4+ IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNmYyBtYWls aW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+IC0tDQo+PiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPj4g5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+ Pg0KPj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+PiDjg43jg4Pjg4jjg6/jg7zj gq/jgrXjg7zjg5Pjgrnjgrfjgrnjg4bjg6DnoJTnqbbmiYANCj4+IOi7oumAgeOCteODvOODk+OC ueWfuuebpOODl+ODreOCuOOCp+OCr+ODiA0KPj4g6Lui6YCB44K144O844OT44K55Yi25b6hRFAN Cj4+DQo+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiUtemHjuW4gue3keeUujMtOS0xMQ0K Pj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4+IEUtTUFJTDogaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5j by5qcA0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g c2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPg0KPg0KPg0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpOVFQgTmV0d29yayBUZWNobm9sb2d5IExhYm9yYXRvcmllcw0KS2VuZ28gTmFpdG8NCkUt TWFpbDogbmFpdG8ua2VuZ29AbGFiLm50dC5jby5qcA0KVEVMOiArODEgNDIyLTU5LTQ5NDkNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= From nobody Mon Feb 24 17:59:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08821A0236 for ; Mon, 24 Feb 2014 17:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 KoOi4pjXocgY for ; Mon, 24 Feb 2014 17:58:59 -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 3C2F41A0221 for ; Mon, 24 Feb 2014 17:58:59 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P1wuYE021723; Tue, 25 Feb 2014 10:58:56 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 500BDE0144; Tue, 25 Feb 2014 10:58:56 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 43CE6E0142; Tue, 25 Feb 2014 10:58:56 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P1wYNl020953; Tue, 25 Feb 2014 10:58:56 +0900 Message-ID: <530BF90B.7040508@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 10:59:39 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: Chris Frederick , Ron Parker X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/C2T6cq9TjjcHy23bszEuM6taCB8 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 01:59:02 -0000 Hi Ron, Chris, Thank you for your reply. I think that your points are following: in case that there are some SFs as user customized, per-subscriber SFCs shouldn't be made, but the SFs should recognize subscribers by IP address or metadata. Of course, it is one of the solutions. However, in this case, I think that SFs as user customized might be required to have a function to recognize each subscriber. On the other hand, I think that there are cases when the function can't be adopted, such like SFs are current equipment that don't have function to recognize metadata. How do we handle these cases? Any new problems or requirements may occur? regards, Shunsuke (2014/02/25 8:46), Chris Frederick wrote: > Yes, agreed on that. > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, February 24, 2014 6:45 PM > To: Chris Frederick; 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Thanks, Chris. > > I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. > > Ron > > > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Monday, February 24, 2014 5:26 PM > To: Ron Parker; 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Agreed. > To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. > As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. > To illustrate w/ an example, we might say something like this: > If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. > There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). > This also goes to the earlier comments Ron + I made about consolidating the flow recognition + decision-making entity in a single (suitably policy-aware) node to reduce the complexity + to scale properly. Thx, /c > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Sunday, February 23, 2014 10:39 PM > To: 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Shunsuke-san, > > While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. > > If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. > > Ron > > >> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >> >> Hi Med, >> >> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >> >> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >> >> 1. The case that the types of SF increase: >> I assumed that the unit of applying SFC to traffic is following; >> - grouping: traffic is applied with specific SFC for each service, >> enterprise customer or region, >> - per-subscriber: traffic is applied with specific SFC for each　 >> subscriber (e.g. per IP address, VLAN ID et.al), >> - per-flow: traffic is applied with specific SFC for each subscriber, >> 　　and objective (e.g. pre URL, application et.al). >> >> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >> >> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >> >> 2. The case that there are some SFs that must be classified for each instance: >> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >> >> IMHO,requirements for scalability will affect SFC architecture and header format. >> >> Thanks, >> >> Shunsuke >> >> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>> Dear all, >>> >>> This new version integrates inputs from NTT representatives. >>> >>> The diff can be tracked here: >>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01& >>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 À >>> : i-d-announce@ietf.org Objet : I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Requirements for Service Function Chaining >>> Authors : Mohamed Boucadair >>> Christian Jacquenet >>> Yuanlong Jiang >>> Ron Parker >>> Carlos Pignataro >>> Kengo Naito >>> Filename : draft-boucadair-sfc-requirements-03.txt >>> Pages : 14 >>> Date : 2014-02-12 >>> >>> Abstract: >>> This document identifies the requirements for the Service Function >>> Chaining (SFC). >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> -- >> ******************************************** >> 本間 俊介 (Homma Shunsuke) >> >> 日本電信電話株å¼ä¼šç¤¾ >> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >> 転é€ã‚µãƒ¼ãƒ“ス制御DP >> >> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >> TEL: 0422-59-3486 >> E-MAIL: homma.shunsuke@lab.ntt.co.jp >> ******************************************** >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------- Shunsuke Homma TEL: +81 0422 59 3486 FAX: +81 0422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Mon Feb 24 18:05:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65A1A039B for ; Mon, 24 Feb 2014 18:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 Z-lNggne0cAl for ; Mon, 24 Feb 2014 18:05:10 -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 D67871A0398 for ; Mon, 24 Feb 2014 18:05:09 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P256AX021991; Tue, 25 Feb 2014 11:05:06 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 854A3E012C; Tue, 25 Feb 2014 11:05:06 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 79788E012B; Tue, 25 Feb 2014 11:05:06 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P256EV013123; Tue, 25 Feb 2014 11:05:06 +0900 Message-ID: <530BF9CF.2020708@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 11:02:55 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ron Parker References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF244.6080000@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3s6BPxSyfn0xhgyqoNX4DRGc1t0 Cc: Chris Frederick , "mohamed.boucadair@orange.com" , =?UTF-8?B?IuacrOmWk+S/iuS7iyhob21tYSBzaHVuc3VrZSki?= , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 02:05:12 -0000 Ron, In terms of classifiers, I agree with you that it is an implementation matter. To avoid misunderstanding, let me ask you this: Then, implementers should also determine what metadata to collect at the classifier (with policy evaluator), and also, how to handle it in SFs, maybe in virtual appliances, and also maybe in virtual switches (or load balancers) in front of them, right? Kengo (2014/02/25 10:43), Ron Parker wrote: > Kengo-san, > > We've tried to leave it up to the innovation of the implementer to determine what metadata to collect, how to collect it, and how to implement policy evaluation that examines the metadata along with the flow properties. In practice, this means that some implementations could combine, for example, a 3gpp PDN-Gateway, SFC classifier, and SFC PDP, bringing together subscriber information, flow information, and service orchestration to one place. However, all of those functions are logically separate and other implementers may find reason to not co-locate them. > > Ron > > > -----Original Message----- > From: Kengo Naito [mailto:naito.kengo@lab.ntt.co.jp] > Sent: Monday, February 24, 2014 8:31 PM > To: Chris Frederick; Ron Parker > Cc: "本間俊介(homma shunsuke)"; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Hello Ron, Chris, > > I also understood that evaluating policy conditions is an efficient function for recognizing subscribers. > Do you think this should be one of the requirements? > > If there is no statements (or definitions), there would be SFs that may not co-operate with sfc evaluated policies. > > Thanks, > Kengo > > (2014/02/25 8:46), Chris Frederick wrote: >> Yes, agreed on that. >> >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, February 24, 2014 6:45 PM >> To: Chris Frederick; 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: RE: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Thanks, Chris. >> >> I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. >> >> Ron >> >> >> -----Original Message----- >> From: Chris Frederick [mailto:cfrederick@sandvine.com] >> Sent: Monday, February 24, 2014 5:26 PM >> To: Ron Parker; 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: RE: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Agreed. >> To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. >> As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. >> To illustrate w/ an example, we might say something like this: >> If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. >> There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). >> This also goes to the earlier comments Ron + I made about >> consolidating the flow recognition + decision-making entity in a >> single (suitably policy-aware) node to reduce the complexity + to >> scale properly. Thx, /c >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Sunday, February 23, 2014 10:39 PM >> To: 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Shunsuke-san, >> >> While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. >> >> If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. >> >> Ron >> >> >>> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >>> >>> Hi Med, >>> >>> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >>> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >>> >>> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >>> >>> 1. The case that the types of SF increase: >>> I assumed that the unit of applying SFC to traffic is following; >>> - grouping: traffic is applied with specific SFC for each service, >>> enterprise customer or region, >>> - per-subscriber: traffic is applied with specific SFC for each　 >>> subscriber (e.g. per IP address, VLAN ID et.al), >>> - per-flow: traffic is applied with specific SFC for each subscriber, >>> 　　and objective (e.g. pre URL, application et.al). >>> >>> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >>> >>> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >>> >>> 2. The case that there are some SFs that must be classified for each instance: >>> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >>> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>> >>> IMHO,requirements for scalability will affect SFC architecture and header format. >>> >>> Thanks, >>> >>> Shunsuke >>> >>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>> >>>> This new version integrates inputs from NTT representatives. >>>> >>>> The diff can be tracked here: >>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01 >>>> & >>>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 >>>> À >>>> : i-d-announce@ietf.org Objet : I-D Action: >>>> draft-boucadair-sfc-requirements-03.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Requirements for Service Function Chaining >>>> Authors : Mohamed Boucadair >>>> Christian Jacquenet >>>> Yuanlong Jiang >>>> Ron Parker >>>> Carlos Pignataro >>>> Kengo Naito >>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>> Pages : 14 >>>> Date : 2014-02-12 >>>> >>>> Abstract: >>>> This document identifies the requirements for the Service Function >>>> Chaining (SFC). >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> -- >>> ******************************************** >>> 本間 俊介 (Homma Shunsuke) >>> >>> 日本電信電話株å¼ä¼šç¤¾ >>> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >>> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >>> 転é€ã‚µãƒ¼ãƒ“ス制御DP >>> >>> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >>> TEL: 0422-59-3486 >>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>> ******************************************** >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> > > -- > ---------------------------------------- > NTT Network Technology Laboratories > Kengo Naito > E-Mail: naito.kengo@lab.ntt.co.jp > TEL: +81 422-59-4949 > ---------------------------------------- > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From nobody Mon Feb 24 18:13:59 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525731A039C for ; Mon, 24 Feb 2014 18:13:57 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH2wz_wJerhK for ; Mon, 24 Feb 2014 18:13:54 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 694781A037F for ; Mon, 24 Feb 2014 18:13:54 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Mon, 24 Feb 2014 18:13:54 -0800 From: Ron Parker To: Kengo Naito Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAdEAD//3vt4IAAjRGA//98aRA= Date: Tue, 25 Feb 2014 02:13:53 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF244.6080000@lab.ntt.co.jp> <530BF9CF.2020708@lab.ntt.co.jp> In-Reply-To: <530BF9CF.2020708@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.20.29.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/epO93bBQxeM2cZYFlVYezJ4sUmA Cc: Chris Frederick , "mohamed.boucadair@orange.com" , =?utf-8?B?IuacrOmWk+S/iuS7iyhob21tYSBzaHVuc3VrZSki?= , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 02:13:57 -0000 WWVzLCBhbGwgb2YgdGhhdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIuDQoNCldydCBsb2Fk IGJhbGFuY2Vycywgc2VlIHNvbWUgb2YgdGhlIHByZXZpb3VzIGRpc2N1c3Npb24gdGhhdCB3YXMg YXR0ZW1wdGluZyB0byBkaWZmZXJlbnRpYXRlIGxvYWQgYmFsYW5jaW5nIG9mIG1pZGJveCBzZXJ2 aWNlIGZ1bmN0aW9ucyB2cy4gbG9hZCBiYWxhbmNlciBhcyBhIHNlcnZpY2UgZnVuY3Rpb24uICAg SW4gdGhlIGZvcm1lciBjYXNlLCB3ZSBtYXkgY2hvb3NlIHRvIG1ha2UgdGhlIGNsYXNzaWZpZXIv UERQIGF3YXJlIG9mIHRoZSBmYWN0IHRoYXQgYSBzZXJ2aWNlIGZ1bmN0aW9uIGlzIG11bHRpcGx5 IGluc3RhbnRpYXRlZC4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEtlbmdvIE5haXRvIFttYWlsdG86bmFpdG8ua2VuZ29AbGFiLm50dC5jby5qcF0gDQpT ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDk6MDMgUE0NClRvOiBSb24gUGFya2VyDQpD YzogQ2hyaXMgRnJlZGVyaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyAi5pys6ZaT 5L+K5LuLKGhvbW1hIHNodW5zdWtlKSI7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNd IFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQN Cg0KUm9uLA0KDQpJbiB0ZXJtcyBvZiBjbGFzc2lmaWVycywgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0 IGl0IGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlci4NClRvIGF2b2lkIG1pc3VuZGVyc3RhbmRp bmcsIGxldCBtZSBhc2sgeW91IHRoaXM6DQpUaGVuLCBpbXBsZW1lbnRlcnMgc2hvdWxkIGFsc28g ZGV0ZXJtaW5lIHdoYXQgbWV0YWRhdGEgdG8gY29sbGVjdCBhdCB0aGUgY2xhc3NpZmllciAod2l0 aCBwb2xpY3kgZXZhbHVhdG9yKSwgYW5kIGFsc28sIGhvdyB0byBoYW5kbGUgaXQgaW4gU0ZzLCBt YXliZSBpbiB2aXJ0dWFsIGFwcGxpYW5jZXMsIGFuZCBhbHNvIG1heWJlIGluIHZpcnR1YWwgc3dp dGNoZXMgKG9yIGxvYWQgYmFsYW5jZXJzKSBpbiBmcm9udCBvZiB0aGVtLCByaWdodD8NCg0KS2Vu Z28NCg0KKDIwMTQvMDIvMjUgMTA6NDMpLCBSb24gUGFya2VyIHdyb3RlOg0KPiBLZW5nby1zYW4s DQo+DQo+IFdlJ3ZlIHRyaWVkIHRvIGxlYXZlIGl0IHVwIHRvIHRoZSBpbm5vdmF0aW9uIG9mIHRo ZSBpbXBsZW1lbnRlciB0byBkZXRlcm1pbmUgd2hhdCBtZXRhZGF0YSB0byBjb2xsZWN0LCBob3cg dG8gY29sbGVjdCBpdCwgYW5kIGhvdyB0byBpbXBsZW1lbnQgcG9saWN5IGV2YWx1YXRpb24gdGhh dCBleGFtaW5lcyB0aGUgbWV0YWRhdGEgYWxvbmcgd2l0aCB0aGUgZmxvdyBwcm9wZXJ0aWVzLiAg IEluIHByYWN0aWNlLCB0aGlzIG1lYW5zIHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgY291bGQg Y29tYmluZSwgZm9yIGV4YW1wbGUsIGEgM2dwcCBQRE4tR2F0ZXdheSwgU0ZDIGNsYXNzaWZpZXIs IGFuZCBTRkMgUERQLCBicmluZ2luZyB0b2dldGhlciBzdWJzY3JpYmVyIGluZm9ybWF0aW9uLCBm bG93IGluZm9ybWF0aW9uLCBhbmQgc2VydmljZSBvcmNoZXN0cmF0aW9uIHRvIG9uZSBwbGFjZS4g ICBIb3dldmVyLCBhbGwgb2YgdGhvc2UgZnVuY3Rpb25zIGFyZSBsb2dpY2FsbHkgc2VwYXJhdGUg YW5kIG90aGVyIGltcGxlbWVudGVycyBtYXkgZmluZCByZWFzb24gdG8gbm90IGNvLWxvY2F0ZSB0 aGVtLg0KPg0KPiAgICAgUm9uDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEtlbmdvIE5haXRvIFttYWlsdG86bmFpdG8ua2VuZ29AbGFiLm50dC5jby5qcF0NCj4g U2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA4OjMxIFBNDQo+IFRvOiBDaHJpcyBGcmVk ZXJpY2s7IFJvbiBQYXJrZXINCj4gQ2M6ICLmnKzplpPkv4rku4soaG9tbWEgc2h1bnN1a2UpIjsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogDQo+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1l bnRzLTAzLnR4dA0KPg0KPiBIZWxsbyBSb24sIENocmlzLA0KPg0KPiBJIGFsc28gdW5kZXJzdG9v ZCB0aGF0IGV2YWx1YXRpbmcgcG9saWN5IGNvbmRpdGlvbnMgaXMgYW4gZWZmaWNpZW50IGZ1bmN0 aW9uIGZvciByZWNvZ25pemluZyBzdWJzY3JpYmVycy4NCj4gRG8geW91IHRoaW5rIHRoaXMgc2hv dWxkIGJlIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzPw0KPg0KPiBJZiB0aGVyZSBpcyBubyBzdGF0 ZW1lbnRzIChvciBkZWZpbml0aW9ucyksIHRoZXJlIHdvdWxkIGJlIFNGcyB0aGF0IG1heSBub3Qg Y28tb3BlcmF0ZSB3aXRoIHNmYyBldmFsdWF0ZWQgcG9saWNpZXMuDQo+DQo+IFRoYW5rcywNCj4g S2VuZ28NCj4NCj4gKDIwMTQvMDIvMjUgODo0NiksIENocmlzIEZyZWRlcmljayB3cm90ZToNCj4+ IFllcywgYWdyZWVkIG9uIHRoYXQuDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tXQ0KPj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA2OjQ1IFBNDQo+PiBUbzog Q2hyaXMgRnJlZGVyaWNrOyDmnKzplpPkv4rku4sNCj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFj dGlvbjoNCj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4NCj4+ IFRoYW5rcywgQ2hyaXMuDQo+Pg0KPj4gSSBkbyB0aGluayB0aGVyZSBhcmUgbG90cyBvZiBlZmZp Y2llbmNpZXMgd2hlbiB0aGUgZmxvdyBsZWFybmVyIChjbGFzc2lmaWVyKSBhbmQgcG9saWN5IGV2 YWx1YXRvciAoUERQKSBhcmUgY28tbG9jYXRlZC4gICBIb3dldmVyLCBhcmNoaXRlY3R1cmFsbHks IEkgd291bGRuJ3QgbWFuZGF0ZSB0aGF0IHRoZXkgYmUgY28tbG9jYXRlZC4NCj4+DQo+PiAgICAg ICBSb24NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENo cmlzIEZyZWRlcmljayBbbWFpbHRvOmNmcmVkZXJpY2tAc2FuZHZpbmUuY29tXQ0KPj4gU2VudDog TW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1OjI2IFBNDQo+PiBUbzogUm9uIFBhcmtlcjsg5pys 6ZaT5L+K5LuLDQo+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+PiBkcmFmdC1ib3Vj YWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+DQo+PiBBZ3JlZWQuDQo+PiBUbyByZXN0 YXRlIHRoaXMgc2xpZ2h0bHksIGlmIHRoZSBTRkMgc3RlZXJpbmcvZGVjaXNpb24gbG9jdXMgaXMg Y2FwYWJsZSBvZiBldmFsdWF0aW5nIG11bHRpcGxlIG9ydGhvZ29uYWwgcG9saWN5IGNvbmRpdGlv bnMgdGhlbiB0aGlzIGlzc3VlIGlzIG9idmlhdGVkOyBzdWJzY3JpYmVycyBiZWNvbWUgYW4gYWdn cmVnYXRlIG9mICd3aGF0IHRoZXkgYXJlJyArIGFyZSBub3Qgc2ltcGx5ICd3aG8gdGhleSBhcmUn Lg0KPj4gQXMgUm9uIHN0YXRlcywgdGhpcyBhd2FyZW5lc3MgbWF5IGJlIGRlcml2ZWQgZnJvbSBM REFQIGxvb2t1cCwgUkFESVVTLCBHeCwgcHJlLXByb3Zpc2lvbmVkIHJ1bGVzLCBldGMuDQo+PiBU byBpbGx1c3RyYXRlIHcvIGFuIGV4YW1wbGUsIHdlIG1pZ2h0IHNheSBzb21ldGhpbmcgbGlrZSB0 aGlzOg0KPj4gSWYgc3Vic2NyaWJlciBYIGlzIHVzaW5nIHlvdXR1YmUsIGFuZCBpcyBvbiBhIGNv bmdlc3RlZCBjZWxsLCBhbmQgaXMgb24gYW4gaVBob25lLCBhbmQgaXMgaW4gdGhlICJHb2xkIFRp ZXIiLCBhbmQsIGFuZCwgYW5kLCBhbmQsIGV0YywgdGhlbiB0aGUgY2hhaW4gY29uc2lzdHMgb2Yg c2VydmljZSBmdW5jdGlvbnMgYSwgYiwgYW5kIGMuDQo+PiBUaGVyZSdzIG5vIG5lZWQgdG8gZW50 ZXIgYSBzdGF0aWMgU0ZDIHJ1bGUvY2hhaW4gZm9yIHN1YnNjcmliZXIgWCAob3IgYW55IHN1YnNj cmliZXIpLiBJbiBmYWN0LCBpdCdzIG5vdCBkZXNpcmFibGUgYW55d2F5IGJlY2F1c2UgYWxsIG9m IHRoZSBhYm92ZSBjb25kaXRpb25zIG1heSBldmFsdWF0ZSB0byBUcnVlLCBzYXZlIG9uZSAoImlz IG9uIGEgY29uZ2VzdGVkIGNlbGwiKSwgYW5kIHRoZSByZXN1bHRhbnQgY2hhaW4gbWlnaHQgYmUg YWx0ZXJlZCAocGVyaGFwcyB0byBieXBhc3MgYSB2aWRlbyBvcHRpbWl6YXRpb24gc2VydmljZSBm dW5jdGlvbikuDQo+PiBUaGlzIGFsc28gZ29lcyB0byB0aGUgZWFybGllciBjb21tZW50cyBSb24g KyBJIG1hZGUgYWJvdXQgDQo+PiBjb25zb2xpZGF0aW5nIHRoZSBmbG93IHJlY29nbml0aW9uICsg ZGVjaXNpb24tbWFraW5nIGVudGl0eSBpbiBhIA0KPj4gc2luZ2xlIChzdWl0YWJseSBwb2xpY3kt YXdhcmUpIG5vZGUgdG8gcmVkdWNlIHRoZSBjb21wbGV4aXR5ICsgdG8gDQo+PiBzY2FsZSBwcm9w ZXJseS4gVGh4LCAvYw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJr ZXINCj4+IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMjMsIDIwMTQgMTA6MzkgUE0NCj4+IFRvOiDm nKzplpPkv4rku4sNCj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+IGRyYWZ0LWJv dWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4NCj4+IFNodW5zdWtlLXNhbiwNCj4+ DQo+PiBXaGlsZSBhIHRoZW9yZXRpY2FsIGNhc2UgY2FuIGJlIG1hZGUgZm9yIG9uZSBvciBtb3Jl IFNGQ3MgcGVyIHN1YnNjcmliZXIsIGZvciByZWFzb25zIHlvdSBzdGF0ZSwgaXQgaXNuJ3QgcHJh Y3RpY2FsLiAgQnV0LCB0aGVyZSBpcyBhbm90aGVyIHdheSB0byB2aWV3IHRoaXMgYXNwZWN0IG9m IHRoZSBwcm9ibGVtLiAgTGV0J3MgdGFrZSB5b3VyIHBlci1zdWJzY3JpYmVyIGN1c3RvbWl6ZWQg ZmlyZXdhbGwgYXMgYSBoeXBvdGhldGljYWwgZXhhbXBsZS4gIElmIHRoZXJlIHdlcmUgb25seSBv bmUgZmlyZXdhbGwsIGluc3RlYWQsIGFuZCBpdCB3YXMgY2FwYWJsZSBvZiBsb2NhbCBwb2xpY3kg ZXZhbHVhdGlvbiBiYXNlZCBvbiBzdWJzY3JpYmVyLCB0aGUgbnVtYmVyIG9mIFNGQ3Mgd291bGQg YmUgdmFzdGx5IHJlZHVjZWQuICAgT25lIHdheSBmb3IgdGhhdCB0byBoYXBwZW4gd291bGQgYmUg dG8gc2ltcGx5IHVzZSB0aGUgc291cmNlL2Rlc3RpbmF0aW9uIElQIGFkZHJlc3MgZnJvbSB0aGUg cGFja2V0IGFuZCBzb21lIG91dCBvZiBiYW5kIGxvb2t1cCBtZWNoYW5pc20gbGlrZSBMREFQIG9y IFJBRElVUyBhdCB0aGUgZmlyZXdhbGwuICAgIEFub3RoZXIgYXBwcm9hY2ggdG8gZGV0ZXJtaW5l IHdobyB0aGUgc3Vic2NyaWJlciBpcyB3b3VsZCBiZSBmb3IgdGhlIFNGQyBjbGFzc2lmaWVyIHRv IGFkZCBhIGRpc3RpbmN0IHN1YnNjcmliZXIgaWQgYXMgbWV0YWRhdGEgdG8gdGhlIHNlcnZpY2Ug aGVhZGVyIChlZywgYW4gSU1TSSkgYW5kIHN0aWxsIHVzZSBMREFQLCBldGMuIGF0IHRoZSBmaXJl d2FsbC4NCj4+DQo+PiBJZiB0aGUgcHJvYmxlbSBpcyBjaGFuZ2VkIHNsaWdodGx5IHNvIHRoYXQg dGhlIGZpcmV3YWxsIHBvbGljeSBpcyBwZXIgZ3JvdXAgb2Ygc3Vic2NyaWJlcnMsIHdoZXJlIHRo ZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4geWV0IGFub3RoZXIgYXBwcm9hY2gg aXMgdG8gbW9kZWwgdGhlIGZpcmV3YWxsIGFzIGEgZGlzdGluY3QgbG9naWNhbCBmaXJld2FsbCBw ZXIgZmlyZXdhbGwgcG9saWN5IHNldCAodGhleSBjb3VsZCBhbGwgcmVzaWRlIGluIHRoZSBzYW1l IG1hY2hpbmUgb3IgVk0pIGFuZCB0byBjb29yZGluYXRlIHRoZSBjbGFzc2lmaWVyJ3MgcG9saWN5 IGFjY29yZGluZ2x5Lg0KPj4NCj4+ICAgICAgUm9uDQo+Pg0KPj4NCj4+PiBPbiBGZWIgMjMsIDIw MTQsIGF0IDEwOjA0IFBNLCAi5pys6ZaT5L+K5LuLIiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5j by5qcD4gd3JvdGU6DQo+Pj4NCj4+PiBIaSBNZWQsDQo+Pj4NCj4+PiBJbiB0ZXJtcyBvZiB5b3Vy IGNvbW1lbnQsIEkgYXNzdW1lZCBzb21lIHVzZSBjYXNlcyBhYm91dCBzY2FsYWJpbGl0eSBzbyB0 aGF0IHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhYm91dCBzY2FsYWJpbGl0eSBjb25z aWRlcmF0aW9ucy4NCj4+PiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0aG9yIG9mIHJlcXVp cmVtZW50IGRyYWZ0IGFuZCB0aGluayBzY2FsYWJpbGl0eSBpcyBvbmUgb2YgaW1wb3J0YW50IHRo aW5ncyB0byBjb25zaWRlci4NCj4+Pg0KPj4+IEFzc3VtaW5nIHRoZSB1c2UgY2FzZXMgbGlzdGVk IGZvbGxvd2luZywgdGhlIG1hbmFnZW1lbnQgbWVjaGFuaXNtIG9mIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5zIG1pZ2h0IHJlcXVpcmUgaGlnaCBzY2FsYWJpbGl0eS4NCj4+Pg0KPj4+IDEuIFRoZSBj YXNlIHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPj4+IEkgYXNzdW1lZCB0aGF0IHRo ZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4+PiAgICAt IGdyb3VwaW5nOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2gg c2VydmljZSwNCj4+PiAgICAgIGVudGVycHJpc2UgY3VzdG9tZXIgb3IgcmVnaW9uLA0KPj4+ICAg IC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBm b3IgZWFjaOOAgA0KPj4+ICAgICAgc3Vic2NyaWJlciAoZS5nLiBwZXIgSVAgYWRkcmVzcywgVkxB TiBJRCBldC5hbCksDQo+Pj4gICAgLSBwZXItZmxvdzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGgg c3BlY2lmaWMgU0ZDIGZvciBlYWNoIHN1YnNjcmliZXIsDQo+Pj4g44CA44CAYW5kIG9iamVjdGl2 ZSAoZS5nLiBwcmUgVVJMLCBhcHBsaWNhdGlvbiBldC5hbCkuDQo+Pj4NCj4+PiBTb21lIG9mIHRo ZSBzZXJ2aWNlIHByb3ZpZGVycyBoYXZlIGVub3Jtb3VzIG51bWJlciBvZiBzdWJzY3JpYmVycywg YW5kIHRoZSBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgaXMgdXAgdG8gc2V2ZXJhbCB0ZW5zIG9yIGh1 bmRyZWRzIG9mIG1pbGxpb24uIFRoZXJlZm9yZSwgaW4gY2FzZXMgb2YgcGVyLXN1YnNjcmliZXIg YW5kIHBlci1mbG93LCB0aGUgbnVtYmVyIG9mIFNGQ3MgbWlnaHQgaW5jcmVhc2UgZXhwbG9zaXZl bHkuIFBlci1zdWJzY3JpYmVyIFNGQ3Mgd291bGQgYmUgbmVlZGVkIGluIHRoZSBjYXNlIHRoYXQg dGhlcmUgYXJlIHNvbWUgU0ZzIGRlZGljYXRlZCB0byBlYWNoIHVzZXIoZS5nLiB2Q1BFIGFzIHVz ZXIgY3VzdG9taXplZCkuDQo+Pj4NCj4+PiBBbHNvLCBpbiBjYXNlIG9mIGdyb3VwaW5nLCBpZiB0 aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3NlIHBvbGljaWVzIGFyZSBkaWZmZXJlbnQsIHN1 Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIgYW5kIHBlciByZWdpb24sIHRoZSBudW1iZXIg b2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBGaXJld2FsbHMgaGF2ZSBkaWZmZXJlbnQgcG9s aWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9tZXIpLg0KPj4+DQo+Pj4gMi4gVGhlIGNhc2Ug dGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgdGhhdCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2gg aW5zdGFuY2U6DQo+Pj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9y IGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+ Pj4gVGhlIFNGcyB0aGF0IHByb2Nlc3Mgc3RhdGVmdWwgdHJhZmZpYyBhcmUgbmVlZGVkIHRvIGJl IGRpZmZlcmVudGlhdGVkIHBlciBpbnN0YW5jZSAoZS5nLiBGaXJld2FsbCwgQ29udGVudHMtQ2Fj aGUsIGFuZCBWaWRlby1PcHRpbWl6ZXIpLg0KPj4+DQo+Pj4gSU1ITyxyZXF1aXJlbWVudHMgZm9y IHNjYWxhYmlsaXR5IHdpbGwgYWZmZWN0IFNGQyBhcmNoaXRlY3R1cmUgYW5kIGhlYWRlciBmb3Jt YXQuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4NCj4+PiBTaHVuc3VrZQ0KPj4+DQo+Pj4gKDIwMTQv MDIvMTIgMTg6NDkpLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+PiBE ZWFyIGFsbCwNCj4+Pj4NCj4+Pj4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVzIGlucHV0cyBm cm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+Pj4+DQo+Pj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFj a2VkIGhlcmU6DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWJv dWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTANCj4+Pj4gMQ0KPj4+PiAmDQo+Pj4+IGRpZmZ0eXBl PS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMt MDMNCj4+Pj4NCj4+Pj4gQ2hlZXJzLA0KPj4+PiBNZWQNCj4+Pj4NCj4+Pj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+Pj4+IERlIDogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91 bmNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgDQo+Pj4+IGRlIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTIgZsOpdnJpZXIgMjAxNCAxMDo0NiANCj4+ Pj4gw4ANCj4+Pj4gOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0K Pj4+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4NCj4+Pj4N Cj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+Pg0KPj4+Pg0KPj4+PiAgICAgICAgICAg VGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nDQo+Pj4+ICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0K Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcNCj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbiBQYXJrZXINCj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEtlbmdvIE5haXRvDQo+Pj4+ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm91Y2Fk YWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+ICAgICAgUGFnZXMgICAgICAgICAgIDog MTQNCj4+Pj4gICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAyLTEyDQo+Pj4+DQo+Pj4+IEFi c3RyYWN0Og0KPj4+PiAgICAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUgcmVxdWlyZW1l bnRzIGZvciB0aGUgU2VydmljZSBGdW5jdGlvbg0KPj4+PiAgICAgIENoYWluaW5nIChTRkMpLg0K Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMvDQo+Pj4+DQo+Pj4+IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+Pg0KPj4+ PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVx dWlyZW1lbnRzLTANCj4+Pj4gMw0KPj4+Pg0KPj4+Pg0KPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+Pj4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPj4+Pg0KPj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4+Pj4g SS1ELUFubm91bmNlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj4+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBo dHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIA0KPj4+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+ IHNmY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4+IC0tDQo+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCj4+PiDmnKzplpMg5L+K5LuLIChIb21tYSBTaHVuc3VrZSkNCj4+Pg0KPj4+IOaXpeac rOmbu+S/oembu+ipseagquW8j+S8muekvg0KPj4+IOODjeODg+ODiOODr+ODvOOCr+OCteODvOOD k+OCueOCt+OCueODhuODoOeglOeptuaJgA0KPj4+IOi7oumAgeOCteODvOODk+OCueWfuuebpOOD l+ODreOCuOOCp+OCr+ODiA0KPj4+IOi7oumAgeOCteODvOODk+OCueWItuW+oURQDQo+Pj4NCj4+ PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiUtemHjuW4gue3keeUujMtOS0xMQ0KPj4+IFRF TDogMDQyMi01OS0zNDg2DQo+Pj4gRS1NQUlMOiBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpw DQo+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+Pg0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g c2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+DQo+Pg0KPj4NCj4NCj4gLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBOVFQgTmV0d29yayBUZWNobm9sb2d5IExhYm9yYXRvcmll cw0KPiBLZW5nbyBOYWl0bw0KPiBFLU1haWw6IG5haXRvLmtlbmdvQGxhYi5udHQuY28uanANCj4g VEVMOiArODEgNDIyLTU5LTQ5NDkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPg0KPg0KDQoNCi0tDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOVFQgTmV0d29yayBUZWNobm9sb2d5 IExhYm9yYXRvcmllcw0KS2VuZ28gTmFpdG8NCkUtTWFpbDogbmFpdG8ua2VuZ29AbGFiLm50dC5j by5qcA0KVEVMOiArODEgNDIyLTU5LTQ5NDkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQo= From nobody Mon Feb 24 21:17:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4711A0406 for ; Mon, 24 Feb 2014 21:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 MaS9VnJSg1ss for ; Mon, 24 Feb 2014 21:17:33 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 415F11A03C8 for ; Mon, 24 Feb 2014 21:17:33 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Tue, 25 Feb 2014 00:17:32 -0500 From: Chris Frederick To: Shunsuke Homma , Ron Parker Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSAAA3T7AAACnDhIP//0f2AgAAociA= Date: Tue, 25 Feb 2014 05:17:31 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> In-Reply-To: <530BF90B.7040508@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-JMbk6ONvVYmA_xKmjosFPf2dhc Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 05:17:36 -0000 SGkgU2h1bnN1a2Utc2FuLA0KSSBhY2tub3dsZWRnZSB0aGUgY29tbWVudHMgYWJvdXQgdGhlc2Ug YmVpbmcgaW1wbGVtZW50YXRpb24gbWF0dGVycywgYnV0IEkndmUgb2ZmZXJlZCBzb21lIHRob3Vn aHRzIGlubGluZSB3aXRoIHlvdXIgbWFpbCBiZWxvdy4gVGh4LA0KL2MNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFNodW5zdWtlIEhvbW1hIFttYWlsdG86aG9tbWEuc2h1bnN1 a2VAbGFiLm50dC5jby5qcF0gDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDk6MDAg UE0NClRvOiBDaHJpcyBGcmVkZXJpY2s7IFJvbiBQYXJrZXINCkNjOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFj dGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQoNCkhpIFJvbiwg Q2hyaXMsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4NCg0KSSB0aGluayB0aGF0IHlvdXIg cG9pbnRzIGFyZSBmb2xsb3dpbmc6DQppbiBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIGFz IHVzZXIgY3VzdG9taXplZCwgcGVyLXN1YnNjcmliZXIgU0ZDcyBzaG91bGRuJ3QgYmUgbWFkZSwg YnV0IHRoZSBTRnMgc2hvdWxkIHJlY29nbml6ZSBzdWJzY3JpYmVycyBieSBJUCBhZGRyZXNzIG9y IG1ldGFkYXRhLg0KQ0Y+PiBNeSBwb2ludCB3YXMgdGhhdCBJIGRvbid0IHNlZSBpdCBhcyBkZXNp cmFibGUgdG8gaGF2ZSBzcGVjaWZpYyBwZXItc3Vic2NyaWJlciBTRkMgcnVsZXMgKGFzIGluIHN0 YXRpYyBydWxlcywgbGlrZSBzdWJzY3JpYmVyX0NocmlzPVNGQ19hX2JfYyksIHdpdGggYSBydWxl IGZvciBldmVyeSBzdWIsIGluIHRoYXQgc2Vuc2UuIEJldHRlciBpcyBhIHNjZW5hcmlvIHdoZXJl IHRoZSBTRkMgY2hhaW4gY29udHJvbGxlciBpcyBzdWJzY3JpYmVyLWF3YXJlICsgYWJsZSB0byBl dmFsdWF0ZSBtdWx0aXBsZSBvcnRob2dvbmFsIGZsb3cgKyBzdWJzY3JpYmVyIGNvbmRpdGlvbnMg aW4gcmVhbCB0aW1lLCBhbmQgZm9ybXVsYXRlIGEgY2hhaW4gb24gdGhlIGJhc2lzIG9mIHRob3Nl IGR5bmFtaWMgY29uZGl0aW9ucy4gIA0KDQpPZiBjb3Vyc2UsIGl0IGlzIG9uZSBvZiB0aGUgc29s dXRpb25zLg0KSG93ZXZlciwgaW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoYXQgU0ZzIGFzIHVzZXIg Y3VzdG9taXplZCBtaWdodCBiZSByZXF1aXJlZCB0byBoYXZlIGEgZnVuY3Rpb24gdG8gcmVjb2du aXplIGVhY2ggc3Vic2NyaWJlci4NCkNGPj4gSSB3YXNuJ3QgYWN0dWFsbHkgdGhpbmtpbmcgaW4g dGVybXMgb2YgU0YgKHJlKWNsYXNzaWZpY2F0aW9uOyBJJ3ZlIHByZXZpb3VzbHkgY29tbWVudGVk IG9uIHdoeSBJIHRoaW5rIHRoYXQgaWRlYSBpcyBzb21ld2hhdCBmcmF1Z2h0IChpLmUuIGJlY2F1 c2UgbW9kaWZpY2F0aW9uIG9mIHRoZSBmbG93IHBhdGggYnkgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdp dGhpbiB0aGUgY2hhaW4gY291bGQgcmVzdWx0IGluIGEgJ2JyZWFraW5nJyBvZiB0aGUgY2hhaW4g b3IgZmxvdy4gSWYgdGhlcmUgaXMgbm90IGJpZGlyZWN0aW9uYWwgc3ltbWV0cnkgaW4gdGhlIGZs b3cgYW5kIHNlcnZpY2UgZnVuY3Rpb24gZWxlbWVudHMgaW4gdGhlIGNoYWluIGNhbiBtYWtlIHJv dXRpbmcgZGVjaXNpb25zLCB0aGVuIHRoZXJlJ3Mgc29tZSBtZXRhZGF0YSBjb3JyZWxhdGlvbiB0 byB3b3JrIG91dCwgYXQgbWluaW11bSkuIEkgZG8gYWdyZWUgdGhhdCB0aGUgU0ZDIGNoYWluIGNv bnRyb2xsZXIgd291bGQgbmVlZCB0byBiZSBzdWJzY3JpYmVyLWF3YXJlIHRob3VnaC4NCg0KT24g dGhlIG90aGVyIGhhbmQsIEkgdGhpbmsgdGhhdCB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgZnVu Y3Rpb24gY2FuJ3QgYmUgYWRvcHRlZCwgc3VjaCBsaWtlIFNGcyBhcmUgY3VycmVudCBlcXVpcG1l bnQgdGhhdCBkb24ndCBoYXZlIGZ1bmN0aW9uIHRvIHJlY29nbml6ZSBtZXRhZGF0YS4NCkNGPj4g QWdyZWVkLiBUaGlzIHNwZWFrcyB0byBteSBjb21tZW50IGFib3ZlICsgdG8gdGhlIGFkdmFudGFn ZXMgc29tZSBvZiB1cyBoYXZlIG1lbnRpb25lZCB2aXogYSBjb25zb2xpZGF0ZWQgcG9saWN5LWJh c2VkIHN0ZWVyaW5nL1BEUC9TRkMgY2hhaW4gY29udHJvbGxlciBlbnRpdHkuIA0KDQpIb3cgZG8g d2UgaGFuZGxlIHRoZXNlIGNhc2VzPw0KQW55IG5ldyBwcm9ibGVtcyBvciByZXF1aXJlbWVudHMg bWF5IG9jY3VyPw0KDQpyZWdhcmRzLA0KDQpTaHVuc3VrZQ0KDQooMjAxNC8wMi8yNSA4OjQ2KSwg Q2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPiBZZXMsIGFncmVlZCBvbiB0aGF0Lg0KPg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwg MjAxNCA2OjQ1IFBNDQo+IFRvOiBDaHJpcyBGcmVkZXJpY2s7IOacrOmWk+S/iuS7iw0KPiBDYzog bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJF OiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogDQo+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1l bnRzLTAzLnR4dA0KPg0KPiBUaGFua3MsIENocmlzLg0KPg0KPiBJIGRvIHRoaW5rIHRoZXJlIGFy ZSBsb3RzIG9mIGVmZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNsYXNzaWZpZXIp IGFuZCBwb2xpY3kgZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhvd2V2ZXIsIGFy Y2hpdGVjdHVyYWxseSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBjby1sb2NhdGVk Lg0KPg0KPiAgICAgIFJvbg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNrQHNhbmR2aW5lLmNvbV0NCj4g U2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1OjI2IFBNDQo+IFRvOiBSb24gUGFya2Vy OyDmnKzplpPkv4rku4sNCj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246IA0KPiBkcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4NCj4gQWdyZWVkLg0KPiBUbyByZXN0 YXRlIHRoaXMgc2xpZ2h0bHksIGlmIHRoZSBTRkMgc3RlZXJpbmcvZGVjaXNpb24gbG9jdXMgaXMg Y2FwYWJsZSBvZiBldmFsdWF0aW5nIG11bHRpcGxlIG9ydGhvZ29uYWwgcG9saWN5IGNvbmRpdGlv bnMgdGhlbiB0aGlzIGlzc3VlIGlzIG9idmlhdGVkOyBzdWJzY3JpYmVycyBiZWNvbWUgYW4gYWdn cmVnYXRlIG9mICd3aGF0IHRoZXkgYXJlJyArIGFyZSBub3Qgc2ltcGx5ICd3aG8gdGhleSBhcmUn Lg0KPiBBcyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkgYmUgZGVyaXZlZCBmcm9tIExE QVAgbG9va3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQgcnVsZXMsIGV0Yy4NCj4gVG8g aWxsdXN0cmF0ZSB3LyBhbiBleGFtcGxlLCB3ZSBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2UgdGhp czoNCj4gSWYgc3Vic2NyaWJlciBYIGlzIHVzaW5nIHlvdXR1YmUsIGFuZCBpcyBvbiBhIGNvbmdl c3RlZCBjZWxsLCBhbmQgaXMgb24gYW4gaVBob25lLCBhbmQgaXMgaW4gdGhlICJHb2xkIFRpZXIi LCBhbmQsIGFuZCwgYW5kLCBhbmQsIGV0YywgdGhlbiB0aGUgY2hhaW4gY29uc2lzdHMgb2Ygc2Vy dmljZSBmdW5jdGlvbnMgYSwgYiwgYW5kIGMuDQo+IFRoZXJlJ3Mgbm8gbmVlZCB0byBlbnRlciBh IHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChvciBhbnkgc3Vic2NyaWJl cikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVjYXVzZSBhbGwgb2YgdGhl IGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNhdmUgb25lICgiaXMgb24g YSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFpbiBtaWdodCBiZSBhbHRl cmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlvbiBzZXJ2aWNlIGZ1bmN0 aW9uKS4NCj4gVGhpcyBhbHNvIGdvZXMgdG8gdGhlIGVhcmxpZXIgY29tbWVudHMgUm9uICsgSSBt YWRlIGFib3V0IA0KPiBjb25zb2xpZGF0aW5nIHRoZSBmbG93IHJlY29nbml0aW9uICsgZGVjaXNp b24tbWFraW5nIGVudGl0eSBpbiBhIA0KPiBzaW5nbGUgKHN1aXRhYmx5IHBvbGljeS1hd2FyZSkg bm9kZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgKyB0byANCj4gc2NhbGUgcHJvcGVybHkuIFRo eCwgL2MNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQo+IFNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMjMsIDIwMTQgMTA6MzkgUE0NCj4gVG86IOacrOmWk+S/iuS7iw0K PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogDQo+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVx dWlyZW1lbnRzLTAzLnR4dA0KPg0KPiBTaHVuc3VrZS1zYW4sDQo+DQo+IFdoaWxlIGEgdGhlb3Jl dGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9yIG1vcmUgU0ZDcyBwZXIgc3Vic2NyaWJl ciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBpc24ndCBwcmFjdGljYWwuICBCdXQsIHRoZXJl IGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBhc3BlY3Qgb2YgdGhlIHByb2JsZW0uICBMZXQn cyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3VzdG9taXplZCBmaXJld2FsbCBhcyBhIGh5cG90 aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBvbmx5IG9uZSBmaXJld2FsbCwgaW5zdGVh ZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2FsIHBvbGljeSBldmFsdWF0aW9uIGJhc2VkIG9u IHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBiZSB2YXN0bHkgcmVkdWNlZC4g ICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3b3VsZCBiZSB0byBzaW1wbHkgdXNlIHRoZSBz b3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9tIHRoZSBwYWNrZXQgYW5kIHNvbWUgb3V0 IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtlIExEQVAgb3IgUkFESVVTIGF0IHRoZSBmaXJl d2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBkZXRlcm1pbmUgd2hvIHRoZSBzdWJzY3JpYmVy IGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNzaWZpZXIgdG8gYWRkIGEgZGlzdGluY3Qgc3Vi c2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2VydmljZSBoZWFkZXIgKGVnLCBhbiBJTVNJ KSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQgdGhlIGZpcmV3YWxsLg0KPg0KPiBJZiB0aGUg cHJvYmxlbSBpcyBjaGFuZ2VkIHNsaWdodGx5IHNvIHRoYXQgdGhlIGZpcmV3YWxsIHBvbGljeSBp cyBwZXIgZ3JvdXAgb2Ygc3Vic2NyaWJlcnMsIHdoZXJlIHRoZXJlIGFyZSBwZXJoYXBzIDEwcyBv ZiBncm91cHMsIHRoZW4geWV0IGFub3RoZXIgYXBwcm9hY2ggaXMgdG8gbW9kZWwgdGhlIGZpcmV3 YWxsIGFzIGEgZGlzdGluY3QgbG9naWNhbCBmaXJld2FsbCBwZXIgZmlyZXdhbGwgcG9saWN5IHNl dCAodGhleSBjb3VsZCBhbGwgcmVzaWRlIGluIHRoZSBzYW1lIG1hY2hpbmUgb3IgVk0pIGFuZCB0 byBjb29yZGluYXRlIHRoZSBjbGFzc2lmaWVyJ3MgcG9saWN5IGFjY29yZGluZ2x5Lg0KPg0KPiAg ICAgUm9uDQo+DQo+DQo+PiBPbiBGZWIgMjMsIDIwMTQsIGF0IDEwOjA0IFBNLCAi5pys6ZaT5L+K 5LuLIiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4gd3JvdGU6DQo+Pg0KPj4gSGkgTWVk LA0KPj4NCj4+IEluIHRlcm1zIG9mIHlvdXIgY29tbWVudCwgSSBhc3N1bWVkIHNvbWUgdXNlIGNh c2VzIGFib3V0IHNjYWxhYmlsaXR5IHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNz aW9uIGFib3V0IHNjYWxhYmlsaXR5IGNvbnNpZGVyYXRpb25zLg0KPj4gI0kgd29yayB3aXRoIEsu TmFpdG8sIGNvLWF1dGhvciBvZiByZXF1aXJlbWVudCBkcmFmdCBhbmQgdGhpbmsgc2NhbGFiaWxp dHkgaXMgb25lIG9mIGltcG9ydGFudCB0aGluZ3MgdG8gY29uc2lkZXIuDQo+Pg0KPj4gQXNzdW1p bmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0aGUgbWFuYWdlbWVudCBtZWNoYW5p c20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQgcmVxdWlyZSBoaWdoIHNjYWxhYmls aXR5Lg0KPj4NCj4+IDEuIFRoZSBjYXNlIHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0K Pj4gSSBhc3N1bWVkIHRoYXQgdGhlIHVuaXQgb2YgYXBwbHlpbmcgU0ZDIHRvIHRyYWZmaWMgaXMg Zm9sbG93aW5nOw0KPj4gICAtIGdyb3VwaW5nOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVj aWZpYyBTRkMgZm9yIGVhY2ggc2VydmljZSwNCj4+ICAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9y IHJlZ2lvbiwNCj4+ICAgLSBwZXItc3Vic2NyaWJlcjogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGgg c3BlY2lmaWMgU0ZDIGZvciBlYWNo44CADQo+PiAgICAgc3Vic2NyaWJlciAoZS5nLiBwZXIgSVAg YWRkcmVzcywgVkxBTiBJRCBldC5hbCksDQo+PiAgIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMgYXBw bGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPj4g44CA44CAYW5k IG9iamVjdGl2ZSAoZS5nLiBwcmUgVVJMLCBhcHBsaWNhdGlvbiBldC5hbCkuDQo+Pg0KPj4gU29t ZSBvZiB0aGUgc2VydmljZSBwcm92aWRlcnMgaGF2ZSBlbm9ybW91cyBudW1iZXIgb2Ygc3Vic2Ny aWJlcnMsIGFuZCB0aGUgbnVtYmVyIG9mIHN1YnNjcmliZXJzIGlzIHVwIHRvIHNldmVyYWwgdGVu cyBvciBodW5kcmVkcyBvZiBtaWxsaW9uLiBUaGVyZWZvcmUsIGluIGNhc2VzIG9mIHBlci1zdWJz Y3JpYmVyIGFuZCBwZXItZmxvdywgdGhlIG51bWJlciBvZiBTRkNzIG1pZ2h0IGluY3JlYXNlIGV4 cGxvc2l2ZWx5LiBQZXItc3Vic2NyaWJlciBTRkNzIHdvdWxkIGJlIG5lZWRlZCBpbiB0aGUgY2Fz ZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBkZWRpY2F0ZWQgdG8gZWFjaCB1c2VyKGUuZy4gdkNQ RSBhcyB1c2VyIGN1c3RvbWl6ZWQpLg0KPj4NCj4+IEFsc28sIGluIGNhc2Ugb2YgZ3JvdXBpbmcs IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMgYXJlIGRpZmZlcmVu dCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJlZ2lvbiwgdGhlIG51 bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZlcmVu dCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+Pg0KPj4gMi4gVGhlIGNh c2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgdGhhdCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVh Y2ggaW5zdGFuY2U6DQo+PiBJbiBjYXNlIHRoYXQgdGhlcmUgYXJlIFNGcyB3aXRoIHRoZSBzYW1l IGZ1bmN0aW9uIGluIHRoZSBuZXR3b3JrIGFuZCB0aGUgU0ZzIG11c3QgYmUgY2xhc3NpZmllZCBm b3IgZWFjaCBpbnN0YW5jZSwgdGhlIGNvbWJpbmF0aW9uIG9mIFNGcyBtaWdodCBpbmNyZWFzZS4N Cj4+IFRoZSBTRnMgdGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBi ZSBkaWZmZXJlbnRpYXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNh Y2hlLCBhbmQgVmlkZW8tT3B0aW1pemVyKS4NCj4+DQo+PiBJTUhPLHJlcXVpcmVtZW50cyBmb3Ig c2NhbGFiaWxpdHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1h dC4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gU2h1bnN1a2UNCj4+DQo+PiAoMjAxNC8wMi8xMiAx ODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+Pj4gRGVhciBhbGws DQo+Pj4NCj4+PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJl cHJlc2VudGF0aXZlcy4NCj4+Pg0KPj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFja2VkIGhlcmU6DQo+ Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtYm91Y2FkYWlyLXNmYy1y ZXF1aXJlbWVudHMtMDENCj4+PiAmDQo+Pj4gZGlmZnR5cGU9LS1odG1sJnN1Ym1pdD1HbyEmdXJs Mj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+DQo+Pj4gQ2hlZXJzLA0K Pj4+IE1lZA0KPj4+DQo+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gRGUgOiBJ LUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCANCj4+PiBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1lcmNyZWRp IDEyIGbDqXZyaWVyIDIwMTQgMTA6NDYgDQo+Pj4gw4ANCj4+PiA6IGktZC1hbm5vdW5jZUBpZXRm Lm9yZyBPYmpldCA6IEktRCBBY3Rpb246DQo+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJl bWVudHMtMDMudHh0DQo+Pj4NCj4+Pg0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pg0K Pj4+DQo+Pj4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nDQo+Pj4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9o YW1lZCBCb3VjYWRhaXINCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaHJpc3RpYW4g SmFjcXVlbmV0DQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcN Cj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2FybG9zIFBpZ25hdGFybw0KPj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEtlbmdvIE5haXRvDQo+Pj4gICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWJv dWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+ICAgICBQYWdlcyAgICAgICAgICAg OiAxNA0KPj4+ICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAyLTEyDQo+Pj4NCj4+PiBBYnN0 cmFjdDoNCj4+PiAgICAgVGhpcyBkb2N1bWVudCBpZGVudGlmaWVzIHRoZSByZXF1aXJlbWVudHMg Zm9yIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uDQo+Pj4gICAgIENoYWluaW5nIChTRkMpLg0KPj4+DQo+ Pj4NCj4+Pg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNh ZGFpci1zZmMtcmVxdWlyZW1lbnRzLw0KPj4+DQo+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+Pg0KPj4+IEEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+ DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4NCj4+ PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdA0KPj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj4gSW50ZXJuZXQt RHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+ Pj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+Pg0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPj4NCj4+IC0tDQo+PiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4g5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1 a2UpDQo+Pg0KPj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+PiDjg43jg4Pjg4jj g6/jg7zjgq/jgrXjg7zjg5Pjgrnjgrfjgrnjg4bjg6DnoJTnqbbmiYANCj4+IOi7oumAgeOCteOD vOODk+OCueWfuuebpOODl+ODreOCuOOCp+OCr+ODiA0KPj4g6Lui6YCB44K144O844OT44K55Yi2 5b6hRFANCj4+DQo+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiUtemHjuW4gue3keeUujMt OS0xMQ0KPj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4+IEUtTUFJTDogaG9tbWEuc2h1bnN1a2VAbGFi Lm50dC5jby5qcA0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBs aXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPg0KPg0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpTaHVuc3VrZSBIb21tYQ0KPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+DQpURUw6ICs4 MSAwNDIyIDU5IDM0ODYNCkZBWDogKzgxIDA0MjIgNjAgNzQ2MA0KDQpOVFQgTmV0d29yayBTZXJ2 aWNlIFN5c3RlbSBMYWJzLg0KTXVzYXNoaW5vIGNpdHksIFRva3lvLCBKYXBhbg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Tue Feb 25 00:47:54 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CCE1A03C5 for ; Tue, 25 Feb 2014 00:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.26 X-Spam-Level: * X-Spam-Status: No, score=1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 vioxpiqMpyhQ for ; Tue, 25 Feb 2014 00:47:49 -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 5AF9A1A03BB for ; Tue, 25 Feb 2014 00:47:49 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P8lidi001906; Tue, 25 Feb 2014 17:47:44 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C5526E0144; Tue, 25 Feb 2014 17:47:44 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B91B2E0142; Tue, 25 Feb 2014 17:47:44 +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 s1P8lXFj026923; Tue, 25 Feb 2014 17:47:44 +0900 Message-ID: <530C58E6.10107@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 17:48:38 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> <530BD76B.709@joelhalpern.com> <5602569641FB314FB4D9AD5659D41B9C2C14E78FF8@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C14E78FF8@WSMSG3154V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: "Pham, Chuong D" , "Joel M. Halpern" , Ron Parker X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ksFt0ahPcqtIGZMhMoLornFF_rs Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 08:47:52 -0000 Hi Chuong, Joel, >Agree that the number of service chains is needed to be limited but >classifying each subscriber into these service chains is an important >requirement. I agree. In my opinion, we should realize that there are some problems or requirements in case that the number of subscribers and SFs are increase, and confirm what the problems and requirements are. Regards, Shunsuke (2014/02/25 8:41), Pham, Chuong D wrote: > Joel, > Fully agree. I said the same but reading my message again, I realised that I might have caused confusion. Agree that the number of service chains is needed to be limited but classifying each subscriber into these service chains is an important requirement. > Regards, > Chuong > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, 25 February 2014 10:36 AM > To: Pham, Chuong D; Ron Parker; 本間俊介 > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Being able to give each subscriber the services they want is clearly necessary for any mobile, residential, or even business service in this environment. > > But that does not mean we should want or expect that the number of different service chains is on the same order as the number of users. > One of the advantages of ingress classification is that many users can use the same service chain. > > Yours, > Joel > > On 2/24/14, 6:11 PM, Pham, Chuong D wrote: >> Hi all, >> >> In Mobile, per-subscriber value-added-service (VAS) is valuable and is a culture of personalisation i.e. a user is a sole owner of a device. To date with the legacy circuit-switched voice-centric network aka CS voice, we already have per-subscriber VAS in the form of supplementary services i.e. voice mail, diversion etc. and in the Packet Data world, the PCRF architecture was developed with that (per-subscriber service) in mind. What is lacking at the moment is the per-subscriber SFC on the Gi/SGi user plane capability to monetize with VAS as what we have been doing with CS. >> >> In my opinion, it is a very important aspect of SFC. I agree there will be scalability challenge but the value of this capability justifies the challenge. The scalability as Ron has indicated, will be more on the "control plane" which needs to a) identify the user and b)determine the SFs required and c)signal the network and the SFs for SFC. The Mobile network with personalisation culture in mind has plenty of resources for the SFC to leverage for per-subscribers service. >> >> The number of SFCs may not be high as the number of VASes normally will be limited to a small number. We don't need per-subscriber SFC but a capability to map each subscriber to one of the SFC in the VAS catalogue. Take Ron's example of a per-subscriber's firewall. A service provider would not likely to offer a per-subscriber network-based FW where a subscriber can use a portal to configure the way they can do on a RG or a software FW on a PC. It would likely offer a generic Gi stateful firewall so that unsolicited traffic cannot be sent to the UE. >> >> As we are looking at a Requirements document here, we should focus more on the requirements (in this document) rather than go into solution mode and perhaps think ahead that it may be too hard then back out the requirements. >> >> I fully agree, scalability will likely influence architecture (solution mode) so it needs to be included. >> >> Regards, >> Chuong >> >> >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, 24 February 2014 2:39 PM >> To: 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Shunsuke-san, >> >> While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. >> >> If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. >> >> Ron >> >> >>> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >>> >>> Hi Med, >>> >>> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >>> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >>> >>> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >>> >>> 1. The case that the types of SF increase: >>> I assumed that the unit of applying SFC to traffic is following; >>> - grouping: traffic is applied with specific SFC for each service, >>> enterprise customer or region, >>> - per-subscriber: traffic is applied with specific SFC for each　 >>> subscriber (e.g. per IP address, VLAN ID et.al), >>> - per-flow: traffic is applied with specific SFC for each subscriber, >>> 　　and objective (e.g. pre URL, application et.al). >>> >>> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >>> >>> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >>> >>> 2. The case that there are some SFs that must be classified for each instance: >>> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >>> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>> >>> IMHO,requirements for scalability will affect SFC architecture and header format. >>> >>> Thanks, >>> >>> Shunsuke >>> >>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>> >>>> This new version integrates inputs from NTT representatives. >>>> >>>> The diff can be tracked here: >>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01 >>>> & >>>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 >>>> À >>>> : i-d-announce@ietf.org Objet : I-D Action: >>>> draft-boucadair-sfc-requirements-03.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Requirements for Service Function Chaining >>>> Authors : Mohamed Boucadair >>>> Christian Jacquenet >>>> Yuanlong Jiang >>>> Ron Parker >>>> Carlos Pignataro >>>> Kengo Naito >>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>> Pages : 14 >>>> Date : 2014-02-12 >>>> >>>> Abstract: >>>> This document identifies the requirements for the Service Function >>>> Chaining (SFC). >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> -- >>> ******************************************** >>> 本間 俊介 (Homma Shunsuke) >>> >>> 日本電信電話株å¼ä¼šç¤¾ >>> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >>> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >>> 転é€ã‚µãƒ¼ãƒ“ス制御DP >>> >>> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >>> TEL: 0422-59-3486 >>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>> ******************************************** >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------- Shunsuke Homma TEL: +81 0422 59 3486 FAX: +81 0422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Feb 25 01:50:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA771A0660 for ; Tue, 25 Feb 2014 01:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 luhITqctr9o9 for ; Tue, 25 Feb 2014 01:50:36 -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 83D6B1A0425 for ; Tue, 25 Feb 2014 01:50:35 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P9oW0g003788; Tue, 25 Feb 2014 18:50:32 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 3A32DE0144; Tue, 25 Feb 2014 18:50:32 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2E5DDE0142; Tue, 25 Feb 2014 18:50:32 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1P9oVfT026871; Tue, 25 Feb 2014 18:50:32 +0900 Message-ID: <530C66E5.1050905@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 18:48:21 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ron Parker References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF244.6080000@lab.ntt.co.jp> <530BF9CF.2020708@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Fhmqf6c3LnM_zNZxf2yO_SqPJOM Cc: Chris Frederick , "mohamed.boucadair@orange.com" , =?UTF-8?B?IuacrOmWk+S/iuS7iyhob21tYSBzaHVuc3VrZSki?= , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 09:50:38 -0000 Ron, (2014/02/25 11:13), Ron Parker wrote: > Yes, all of that is an implementation matter. > > Wrt load balancers, see some of the previous discussion that was attempting to differentiate load balancing of midbox service functions vs. load balancer as a service function. Thank you for pointing. > In the former case, we may choose to make the classifier/PDP aware of the fact that a service function is multiply instantiated. Okay, and in any case, the common fact is that the number of service chains is needed to be limited but classifying each subscriber into service chains, and recognize policies, is an important requirement, as Chuong says in the thread. I also agree this point. Thanks, Kengo > > Ron > > > -----Original Message----- > From: Kengo Naito [mailto:naito.kengo@lab.ntt.co.jp] > Sent: Monday, February 24, 2014 9:03 PM > To: Ron Parker > Cc: Chris Frederick; mohamed.boucadair@orange.com; "本間俊介(homma shunsuke)"; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Ron, > > In terms of classifiers, I agree with you that it is an implementation matter. > To avoid misunderstanding, let me ask you this: > Then, implementers should also determine what metadata to collect at the classifier (with policy evaluator), and also, how to handle it in SFs, maybe in virtual appliances, and also maybe in virtual switches (or load balancers) in front of them, right? > > Kengo > > (2014/02/25 10:43), Ron Parker wrote: >> Kengo-san, >> >> We've tried to leave it up to the innovation of the implementer to determine what metadata to collect, how to collect it, and how to implement policy evaluation that examines the metadata along with the flow properties. In practice, this means that some implementations could combine, for example, a 3gpp PDN-Gateway, SFC classifier, and SFC PDP, bringing together subscriber information, flow information, and service orchestration to one place. However, all of those functions are logically separate and other implementers may find reason to not co-locate them. >> >> Ron >> >> >> -----Original Message----- >> From: Kengo Naito [mailto:naito.kengo@lab.ntt.co.jp] >> Sent: Monday, February 24, 2014 8:31 PM >> To: Chris Frederick; Ron Parker >> Cc: "本間俊介(homma shunsuke)"; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Hello Ron, Chris, >> >> I also understood that evaluating policy conditions is an efficient function for recognizing subscribers. >> Do you think this should be one of the requirements? >> >> If there is no statements (or definitions), there would be SFs that may not co-operate with sfc evaluated policies. >> >> Thanks, >> Kengo >> >> (2014/02/25 8:46), Chris Frederick wrote: >>> Yes, agreed on that. >>> >>> -----Original Message----- >>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> Sent: Monday, February 24, 2014 6:45 PM >>> To: Chris Frederick; 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: RE: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Thanks, Chris. >>> >>> I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Chris Frederick [mailto:cfrederick@sandvine.com] >>> Sent: Monday, February 24, 2014 5:26 PM >>> To: Ron Parker; 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: RE: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Agreed. >>> To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. >>> As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. >>> To illustrate w/ an example, we might say something like this: >>> If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. >>> There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). >>> This also goes to the earlier comments Ron + I made about >>> consolidating the flow recognition + decision-making entity in a >>> single (suitably policy-aware) node to reduce the complexity + to >>> scale properly. Thx, /c >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Sunday, February 23, 2014 10:39 PM >>> To: 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Shunsuke-san, >>> >>> While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. >>> >>> If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. >>> >>> Ron >>> >>> >>>> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >>>> >>>> Hi Med, >>>> >>>> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >>>> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >>>> >>>> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >>>> >>>> 1. The case that the types of SF increase: >>>> I assumed that the unit of applying SFC to traffic is following; >>>> - grouping: traffic is applied with specific SFC for each service, >>>> enterprise customer or region, >>>> - per-subscriber: traffic is applied with specific SFC for each　 >>>> subscriber (e.g. per IP address, VLAN ID et.al), >>>> - per-flow: traffic is applied with specific SFC for each subscriber, >>>> 　　and objective (e.g. pre URL, application et.al). >>>> >>>> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >>>> >>>> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >>>> >>>> 2. The case that there are some SFs that must be classified for each instance: >>>> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >>>> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>>> >>>> IMHO,requirements for scalability will affect SFC architecture and header format. >>>> >>>> Thanks, >>>> >>>> Shunsuke >>>> >>>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>>> Dear all, >>>>> >>>>> This new version integrates inputs from NTT representatives. >>>>> >>>>> The diff can be tracked here: >>>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-0 >>>>> 1 >>>>> & >>>>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> -----Message d'origine----- >>>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>>>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 >>>>> À >>>>> : i-d-announce@ietf.org Objet : I-D Action: >>>>> draft-boucadair-sfc-requirements-03.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> >>>>> >>>>> Title : Requirements for Service Function Chaining >>>>> Authors : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Yuanlong Jiang >>>>> Ron Parker >>>>> Carlos Pignataro >>>>> Kengo Naito >>>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>>> Pages : 14 >>>>> Date : 2014-02-12 >>>>> >>>>> Abstract: >>>>> This document identifies the requirements for the Service Function >>>>> Chaining (SFC). >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-0 >>>>> 3 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> -- >>>> ******************************************** >>>> 本間 俊介 (Homma Shunsuke) >>>> >>>> 日本電信電話株å¼ä¼šç¤¾ >>>> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >>>> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >>>> 転é€ã‚µãƒ¼ãƒ“ス制御DP >>>> >>>> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >>>> TEL: 0422-59-3486 >>>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>>> ******************************************** >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >> -- >> ---------------------------------------- >> NTT Network Technology Laboratories >> Kengo Naito >> E-Mail: naito.kengo@lab.ntt.co.jp >> TEL: +81 422-59-4949 >> ---------------------------------------- >> >> >> _______________________________________________ >> 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 > ---------------------------------------- > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From nobody Tue Feb 25 04:24:56 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46F1A06C6 for ; Tue, 25 Feb 2014 04:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 sFAkF6mHp2wP for ; Tue, 25 Feb 2014 04:24:52 -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 20C991A0348 for ; Tue, 25 Feb 2014 04:24:52 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1PCOk6I023282; Tue, 25 Feb 2014 21:24:46 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A462AE0144; Tue, 25 Feb 2014 21:24:46 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 98312E0142; Tue, 25 Feb 2014 21:24:46 +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 s1PCOEdZ004015; Tue, 25 Feb 2014 21:24:46 +0900 Message-ID: <530C8BAF.3040208@lab.ntt.co.jp> Date: Tue, 25 Feb 2014 21:25:19 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: Chris Frederick , Ron Parker X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PX8NHFSaS1UOJgAJ99zDMXe3asA Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 12:24:55 -0000 Hi Chris, Do you mean that, for retaining integrity of chains, management of subscribers should be provided not by SFs, but by SFC controller? If so, the problem is that the number of chains that SFC controller must manage is large, and it is the same problem I said, I think. Regards, Shunsuke (2014/02/25 14:17), Chris Frederick wrote: > Hi Shunsuke-san, > I acknowledge the comments about these being implementation matters, but I've offered some thoughts inline with your mail below. Thx, > /c > > -----Original Message----- > From: Shunsuke Homma [mailto:homma.shunsuke@lab.ntt.co.jp] > Sent: Monday, February 24, 2014 9:00 PM > To: Chris Frederick; Ron Parker > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Hi Ron, Chris, > > Thank you for your reply. > > I think that your points are following: > in case that there are some SFs as user customized, per-subscriber SFCs shouldn't be made, but the SFs should recognize subscribers by IP address or metadata. > CF>> My point was that I don't see it as desirable to have specific per-subscriber SFC rules (as in static rules, like subscriber_Chris=SFC_a_b_c), with a rule for every sub, in that sense. Better is a scenario where the SFC chain controller is subscriber-aware + able to evaluate multiple orthogonal flow + subscriber conditions in real time, and formulate a chain on the basis of those dynamic conditions. > > Of course, it is one of the solutions. > However, in this case, I think that SFs as user customized might be required to have a function to recognize each subscriber. > CF>> I wasn't actually thinking in terms of SF (re)classification; I've previously commented on why I think that idea is somewhat fraught (i.e. because modification of the flow path by a service function within the chain could result in a 'breaking' of the chain or flow. If there is not bidirectional symmetry in the flow and service function elements in the chain can make routing decisions, then there's some metadata correlation to work out, at minimum). I do agree that the SFC chain controller would need to be subscriber-aware though. > > On the other hand, I think that there are cases when the function can't be adopted, such like SFs are current equipment that don't have function to recognize metadata. > CF>> Agreed. This speaks to my comment above + to the advantages some of us have mentioned viz a consolidated policy-based steering/PDP/SFC chain controller entity. > > How do we handle these cases? > Any new problems or requirements may occur? > > regards, > > Shunsuke > > (2014/02/25 8:46), Chris Frederick wrote: >> Yes, agreed on that. >> >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, February 24, 2014 6:45 PM >> To: Chris Frederick; 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: RE: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Thanks, Chris. >> >> I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. >> >> Ron >> >> >> -----Original Message----- >> From: Chris Frederick [mailto:cfrederick@sandvine.com] >> Sent: Monday, February 24, 2014 5:26 PM >> To: Ron Parker; 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: RE: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Agreed. >> To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. >> As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. >> To illustrate w/ an example, we might say something like this: >> If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. >> There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). >> This also goes to the earlier comments Ron + I made about >> consolidating the flow recognition + decision-making entity in a >> single (suitably policy-aware) node to reduce the complexity + to >> scale properly. Thx, /c >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Sunday, February 23, 2014 10:39 PM >> To: 本間俊介 >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Shunsuke-san, >> >> While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. >> >> If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. >> >> Ron >> >> >>> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >>> >>> Hi Med, >>> >>> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >>> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >>> >>> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >>> >>> 1. The case that the types of SF increase: >>> I assumed that the unit of applying SFC to traffic is following; >>> - grouping: traffic is applied with specific SFC for each service, >>> enterprise customer or region, >>> - per-subscriber: traffic is applied with specific SFC for each　 >>> subscriber (e.g. per IP address, VLAN ID et.al), >>> - per-flow: traffic is applied with specific SFC for each subscriber, >>> 　　and objective (e.g. pre URL, application et.al). >>> >>> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >>> >>> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >>> >>> 2. The case that there are some SFs that must be classified for each instance: >>> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >>> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>> >>> IMHO,requirements for scalability will affect SFC architecture and header format. >>> >>> Thanks, >>> >>> Shunsuke >>> >>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>> >>>> This new version integrates inputs from NTT representatives. >>>> >>>> The diff can be tracked here: >>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-01 >>>> & >>>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 >>>> À >>>> : i-d-announce@ietf.org Objet : I-D Action: >>>> draft-boucadair-sfc-requirements-03.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Requirements for Service Function Chaining >>>> Authors : Mohamed Boucadair >>>> Christian Jacquenet >>>> Yuanlong Jiang >>>> Ron Parker >>>> Carlos Pignataro >>>> Kengo Naito >>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>> Pages : 14 >>>> Date : 2014-02-12 >>>> >>>> Abstract: >>>> This document identifies the requirements for the Service Function >>>> Chaining (SFC). >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-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/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> -- >>> ******************************************** >>> 本間 俊介 (Homma Shunsuke) >>> >>> 日本電信電話株å¼ä¼šç¤¾ >>> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >>> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >>> 転é€ã‚µãƒ¼ãƒ“ス制御DP >>> >>> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >>> TEL: 0422-59-3486 >>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>> ******************************************** >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> > > > -- > ---------------------------------- > Shunsuke Homma > > TEL: +81 0422 59 3486 > FAX: +81 0422 60 7460 > > NTT Network Service System Labs. > Musashino city, Tokyo, Japan > ---------------------------------- > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------- Shunsuke Homma TEL: +81 0422 59 3486 FAX: +81 0422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Feb 25 06:43:45 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAF81A0763 for ; Tue, 25 Feb 2014 06:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 ZfFKZHwLvFwa for ; Tue, 25 Feb 2014 06:43:38 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 875CF1A075F for ; Tue, 25 Feb 2014 06:43:38 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%20]) with mapi id 14.01.0339.001; Tue, 25 Feb 2014 09:43:37 -0500 From: Chris Frederick To: Shunsuke Homma , Ron Parker Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSAAA3T7AAACnDhIP//0f2AgAAociCAAIZdgIAAOz2A Date: Tue, 25 Feb 2014 14:43:37 +0000 Message-ID: <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> In-Reply-To: <530C8BAF.3040208@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.91.160.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cyySnlwF_qQcc0vt94lmpK3VOIw Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 14:43:42 -0000 SGkgU2h1bnN1a2Utc2FuLA0KSSByZWNvZ25pemUgdGhhdCB1bHRpbWF0ZWx5LCB0aGlzIGlzIGFu IGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIGFuZCBub3Qgc29tZXRoaW5nIHRvIGJlIG1hbmRhdGVk IGFzIGEgaGFyZCAncnVsZScuIEkganVzdCB3YW50ZWQgdG8gaGlnaGxpZ2h0IHdoYXQgaXMgcG9z c2libGUgKyB3aGF0IHdlIGJlbGlldmUgdG8gYmUgYmVzdCBwcmFjdGljZXMgaW4gdGhpcyBhcmVh LCBiYXNlZCBvbiBvdXIgZXhwZXJpZW5jZS4NClRoYXQgc2FpZCwgeWVzLCBJIGJlbGlldmUgdGhh dCBpbiBwcmFjdGljYWwgKHJlYWwtd29ybGQpIHRlcm1zLCBpdCBtYWtlcyBzZW5zZSB0byBkZWVt cGhhc2l6ZSB0aGUgJyhyZSljbGFzc2lmaWNhdGlvbicgcm9sZSBvZiBTRnMgaW4gbW9zdCBjYXNl cywgZm9yIHJlYXNvbnMgSSd2ZSBzdGF0ZWQgcHJldmlvdXNseSAocXVlc3Rpb25zIG9mIG1ldGFk YXRhIHNoYXJpbmcgYmV0d2VlbiBTRnMsIGlzc3VlcyByZWxhdGVkIHRvIHJldGFpbmluZyBpbnRl Z3JpdHkgb2YgY2hhaW5zL2JyZWFraW5nIGZsb3dzLCBldGMuKS4NClRvIHlvdXIgY29tbWVudCBh Ym91dCBzY2FsaW5nIHRoZSBTRkMgQ29udHJvbGxlciwgSSB3b3VsZCBqdXN0IHNheSB0aGF0IHRo ZXJlIGFyZSBjb21tZXJjaWFsbHkgZGVwbG95ZWQgU0ZDIENvbnRyb2xsZXJzIHRvZGF5IHRoYXQg ZG8gdGhpcywgaS5lLiBzaXQgaW5saW5lIGluIGNvbnN1bWVyIG5ldHdvcmtzLCByZWNlaXZlL2lu c3BlY3QgbWlsbGlvbnMgb2YgY29uY3VycmVudCBiaWRpcmVjdGlvbmFsIGZsb3dzLCArIG1ha2Ug cmVhbC10aW1lIFNGQyBzdGVlcmluZyBhbmQgc2VxdWVuY2luZyBkZWNpc2lvbnMgYmFzZWQgb24g Zmxvdywgc3Vic2NyaWJlciwgc2Vzc2lvbiwgYW5kIG5ldHdvcmsgY29uZGl0aW9ucy4gDQpPYnZp b3VzbHksIGRpZmZlcmVuY2VzIGluIHZlbmRvciBjYXBhYmlsaXRpZXMsIGFzIHdlbGwgYXMgYXJj aGl0ZWN0dXJhbCBkZWNpc2lvbnMgdml6IGNvbnNvbGlkYXRpbmcgdnMuIGRpc3RyaWJ1dGluZyBk aWZmZXJlbnQgU0ZDIGZ1bmN0aW9ucyBsaWtlIGZsb3cgY2xhc3NpZmljYXRpb24sIFBEUC9TRkMg Q29udHJvbGxlciwgc3RlZXJpbmcvbGIsIGV0YywgYWxsIHdpbGwgaGF2ZSBhbiBpbXBhY3QgaGVy ZS4gQmVzdCwNCi9jDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaHVuc3Vr ZSBIb21tYSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanBdIA0KU2VudDogVHVl c2RheSwgRmVicnVhcnkgMjUsIDIwMTQgNzoyNSBBTQ0KVG86IENocmlzIEZyZWRlcmljazsgUm9u IFBhcmtlcg0KQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJl cXVpcmVtZW50cy0wMy50eHQNCg0KSGkgQ2hyaXMsDQoNCkRvIHlvdSBtZWFuIHRoYXQsIGZvciBy ZXRhaW5pbmcgaW50ZWdyaXR5IG9mIGNoYWlucywgbWFuYWdlbWVudCBvZiBzdWJzY3JpYmVycyBz aG91bGQgYmUgcHJvdmlkZWQgbm90IGJ5IFNGcywgYnV0IGJ5IFNGQyBjb250cm9sbGVyPw0KDQpJ ZiBzbywgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGNoYWlucyB0aGF0IFNGQyBj b250cm9sbGVyIG11c3QgbWFuYWdlIGlzIGxhcmdlLCBhbmQgaXQgaXMgdGhlIHNhbWUgcHJvYmxl bSBJIHNhaWQsIEkgdGhpbmsuDQoNClJlZ2FyZHMsDQoNClNodW5zdWtlDQoNCigyMDE0LzAyLzI1 IDE0OjE3KSwgQ2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPiBIaSBTaHVuc3VrZS1zYW4sDQo+IEkg YWNrbm93bGVkZ2UgdGhlIGNvbW1lbnRzIGFib3V0IHRoZXNlIGJlaW5nIGltcGxlbWVudGF0aW9u IG1hdHRlcnMsIA0KPiBidXQgSSd2ZSBvZmZlcmVkIHNvbWUgdGhvdWdodHMgaW5saW5lIHdpdGgg eW91ciBtYWlsIGJlbG93LiBUaHgsIC9jDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFNodW5zdWtlIEhvbW1hIFttYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5j by5qcF0NCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA5OjAwIFBNDQo+IFRvOiBD aHJpcyBGcmVkZXJpY2s7IFJvbiBQYXJrZXINCj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246 IA0KPiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4NCj4gSGkgUm9u LCBDaHJpcywNCj4NCj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPg0KPiBJIHRoaW5rIHRo YXQgeW91ciBwb2ludHMgYXJlIGZvbGxvd2luZzoNCj4gaW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBz b21lIFNGcyBhcyB1c2VyIGN1c3RvbWl6ZWQsIHBlci1zdWJzY3JpYmVyIFNGQ3Mgc2hvdWxkbid0 IGJlIG1hZGUsIGJ1dCB0aGUgU0ZzIHNob3VsZCByZWNvZ25pemUgc3Vic2NyaWJlcnMgYnkgSVAg YWRkcmVzcyBvciBtZXRhZGF0YS4NCj4gQ0Y+PiBNeSBwb2ludCB3YXMgdGhhdCBJIGRvbid0IHNl ZSBpdCBhcyBkZXNpcmFibGUgdG8gaGF2ZSBzcGVjaWZpYyBwZXItc3Vic2NyaWJlciBTRkMgcnVs ZXMgKGFzIGluIHN0YXRpYyBydWxlcywgbGlrZSBzdWJzY3JpYmVyX0NocmlzPVNGQ19hX2JfYyks IHdpdGggYSBydWxlIGZvciBldmVyeSBzdWIsIGluIHRoYXQgc2Vuc2UuIEJldHRlciBpcyBhIHNj ZW5hcmlvIHdoZXJlIHRoZSBTRkMgY2hhaW4gY29udHJvbGxlciBpcyBzdWJzY3JpYmVyLWF3YXJl ICsgYWJsZSB0byBldmFsdWF0ZSBtdWx0aXBsZSBvcnRob2dvbmFsIGZsb3cgKyBzdWJzY3JpYmVy IGNvbmRpdGlvbnMgaW4gcmVhbCB0aW1lLCBhbmQgZm9ybXVsYXRlIGEgY2hhaW4gb24gdGhlIGJh c2lzIG9mIHRob3NlIGR5bmFtaWMgY29uZGl0aW9ucy4NCj4NCj4gT2YgY291cnNlLCBpdCBpcyBv bmUgb2YgdGhlIHNvbHV0aW9ucy4NCj4gSG93ZXZlciwgaW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRo YXQgU0ZzIGFzIHVzZXIgY3VzdG9taXplZCBtaWdodCBiZSByZXF1aXJlZCB0byBoYXZlIGEgZnVu Y3Rpb24gdG8gcmVjb2duaXplIGVhY2ggc3Vic2NyaWJlci4NCj4gQ0Y+PiBJIHdhc24ndCBhY3R1 YWxseSB0aGlua2luZyBpbiB0ZXJtcyBvZiBTRiAocmUpY2xhc3NpZmljYXRpb247IEkndmUgcHJl dmlvdXNseSBjb21tZW50ZWQgb24gd2h5IEkgdGhpbmsgdGhhdCBpZGVhIGlzIHNvbWV3aGF0IGZy YXVnaHQgKGkuZS4gYmVjYXVzZSBtb2RpZmljYXRpb24gb2YgdGhlIGZsb3cgcGF0aCBieSBhIHNl cnZpY2UgZnVuY3Rpb24gd2l0aGluIHRoZSBjaGFpbiBjb3VsZCByZXN1bHQgaW4gYSAnYnJlYWtp bmcnIG9mIHRoZSBjaGFpbiBvciBmbG93LiBJZiB0aGVyZSBpcyBub3QgYmlkaXJlY3Rpb25hbCBz eW1tZXRyeSBpbiB0aGUgZmxvdyBhbmQgc2VydmljZSBmdW5jdGlvbiBlbGVtZW50cyBpbiB0aGUg Y2hhaW4gY2FuIG1ha2Ugcm91dGluZyBkZWNpc2lvbnMsIHRoZW4gdGhlcmUncyBzb21lIG1ldGFk YXRhIGNvcnJlbGF0aW9uIHRvIHdvcmsgb3V0LCBhdCBtaW5pbXVtKS4gSSBkbyBhZ3JlZSB0aGF0 IHRoZSBTRkMgY2hhaW4gY29udHJvbGxlciB3b3VsZCBuZWVkIHRvIGJlIHN1YnNjcmliZXItYXdh cmUgdGhvdWdoLg0KPg0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayB0aGF0IHRoZXJlIGFy ZSBjYXNlcyB3aGVuIHRoZSBmdW5jdGlvbiBjYW4ndCBiZSBhZG9wdGVkLCBzdWNoIGxpa2UgU0Zz IGFyZSBjdXJyZW50IGVxdWlwbWVudCB0aGF0IGRvbid0IGhhdmUgZnVuY3Rpb24gdG8gcmVjb2du aXplIG1ldGFkYXRhLg0KPiBDRj4+IEFncmVlZC4gVGhpcyBzcGVha3MgdG8gbXkgY29tbWVudCBh Ym92ZSArIHRvIHRoZSBhZHZhbnRhZ2VzIHNvbWUgb2YgdXMgaGF2ZSBtZW50aW9uZWQgdml6IGEg Y29uc29saWRhdGVkIHBvbGljeS1iYXNlZCBzdGVlcmluZy9QRFAvU0ZDIGNoYWluIGNvbnRyb2xs ZXIgZW50aXR5Lg0KPg0KPiBIb3cgZG8gd2UgaGFuZGxlIHRoZXNlIGNhc2VzPw0KPiBBbnkgbmV3 IHByb2JsZW1zIG9yIHJlcXVpcmVtZW50cyBtYXkgb2NjdXI/DQo+DQo+IHJlZ2FyZHMsDQo+DQo+ IFNodW5zdWtlDQo+DQo+ICgyMDE0LzAyLzI1IDg6NDYpLCBDaHJpcyBGcmVkZXJpY2sgd3JvdGU6 DQo+PiBZZXMsIGFncmVlZCBvbiB0aGF0Lg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdv cmtzLmNvbV0NCj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNjo0NSBQTQ0KPj4g VG86IENocmlzIEZyZWRlcmljazsg5pys6ZaT5L+K5LuLDQo+PiBDYzogbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEkt RCBBY3Rpb246DQo+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+ DQo+PiBUaGFua3MsIENocmlzLg0KPj4NCj4+IEkgZG8gdGhpbmsgdGhlcmUgYXJlIGxvdHMgb2Yg ZWZmaWNpZW5jaWVzIHdoZW4gdGhlIGZsb3cgbGVhcm5lciAoY2xhc3NpZmllcikgYW5kIHBvbGlj eSBldmFsdWF0b3IgKFBEUCkgYXJlIGNvLWxvY2F0ZWQuICAgSG93ZXZlciwgYXJjaGl0ZWN0dXJh bGx5LCBJIHdvdWxkbid0IG1hbmRhdGUgdGhhdCB0aGV5IGJlIGNvLWxvY2F0ZWQuDQo+Pg0KPj4g ICAgICAgUm9uDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNrQHNhbmR2aW5lLmNvbV0NCj4+IFNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNToyNiBQTQ0KPj4gVG86IFJvbiBQYXJrZXI7 IOacrOmWk+S/iuS7iw0KPj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4gZHJhZnQt Ym91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pg0KPj4gQWdyZWVkLg0KPj4gVG8g cmVzdGF0ZSB0aGlzIHNsaWdodGx5LCBpZiB0aGUgU0ZDIHN0ZWVyaW5nL2RlY2lzaW9uIGxvY3Vz IGlzIGNhcGFibGUgb2YgZXZhbHVhdGluZyBtdWx0aXBsZSBvcnRob2dvbmFsIHBvbGljeSBjb25k aXRpb25zIHRoZW4gdGhpcyBpc3N1ZSBpcyBvYnZpYXRlZDsgc3Vic2NyaWJlcnMgYmVjb21lIGFu IGFnZ3JlZ2F0ZSBvZiAnd2hhdCB0aGV5IGFyZScgKyBhcmUgbm90IHNpbXBseSAnd2hvIHRoZXkg YXJlJy4NCj4+IEFzIFJvbiBzdGF0ZXMsIHRoaXMgYXdhcmVuZXNzIG1heSBiZSBkZXJpdmVkIGZy b20gTERBUCBsb29rdXAsIFJBRElVUywgR3gsIHByZS1wcm92aXNpb25lZCBydWxlcywgZXRjLg0K Pj4gVG8gaWxsdXN0cmF0ZSB3LyBhbiBleGFtcGxlLCB3ZSBtaWdodCBzYXkgc29tZXRoaW5nIGxp a2UgdGhpczoNCj4+IElmIHN1YnNjcmliZXIgWCBpcyB1c2luZyB5b3V0dWJlLCBhbmQgaXMgb24g YSBjb25nZXN0ZWQgY2VsbCwgYW5kIGlzIG9uIGFuIGlQaG9uZSwgYW5kIGlzIGluIHRoZSAiR29s ZCBUaWVyIiwgYW5kLCBhbmQsIGFuZCwgYW5kLCBldGMsIHRoZW4gdGhlIGNoYWluIGNvbnNpc3Rz IG9mIHNlcnZpY2UgZnVuY3Rpb25zIGEsIGIsIGFuZCBjLg0KPj4gVGhlcmUncyBubyBuZWVkIHRv IGVudGVyIGEgc3RhdGljIFNGQyBydWxlL2NoYWluIGZvciBzdWJzY3JpYmVyIFggKG9yIGFueSBz dWJzY3JpYmVyKS4gSW4gZmFjdCwgaXQncyBub3QgZGVzaXJhYmxlIGFueXdheSBiZWNhdXNlIGFs bCBvZiB0aGUgYWJvdmUgY29uZGl0aW9ucyBtYXkgZXZhbHVhdGUgdG8gVHJ1ZSwgc2F2ZSBvbmUg KCJpcyBvbiBhIGNvbmdlc3RlZCBjZWxsIiksIGFuZCB0aGUgcmVzdWx0YW50IGNoYWluIG1pZ2h0 IGJlIGFsdGVyZWQgKHBlcmhhcHMgdG8gYnlwYXNzIGEgdmlkZW8gb3B0aW1pemF0aW9uIHNlcnZp Y2UgZnVuY3Rpb24pLg0KPj4gVGhpcyBhbHNvIGdvZXMgdG8gdGhlIGVhcmxpZXIgY29tbWVudHMg Um9uICsgSSBtYWRlIGFib3V0IA0KPj4gY29uc29saWRhdGluZyB0aGUgZmxvdyByZWNvZ25pdGlv biArIGRlY2lzaW9uLW1ha2luZyBlbnRpdHkgaW4gYSANCj4+IHNpbmdsZSAoc3VpdGFibHkgcG9s aWN5LWF3YXJlKSBub2RlIHRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSArIHRvIA0KPj4gc2NhbGUg cHJvcGVybHkuIFRoeCwgL2MNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24g UGFya2VyDQo+PiBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDIzLCAyMDE0IDEwOjM5IFBNDQo+PiBU bzog5pys6ZaT5L+K5LuLDQo+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2Zj QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+PiBkcmFm dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+DQo+PiBTaHVuc3VrZS1zYW4s DQo+Pg0KPj4gV2hpbGUgYSB0aGVvcmV0aWNhbCBjYXNlIGNhbiBiZSBtYWRlIGZvciBvbmUgb3Ig bW9yZSBTRkNzIHBlciBzdWJzY3JpYmVyLCBmb3IgcmVhc29ucyB5b3Ugc3RhdGUsIGl0IGlzbid0 IHByYWN0aWNhbC4gIEJ1dCwgdGhlcmUgaXMgYW5vdGhlciB3YXkgdG8gdmlldyB0aGlzIGFzcGVj dCBvZiB0aGUgcHJvYmxlbS4gIExldCdzIHRha2UgeW91ciBwZXItc3Vic2NyaWJlciBjdXN0b21p emVkIGZpcmV3YWxsIGFzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuICBJZiB0aGVyZSB3ZXJlIG9u bHkgb25lIGZpcmV3YWxsLCBpbnN0ZWFkLCBhbmQgaXQgd2FzIGNhcGFibGUgb2YgbG9jYWwgcG9s aWN5IGV2YWx1YXRpb24gYmFzZWQgb24gc3Vic2NyaWJlciwgdGhlIG51bWJlciBvZiBTRkNzIHdv dWxkIGJlIHZhc3RseSByZWR1Y2VkLiAgIE9uZSB3YXkgZm9yIHRoYXQgdG8gaGFwcGVuIHdvdWxk IGJlIHRvIHNpbXBseSB1c2UgdGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGZyb20g dGhlIHBhY2tldCBhbmQgc29tZSBvdXQgb2YgYmFuZCBsb29rdXAgbWVjaGFuaXNtIGxpa2UgTERB UCBvciBSQURJVVMgYXQgdGhlIGZpcmV3YWxsLiAgICBBbm90aGVyIGFwcHJvYWNoIHRvIGRldGVy bWluZSB3aG8gdGhlIHN1YnNjcmliZXIgaXMgd291bGQgYmUgZm9yIHRoZSBTRkMgY2xhc3NpZmll ciB0byBhZGQgYSBkaXN0aW5jdCBzdWJzY3JpYmVyIGlkIGFzIG1ldGFkYXRhIHRvIHRoZSBzZXJ2 aWNlIGhlYWRlciAoZWcsIGFuIElNU0kpIGFuZCBzdGlsbCB1c2UgTERBUCwgZXRjLiBhdCB0aGUg ZmlyZXdhbGwuDQo+Pg0KPj4gSWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0 aGF0IHRoZSBmaXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwIG9mIHN1YnNjcmliZXJzLCB3aGVy ZSB0aGVyZSBhcmUgcGVyaGFwcyAxMHMgb2YgZ3JvdXBzLCB0aGVuIHlldCBhbm90aGVyIGFwcHJv YWNoIGlzIHRvIG1vZGVsIHRoZSBmaXJld2FsbCBhcyBhIGRpc3RpbmN0IGxvZ2ljYWwgZmlyZXdh bGwgcGVyIGZpcmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUg c2FtZSBtYWNoaW5lIG9yIFZNKSBhbmQgdG8gY29vcmRpbmF0ZSB0aGUgY2xhc3NpZmllcidzIHBv bGljeSBhY2NvcmRpbmdseS4NCj4+DQo+PiAgICAgIFJvbg0KPj4NCj4+DQo+Pj4gT24gRmViIDIz LCAyMDE0LCBhdCAxMDowNCBQTSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5u dHQuY28uanA+IHdyb3RlOg0KPj4+DQo+Pj4gSGkgTWVkLA0KPj4+DQo+Pj4gSW4gdGVybXMgb2Yg eW91ciBjb21tZW50LCBJIGFzc3VtZWQgc29tZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkg c28gdGhhdCB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkg Y29uc2lkZXJhdGlvbnMuDQo+Pj4gI0kgd29yayB3aXRoIEsuTmFpdG8sIGNvLWF1dGhvciBvZiBy ZXF1aXJlbWVudCBkcmFmdCBhbmQgdGhpbmsgc2NhbGFiaWxpdHkgaXMgb25lIG9mIGltcG9ydGFu dCB0aGluZ3MgdG8gY29uc2lkZXIuDQo+Pj4NCj4+PiBBc3N1bWluZyB0aGUgdXNlIGNhc2VzIGxp c3RlZCBmb2xsb3dpbmcsIHRoZSBtYW5hZ2VtZW50IG1lY2hhbmlzbSBvZiBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWlucyBtaWdodCByZXF1aXJlIGhpZ2ggc2NhbGFiaWxpdHkuDQo+Pj4NCj4+PiAxLiBU aGUgY2FzZSB0aGF0IHRoZSB0eXBlcyBvZiBTRiBpbmNyZWFzZToNCj4+PiBJIGFzc3VtZWQgdGhh dCB0aGUgdW5pdCBvZiBhcHBseWluZyBTRkMgdG8gdHJhZmZpYyBpcyBmb2xsb3dpbmc7DQo+Pj4g ICAgLSBncm91cGluZzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBl YWNoIHNlcnZpY2UsDQo+Pj4gICAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9yIHJlZ2lvbiwNCj4+ PiAgICAtIHBlci1zdWJzY3JpYmVyOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBT RkMgZm9yIGVhY2jjgIANCj4+PiAgICAgIHN1YnNjcmliZXIgKGUuZy4gcGVyIElQIGFkZHJlc3Ms IFZMQU4gSUQgZXQuYWwpLA0KPj4+ICAgIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMgYXBwbGllZCB3 aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPj4+IOOAgOOAgGFuZCBvYmpl Y3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0KPj4+DQo+Pj4gU29tZSBv ZiB0aGUgc2VydmljZSBwcm92aWRlcnMgaGF2ZSBlbm9ybW91cyBudW1iZXIgb2Ygc3Vic2NyaWJl cnMsIGFuZCB0aGUgbnVtYmVyIG9mIHN1YnNjcmliZXJzIGlzIHVwIHRvIHNldmVyYWwgdGVucyBv ciBodW5kcmVkcyBvZiBtaWxsaW9uLiBUaGVyZWZvcmUsIGluIGNhc2VzIG9mIHBlci1zdWJzY3Jp YmVyIGFuZCBwZXItZmxvdywgdGhlIG51bWJlciBvZiBTRkNzIG1pZ2h0IGluY3JlYXNlIGV4cGxv c2l2ZWx5LiBQZXItc3Vic2NyaWJlciBTRkNzIHdvdWxkIGJlIG5lZWRlZCBpbiB0aGUgY2FzZSB0 aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBkZWRpY2F0ZWQgdG8gZWFjaCB1c2VyKGUuZy4gdkNQRSBh cyB1c2VyIGN1c3RvbWl6ZWQpLg0KPj4+DQo+Pj4gQWxzbywgaW4gY2FzZSBvZiBncm91cGluZywg aWYgdGhlcmUgYXJlIG11bHRpcGxlIGdyb3VwcyB3aG9zZSBwb2xpY2llcyBhcmUgZGlmZmVyZW50 LCBzdWNoIGFzIHBlciBlbnRlcnByaXNlIGN1c3RvbWVyIGFuZCBwZXIgcmVnaW9uLCB0aGUgbnVt YmVyIG9mIFNGQ3Mgd291bGQgaW5jcmVhc2UgKGUuZy4gRmlyZXdhbGxzIGhhdmUgZGlmZmVyZW50 IHBvbGljeSBmb3IgZWFjaCBlbnRlcnByaXNlIGN1c3RvbWVyKS4NCj4+Pg0KPj4+IDIuIFRoZSBj YXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIHRoYXQgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBl YWNoIGluc3RhbmNlOg0KPj4+IEluIGNhc2UgdGhhdCB0aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNh bWUgZnVuY3Rpb24gaW4gdGhlIG5ldHdvcmsgYW5kIHRoZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVk IGZvciBlYWNoIGluc3RhbmNlLCB0aGUgY29tYmluYXRpb24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNl Lg0KPj4+IFRoZSBTRnMgdGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0 byBiZSBkaWZmZXJlbnRpYXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRz LUNhY2hlLCBhbmQgVmlkZW8tT3B0aW1pemVyKS4NCj4+Pg0KPj4+IElNSE8scmVxdWlyZW1lbnRz IGZvciBzY2FsYWJpbGl0eSB3aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIg Zm9ybWF0Lg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gU2h1bnN1a2UNCj4+Pg0KPj4+ICgy MDE0LzAyLzEyIDE4OjQ5KSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+ Pj4gRGVhciBhbGwsDQo+Pj4+DQo+Pj4+IFRoaXMgbmV3IHZlcnNpb24gaW50ZWdyYXRlcyBpbnB1 dHMgZnJvbSBOVFQgcmVwcmVzZW50YXRpdmVzLg0KPj4+Pg0KPj4+PiBUaGUgZGlmZiBjYW4gYmUg dHJhY2tlZCBoZXJlOg0KPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFm dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wDQo+Pj4+IDENCj4+Pj4gJg0KPj4+PiBkaWZm dHlwZT0tLWh0bWwmc3VibWl0PUdvISZ1cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1l bnRzLTAzDQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4gTWVkDQo+Pj4+DQo+Pj4+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+PiBEZSA6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1h bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IA0KPj4+PiBkZSBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1lcmNyZWRpIDEyIGbDqXZyaWVyIDIwMTQgMTA6NDYg DQo+Pj4+IMOADQo+Pj4+IDogaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlv bjoNCj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+DQo+ Pj4+DQo+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4gICAgICAg ICAgIFRpdGxlICAgICAgICAgICA6IFJlcXVpcmVtZW50cyBmb3IgU2VydmljZSBGdW5jdGlvbiBD aGFpbmluZw0KPj4+PiAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRh aXINCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQN Cj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1YW5sb25nIEppYW5nDQo+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDYXJsb3MgUGlnbmF0YXJvDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBLZW5nbyBOYWl0bw0KPj4+PiAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWJv dWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+PiAgICAgIFBhZ2VzICAgICAgICAg ICA6IDE0DQo+Pj4+ICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMi0xMg0KPj4+Pg0KPj4+ PiBBYnN0cmFjdDoNCj4+Pj4gICAgICBUaGlzIGRvY3VtZW50IGlkZW50aWZpZXMgdGhlIHJlcXVp cmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+Pj4gICAgICBDaGFpbmluZyAoU0ZD KS4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLw0KPj4+Pg0KPj4+PiBUaGVyZSdz IGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+Pj4N Cj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXItc2Zj LXJlcXVpcmVtZW50cy0wDQo+Pj4+IDMNCj4+Pj4NCj4+Pj4NCj4+Pj4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+Pj4+ IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4NCj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ Pj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmll czogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciANCj4+Pj4gZnRwOi8vZnRwLmll dGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPj4+IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0K Pj4+DQo+Pj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+Pj4g44ON44OD44OI44Ov 44O844Kv44K144O844OT44K544K344K544OG44Og56CU56m25omADQo+Pj4g6Lui6YCB44K144O8 44OT44K55Z+655uk44OX44Ot44K444Kn44Kv44OIDQo+Pj4g6Lui6YCB44K144O844OT44K55Yi2 5b6hRFANCj4+Pg0KPj4+IOOAkjE4MC04NTg144CA5p2x5Lqs6YO95q2m6JS16YeO5biC57eR55S6 My05LTExDQo+Pj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4+PiBFLU1BSUw6IGhvbW1hLnNodW5zdWtl QGxhYi5udHQuY28uanANCj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+ PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+DQo+DQo+DQo+IC0tDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2h1bnN1a2UgSG9tbWENCj4gPGhvbW1hLnNo dW5zdWtlQGxhYi5udHQuY28uanA+DQo+IFRFTDogKzgxIDA0MjIgNTkgMzQ4Ng0KPiBGQVg6ICs4 MSAwNDIyIDYwIDc0NjANCj4NCj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4g TXVzYXNoaW5vIGNpdHksIFRva3lvLCBKYXBhbg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQoNCg0KLS0NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClNodW5zdWtlIEhvbW1hDQo8aG9tbWEuc2h1bnN1a2VAbGFi Lm50dC5jby5qcD4NClRFTDogKzgxIDA0MjIgNTkgMzQ4Ng0KRkFYOiArODEgMDQyMiA2MCA3NDYw DQoNCk5UVCBOZXR3b3JrIFNlcnZpY2UgU3lzdGVtIExhYnMuDQpNdXNhc2hpbm8gY2l0eSwgVG9r eW8sIEphcGFuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Tue Feb 25 06:50:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782BB1A06DC for ; Tue, 25 Feb 2014 06:50:00 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl62YEIMZ5lt for ; Tue, 25 Feb 2014 06:49:56 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD081A0476 for ; Tue, 25 Feb 2014 06:49:56 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0174.001; Tue, 25 Feb 2014 06:49:55 -0800 From: Ron Parker To: Chris Frederick , Shunsuke Homma Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAlJICAADdIgIAAd4eAgAAmpID//3oy0A== Date: Tue, 25 Feb 2014 14:49:53 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> In-Reply-To: <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3S40xcmjmFt8iLj0g0BSw-tXfd0 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 14:50:00 -0000 RXhwYW5kaW5nIG9uIENocmlzJyBjb21tZW50cywgSSBkb24ndCB0aGluayB0aGUgcHJhY3RpY2Fs IGxpbWl0YXRpb25zIGFyZSB3cnQgdGhlIG51bWJlciBvZiBmdWxseS1xdWFsaWZpZWQgNS10dXBs ZXMsIGJ1dCByYXRoZXIgdGhlIG51bWJlciBvZiBkaXN0aW5jdCB0cmVhdG1lbnQgc2VxdWVuY2Vz IHRoYXQgYXJpc2UgZnJvbSB0aG9zZSBmbG93cy4gICBPZiB0aGUgMTAwJ3Mgb2YgbWlsbGlvbnMg b2YgZmxvd3MgdGhhdCBtaWdodCBiZSB0cmFja2VkIGJ5IGEgaGlnaCBlbmQgY2xhc3NpZmllciwg cGVyaGFwcyB0aGUgbnVtYmVyIG9mIHVuaXF1ZSBzZXF1ZW5jZXMgdGhhdCBhcmlzZSBhcmUgaW4g dGhlIDEwMDAncy4gICAgSWYgYXBwbHlpbmcgYSBmaXhlZC1saW5lIG9yIG1vYmlsZSBzZXJ2aWNl IHByb3ZpZGVyIHBlcnNwZWN0aXZlLCB0aGUgbnVtYmVyIG9mIGNoYWlucyB3b3VsZCBiZSBwcm9w b3J0aW9uYWwgdG8gdGhlIG51bWJlciBvZiBkaXN0aW5jdCBlbmQtdG8tZW5kIHNlcnZpY2UgcGxh bnMgb2ZmZXJlZCBhbmQgdGhlbiBtdWx0aXBsaWVkIGJ5IHRoZSBmbG93LWF3YXJlIHN1YnNldHRp bmcgdGhhdCBjYW4gYmUgbWFuYWdlZCBieSB0aGUgY2xhc3NpZmllciAoaS5lLiwgc3Vic2NyaWJl ciBpcyBzdWJqZWN0IHRvIHNlcnZpY2UgZnVuY3Rpb24gQSB0aGVuIEIgdGhlbiBDIGJ1dCBCIG9u bHkgbmVlZHMgVENQLzgwIHRyYWZmaWMsIEEgb25seSBuZWVkcyBVRFAgdHJhZmZpYywgLi4uKS4N Cg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzIEZy ZWRlcmljayBbbWFpbHRvOmNmcmVkZXJpY2tAc2FuZHZpbmUuY29tXSANClNlbnQ6IFR1ZXNkYXks IEZlYnJ1YXJ5IDI1LCAyMDE0IDk6NDQgQU0NClRvOiBTaHVuc3VrZSBIb21tYTsgUm9uIFBhcmtl cg0KQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVt ZW50cy0wMy50eHQNCg0KSGkgU2h1bnN1a2Utc2FuLA0KSSByZWNvZ25pemUgdGhhdCB1bHRpbWF0 ZWx5LCB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIGFuZCBub3Qgc29tZXRoaW5n IHRvIGJlIG1hbmRhdGVkIGFzIGEgaGFyZCAncnVsZScuIEkganVzdCB3YW50ZWQgdG8gaGlnaGxp Z2h0IHdoYXQgaXMgcG9zc2libGUgKyB3aGF0IHdlIGJlbGlldmUgdG8gYmUgYmVzdCBwcmFjdGlj ZXMgaW4gdGhpcyBhcmVhLCBiYXNlZCBvbiBvdXIgZXhwZXJpZW5jZS4NClRoYXQgc2FpZCwgeWVz LCBJIGJlbGlldmUgdGhhdCBpbiBwcmFjdGljYWwgKHJlYWwtd29ybGQpIHRlcm1zLCBpdCBtYWtl cyBzZW5zZSB0byBkZWVtcGhhc2l6ZSB0aGUgJyhyZSljbGFzc2lmaWNhdGlvbicgcm9sZSBvZiBT RnMgaW4gbW9zdCBjYXNlcywgZm9yIHJlYXNvbnMgSSd2ZSBzdGF0ZWQgcHJldmlvdXNseSAocXVl c3Rpb25zIG9mIG1ldGFkYXRhIHNoYXJpbmcgYmV0d2VlbiBTRnMsIGlzc3VlcyByZWxhdGVkIHRv IHJldGFpbmluZyBpbnRlZ3JpdHkgb2YgY2hhaW5zL2JyZWFraW5nIGZsb3dzLCBldGMuKS4NClRv IHlvdXIgY29tbWVudCBhYm91dCBzY2FsaW5nIHRoZSBTRkMgQ29udHJvbGxlciwgSSB3b3VsZCBq dXN0IHNheSB0aGF0IHRoZXJlIGFyZSBjb21tZXJjaWFsbHkgZGVwbG95ZWQgU0ZDIENvbnRyb2xs ZXJzIHRvZGF5IHRoYXQgZG8gdGhpcywgaS5lLiBzaXQgaW5saW5lIGluIGNvbnN1bWVyIG5ldHdv cmtzLCByZWNlaXZlL2luc3BlY3QgbWlsbGlvbnMgb2YgY29uY3VycmVudCBiaWRpcmVjdGlvbmFs IGZsb3dzLCArIG1ha2UgcmVhbC10aW1lIFNGQyBzdGVlcmluZyBhbmQgc2VxdWVuY2luZyBkZWNp c2lvbnMgYmFzZWQgb24gZmxvdywgc3Vic2NyaWJlciwgc2Vzc2lvbiwgYW5kIG5ldHdvcmsgY29u ZGl0aW9ucy4gDQpPYnZpb3VzbHksIGRpZmZlcmVuY2VzIGluIHZlbmRvciBjYXBhYmlsaXRpZXMs IGFzIHdlbGwgYXMgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgdml6IGNvbnNvbGlkYXRpbmcgdnMu IGRpc3RyaWJ1dGluZyBkaWZmZXJlbnQgU0ZDIGZ1bmN0aW9ucyBsaWtlIGZsb3cgY2xhc3NpZmlj YXRpb24sIFBEUC9TRkMgQ29udHJvbGxlciwgc3RlZXJpbmcvbGIsIGV0YywgYWxsIHdpbGwgaGF2 ZSBhbiBpbXBhY3QgaGVyZS4gQmVzdCwgL2MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFNodW5zdWtlIEhvbW1hIFttYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5q cF0NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE0IDc6MjUgQU0NClRvOiBDaHJpcyBG cmVkZXJpY2s7IFJvbiBQYXJrZXINCkNjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91 Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQoNCkhpIENocmlzLA0KDQpEbyB5b3UgbWVh biB0aGF0LCBmb3IgcmV0YWluaW5nIGludGVncml0eSBvZiBjaGFpbnMsIG1hbmFnZW1lbnQgb2Yg c3Vic2NyaWJlcnMgc2hvdWxkIGJlIHByb3ZpZGVkIG5vdCBieSBTRnMsIGJ1dCBieSBTRkMgY29u dHJvbGxlcj8NCg0KSWYgc28sIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG51bWJlciBvZiBjaGFp bnMgdGhhdCBTRkMgY29udHJvbGxlciBtdXN0IG1hbmFnZSBpcyBsYXJnZSwgYW5kIGl0IGlzIHRo ZSBzYW1lIHByb2JsZW0gSSBzYWlkLCBJIHRoaW5rLg0KDQpSZWdhcmRzLA0KDQpTaHVuc3VrZQ0K DQooMjAxNC8wMi8yNSAxNDoxNyksIENocmlzIEZyZWRlcmljayB3cm90ZToNCj4gSGkgU2h1bnN1 a2Utc2FuLA0KPiBJIGFja25vd2xlZGdlIHRoZSBjb21tZW50cyBhYm91dCB0aGVzZSBiZWluZyBp bXBsZW1lbnRhdGlvbiBtYXR0ZXJzLCANCj4gYnV0IEkndmUgb2ZmZXJlZCBzb21lIHRob3VnaHRz IGlubGluZSB3aXRoIHlvdXIgbWFpbCBiZWxvdy4gVGh4LCAvYw0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaHVuc3VrZSBIb21tYSBbbWFpbHRvOmhvbW1hLnNodW5z dWtlQGxhYi5udHQuY28uanBdDQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgOTow MCBQTQ0KPiBUbzogQ2hyaXMgRnJlZGVyaWNrOyBSb24gUGFya2VyDQo+IENjOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFRS OiBJLUQgQWN0aW9uOiANCj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0 DQo+DQo+IEhpIFJvbiwgQ2hyaXMsDQo+DQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4NCj4N Cj4gSSB0aGluayB0aGF0IHlvdXIgcG9pbnRzIGFyZSBmb2xsb3dpbmc6DQo+IGluIGNhc2UgdGhh dCB0aGVyZSBhcmUgc29tZSBTRnMgYXMgdXNlciBjdXN0b21pemVkLCBwZXItc3Vic2NyaWJlciBT RkNzIHNob3VsZG4ndCBiZSBtYWRlLCBidXQgdGhlIFNGcyBzaG91bGQgcmVjb2duaXplIHN1YnNj cmliZXJzIGJ5IElQIGFkZHJlc3Mgb3IgbWV0YWRhdGEuDQo+IENGPj4gTXkgcG9pbnQgd2FzIHRo YXQgSSBkb24ndCBzZWUgaXQgYXMgZGVzaXJhYmxlIHRvIGhhdmUgc3BlY2lmaWMgcGVyLXN1YnNj cmliZXIgU0ZDIHJ1bGVzIChhcyBpbiBzdGF0aWMgcnVsZXMsIGxpa2Ugc3Vic2NyaWJlcl9DaHJp cz1TRkNfYV9iX2MpLCB3aXRoIGEgcnVsZSBmb3IgZXZlcnkgc3ViLCBpbiB0aGF0IHNlbnNlLiBC ZXR0ZXIgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgU0ZDIGNoYWluIGNvbnRyb2xsZXIgaXMgc3Vi c2NyaWJlci1hd2FyZSArIGFibGUgdG8gZXZhbHVhdGUgbXVsdGlwbGUgb3J0aG9nb25hbCBmbG93 ICsgc3Vic2NyaWJlciBjb25kaXRpb25zIGluIHJlYWwgdGltZSwgYW5kIGZvcm11bGF0ZSBhIGNo YWluIG9uIHRoZSBiYXNpcyBvZiB0aG9zZSBkeW5hbWljIGNvbmRpdGlvbnMuDQo+DQo+IE9mIGNv dXJzZSwgaXQgaXMgb25lIG9mIHRoZSBzb2x1dGlvbnMuDQo+IEhvd2V2ZXIsIGluIHRoaXMgY2Fz ZSwgSSB0aGluayB0aGF0IFNGcyBhcyB1c2VyIGN1c3RvbWl6ZWQgbWlnaHQgYmUgcmVxdWlyZWQg dG8gaGF2ZSBhIGZ1bmN0aW9uIHRvIHJlY29nbml6ZSBlYWNoIHN1YnNjcmliZXIuDQo+IENGPj4g SSB3YXNuJ3QgYWN0dWFsbHkgdGhpbmtpbmcgaW4gdGVybXMgb2YgU0YgKHJlKWNsYXNzaWZpY2F0 aW9uOyBJJ3ZlIHByZXZpb3VzbHkgY29tbWVudGVkIG9uIHdoeSBJIHRoaW5rIHRoYXQgaWRlYSBp cyBzb21ld2hhdCBmcmF1Z2h0IChpLmUuIGJlY2F1c2UgbW9kaWZpY2F0aW9uIG9mIHRoZSBmbG93 IHBhdGggYnkgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGhpbiB0aGUgY2hhaW4gY291bGQgcmVzdWx0 IGluIGEgJ2JyZWFraW5nJyBvZiB0aGUgY2hhaW4gb3IgZmxvdy4gSWYgdGhlcmUgaXMgbm90IGJp ZGlyZWN0aW9uYWwgc3ltbWV0cnkgaW4gdGhlIGZsb3cgYW5kIHNlcnZpY2UgZnVuY3Rpb24gZWxl bWVudHMgaW4gdGhlIGNoYWluIGNhbiBtYWtlIHJvdXRpbmcgZGVjaXNpb25zLCB0aGVuIHRoZXJl J3Mgc29tZSBtZXRhZGF0YSBjb3JyZWxhdGlvbiB0byB3b3JrIG91dCwgYXQgbWluaW11bSkuIEkg ZG8gYWdyZWUgdGhhdCB0aGUgU0ZDIGNoYWluIGNvbnRyb2xsZXIgd291bGQgbmVlZCB0byBiZSBz dWJzY3JpYmVyLWF3YXJlIHRob3VnaC4NCj4NCj4gT24gdGhlIG90aGVyIGhhbmQsIEkgdGhpbmsg dGhhdCB0aGVyZSBhcmUgY2FzZXMgd2hlbiB0aGUgZnVuY3Rpb24gY2FuJ3QgYmUgYWRvcHRlZCwg c3VjaCBsaWtlIFNGcyBhcmUgY3VycmVudCBlcXVpcG1lbnQgdGhhdCBkb24ndCBoYXZlIGZ1bmN0 aW9uIHRvIHJlY29nbml6ZSBtZXRhZGF0YS4NCj4gQ0Y+PiBBZ3JlZWQuIFRoaXMgc3BlYWtzIHRv IG15IGNvbW1lbnQgYWJvdmUgKyB0byB0aGUgYWR2YW50YWdlcyBzb21lIG9mIHVzIGhhdmUgbWVu dGlvbmVkIHZpeiBhIGNvbnNvbGlkYXRlZCBwb2xpY3ktYmFzZWQgc3RlZXJpbmcvUERQL1NGQyBj aGFpbiBjb250cm9sbGVyIGVudGl0eS4NCj4NCj4gSG93IGRvIHdlIGhhbmRsZSB0aGVzZSBjYXNl cz8NCj4gQW55IG5ldyBwcm9ibGVtcyBvciByZXF1aXJlbWVudHMgbWF5IG9jY3VyPw0KPg0KPiBy ZWdhcmRzLA0KPg0KPiBTaHVuc3VrZQ0KPg0KPiAoMjAxNC8wMi8yNSA4OjQ2KSwgQ2hyaXMgRnJl ZGVyaWNrIHdyb3RlOg0KPj4gWWVzLCBhZ3JlZWQgb24gdGhhdC4NCj4+DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0 IDY6NDUgUE0NCj4+IFRvOiBDaHJpcyBGcmVkZXJpY2s7IOacrOmWk+S/iuS7iw0KPj4gQ2M6IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6 IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVu dHMtMDMudHh0DQo+Pg0KPj4gVGhhbmtzLCBDaHJpcy4NCj4+DQo+PiBJIGRvIHRoaW5rIHRoZXJl IGFyZSBsb3RzIG9mIGVmZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNsYXNzaWZp ZXIpIGFuZCBwb2xpY3kgZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhvd2V2ZXIs IGFyY2hpdGVjdHVyYWxseSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBjby1sb2Nh dGVkLg0KPj4NCj4+ICAgICAgIFJvbg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0BzYW5kdmlu ZS5jb21dDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDU6MjYgUE0NCj4+IFRv OiBSb24gUGFya2VyOyDmnKzplpPkv4rku4sNCj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFjdGlv bjoNCj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4NCj4+IEFn cmVlZC4NCj4+IFRvIHJlc3RhdGUgdGhpcyBzbGlnaHRseSwgaWYgdGhlIFNGQyBzdGVlcmluZy9k ZWNpc2lvbiBsb2N1cyBpcyBjYXBhYmxlIG9mIGV2YWx1YXRpbmcgbXVsdGlwbGUgb3J0aG9nb25h bCBwb2xpY3kgY29uZGl0aW9ucyB0aGVuIHRoaXMgaXNzdWUgaXMgb2J2aWF0ZWQ7IHN1YnNjcmli ZXJzIGJlY29tZSBhbiBhZ2dyZWdhdGUgb2YgJ3doYXQgdGhleSBhcmUnICsgYXJlIG5vdCBzaW1w bHkgJ3dobyB0aGV5IGFyZScuDQo+PiBBcyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkg YmUgZGVyaXZlZCBmcm9tIExEQVAgbG9va3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQg cnVsZXMsIGV0Yy4NCj4+IFRvIGlsbHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5 IHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+PiBJZiBzdWJzY3JpYmVyIFggaXMgdXNpbmcgeW91dHVi ZSwgYW5kIGlzIG9uIGEgY29uZ2VzdGVkIGNlbGwsIGFuZCBpcyBvbiBhbiBpUGhvbmUsIGFuZCBp cyBpbiB0aGUgIkdvbGQgVGllciIsIGFuZCwgYW5kLCBhbmQsIGFuZCwgZXRjLCB0aGVuIHRoZSBj aGFpbiBjb25zaXN0cyBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyBhLCBiLCBhbmQgYy4NCj4+IFRoZXJl J3Mgbm8gbmVlZCB0byBlbnRlciBhIHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJl ciBYIChvciBhbnkgc3Vic2NyaWJlcikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3 YXkgYmVjYXVzZSBhbGwgb2YgdGhlIGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRy dWUsIHNhdmUgb25lICgiaXMgb24gYSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFu dCBjaGFpbiBtaWdodCBiZSBhbHRlcmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGlt aXphdGlvbiBzZXJ2aWNlIGZ1bmN0aW9uKS4NCj4+IFRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJs aWVyIGNvbW1lbnRzIFJvbiArIEkgbWFkZSBhYm91dCANCj4+IGNvbnNvbGlkYXRpbmcgdGhlIGZs b3cgcmVjb2duaXRpb24gKyBkZWNpc2lvbi1tYWtpbmcgZW50aXR5IGluIGEgDQo+PiBzaW5nbGUg KHN1aXRhYmx5IHBvbGljeS1hd2FyZSkgbm9kZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgKyB0 byANCj4+IHNjYWxlIHByb3Blcmx5LiBUaHgsIC9jDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4gU2VudDogU3VuZGF5LCBGZWJydWFyeSAyMywgMjAxNCAx MDozOSBQTQ0KPj4gVG86IOacrOmWk+S/iuS7iw0KPj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0 aW9uOg0KPj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pg0KPj4g U2h1bnN1a2Utc2FuLA0KPj4NCj4+IFdoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFk ZSBmb3Igb25lIG9yIG1vcmUgU0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0 YXRlLCBpdCBpc24ndCBwcmFjdGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZp ZXcgdGhpcyBhc3BlY3Qgb2YgdGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNj cmliZXIgY3VzdG9taXplZCBmaXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYg dGhlcmUgd2VyZSBvbmx5IG9uZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxl IG9mIGxvY2FsIHBvbGljeSBldmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1i ZXIgb2YgU0ZDcyB3b3VsZCBiZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRv IGhhcHBlbiB3b3VsZCBiZSB0byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAg YWRkcmVzcyBmcm9tIHRoZSBwYWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hh bmlzbSBsaWtlIExEQVAgb3IgUkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHBy b2FjaCB0byBkZXRlcm1pbmUgd2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUg U0ZDIGNsYXNzaWZpZXIgdG8gYWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0 YSB0byB0aGUgc2VydmljZSBoZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAs IGV0Yy4gYXQgdGhlIGZpcmV3YWxsLg0KPj4NCj4+IElmIHRoZSBwcm9ibGVtIGlzIGNoYW5nZWQg c2xpZ2h0bHkgc28gdGhhdCB0aGUgZmlyZXdhbGwgcG9saWN5IGlzIHBlciBncm91cCBvZiBzdWJz Y3JpYmVycywgd2hlcmUgdGhlcmUgYXJlIHBlcmhhcHMgMTBzIG9mIGdyb3VwcywgdGhlbiB5ZXQg YW5vdGhlciBhcHByb2FjaCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwgYXMgYSBkaXN0aW5jdCBs b2dpY2FsIGZpcmV3YWxsIHBlciBmaXJld2FsbCBwb2xpY3kgc2V0ICh0aGV5IGNvdWxkIGFsbCBy ZXNpZGUgaW4gdGhlIHNhbWUgbWFjaGluZSBvciBWTSkgYW5kIHRvIGNvb3JkaW5hdGUgdGhlIGNs YXNzaWZpZXIncyBwb2xpY3kgYWNjb3JkaW5nbHkuDQo+Pg0KPj4gICAgICBSb24NCj4+DQo+Pg0K Pj4+IE9uIEZlYiAyMywgMjAxNCwgYXQgMTA6MDQgUE0sICLmnKzplpPkv4rku4siIDxob21tYS5z aHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+Pg0KPj4+IEhpIE1lZCwNCj4+Pg0KPj4+ IEluIHRlcm1zIG9mIHlvdXIgY29tbWVudCwgSSBhc3N1bWVkIHNvbWUgdXNlIGNhc2VzIGFib3V0 IHNjYWxhYmlsaXR5IHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFib3V0 IHNjYWxhYmlsaXR5IGNvbnNpZGVyYXRpb25zLg0KPj4+ICNJIHdvcmsgd2l0aCBLLk5haXRvLCBj by1hdXRob3Igb2YgcmVxdWlyZW1lbnQgZHJhZnQgYW5kIHRoaW5rIHNjYWxhYmlsaXR5IGlzIG9u ZSBvZiBpbXBvcnRhbnQgdGhpbmdzIHRvIGNvbnNpZGVyLg0KPj4+DQo+Pj4gQXNzdW1pbmcgdGhl IHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0aGUgbWFuYWdlbWVudCBtZWNoYW5pc20gb2Yg U2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQgcmVxdWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0K Pj4+DQo+Pj4gMS4gVGhlIGNhc2UgdGhhdCB0aGUgdHlwZXMgb2YgU0YgaW5jcmVhc2U6DQo+Pj4g SSBhc3N1bWVkIHRoYXQgdGhlIHVuaXQgb2YgYXBwbHlpbmcgU0ZDIHRvIHRyYWZmaWMgaXMgZm9s bG93aW5nOw0KPj4+ICAgIC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNp ZmljIFNGQyBmb3IgZWFjaCBzZXJ2aWNlLA0KPj4+ICAgICAgZW50ZXJwcmlzZSBjdXN0b21lciBv ciByZWdpb24sDQo+Pj4gICAgLSBwZXItc3Vic2NyaWJlcjogdHJhZmZpYyBpcyBhcHBsaWVkIHdp dGggc3BlY2lmaWMgU0ZDIGZvciBlYWNo44CADQo+Pj4gICAgICBzdWJzY3JpYmVyIChlLmcuIHBl ciBJUCBhZGRyZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4+PiAgICAtIHBlci1mbG93OiB0cmFmZmlj IGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc3Vic2NyaWJlciwNCj4+PiDj gIDjgIBhbmQgb2JqZWN0aXZlIChlLmcuIHByZSBVUkwsIGFwcGxpY2F0aW9uIGV0LmFsKS4NCj4+ Pg0KPj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVy IG9mIHN1YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBz ZXZlcmFsIHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBv ZiBwZXItc3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBp bmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQg aW4gdGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNl cihlLmcuIHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4+Pg0KPj4+IEFsc28sIGluIGNhc2Ug b2YgZ3JvdXBpbmcsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMg YXJlIGRpZmZlcmVudCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJl Z2lvbiwgdGhlIG51bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBo YXZlIGRpZmZlcmVudCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+Pj4N Cj4+PiAyLiBUaGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyB0aGF0IG11c3QgYmUgY2xh c3NpZmllZCBmb3IgZWFjaCBpbnN0YW5jZToNCj4+PiBJbiBjYXNlIHRoYXQgdGhlcmUgYXJlIFNG cyB3aXRoIHRoZSBzYW1lIGZ1bmN0aW9uIGluIHRoZSBuZXR3b3JrIGFuZCB0aGUgU0ZzIG11c3Qg YmUgY2xhc3NpZmllZCBmb3IgZWFjaCBpbnN0YW5jZSwgdGhlIGNvbWJpbmF0aW9uIG9mIFNGcyBt aWdodCBpbmNyZWFzZS4NCj4+PiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBzdGF0ZWZ1bCB0cmFmZmlj IGFyZSBuZWVkZWQgdG8gYmUgZGlmZmVyZW50aWF0ZWQgcGVyIGluc3RhbmNlIChlLmcuIEZpcmV3 YWxsLCBDb250ZW50cy1DYWNoZSwgYW5kIFZpZGVvLU9wdGltaXplcikuDQo+Pj4NCj4+PiBJTUhP LHJlcXVpcmVtZW50cyBmb3Igc2NhbGFiaWxpdHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVy ZSBhbmQgaGVhZGVyIGZvcm1hdC4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+Pg0KPj4+IFNodW5zdWtl DQo+Pj4NCj4+PiAoMjAxNC8wMi8xMiAxODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20gd3JvdGU6DQo+Pj4+IERlYXIgYWxsLA0KPj4+Pg0KPj4+PiBUaGlzIG5ldyB2ZXJzaW9uIGlu dGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2VudGF0aXZlcy4NCj4+Pj4NCj4+Pj4gVGhl IGRpZmYgY2FuIGJlIHRyYWNrZWQgaGVyZToNCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDE9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMA0KPj4+PiAxDQo+Pj4+ ICYNCj4+Pj4gZGlmZnR5cGU9LS1odG1sJnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1ib3VjYWRhaXIt c2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IE1lZA0KPj4+Pg0K Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4gRGUgOiBJLUQtQW5ub3VuY2Ug W21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCANCj4+Pj4g ZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVudm95w6kgOiBtZXJjcmVkaSAxMiBmw6l2cmll ciAyMDE0IDEwOjQ2IA0KPj4+PiDDgA0KPj4+PiA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZyBPYmpl dCA6IEktRCBBY3Rpb246DQo+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAz LnR4dA0KPj4+Pg0KPj4+Pg0KPj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4+DQo+Pj4+ DQo+Pj4+ICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW5pbmcNCj4+Pj4gICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1v aGFtZWQgQm91Y2FkYWlyDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaHJpc3Rp YW4gSmFjcXVlbmV0DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFubG9uZyBK aWFuZw0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtlcg0KPj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2FybG9zIFBpZ25hdGFybw0KPj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+Pj4gICAgICBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4gICAgICBQ YWdlcyAgICAgICAgICAgOiAxNA0KPj4+PiAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDIt MTINCj4+Pj4NCj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+ICAgICAgVGhpcyBkb2N1bWVudCBpZGVudGlm aWVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uDQo+Pj4+ICAgICAg Q2hhaW5pbmcgKFNGQykuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+Pj4N Cj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1l bnRzLTAzDQo+Pj4+DQo+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt Ym91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMA0KPj4+PiAzDQo+Pj4+DQo+Pj4+DQo+Pj4+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIA0KPj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+DQo+Pj4+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPj4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+Pj4gSW50ZXJuZXQtRHJh ZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+Pj4+ IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+Pj4+DQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBt YWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+PiDmnKzplpMg5L+K5LuLIChIb21t YSBTaHVuc3VrZSkNCj4+Pg0KPj4+IOaXpeacrOmbu+S/oembu+ipseagquW8j+S8muekvg0KPj4+ IOODjeODg+ODiOODr+ODvOOCr+OCteODvOODk+OCueOCt+OCueODhuODoOeglOeptuaJgA0KPj4+ IOi7oumAgeOCteODvOODk+OCueWfuuebpOODl+ODreOCuOOCp+OCr+ODiA0KPj4+IOi7oumAgeOC teODvOODk+OCueWItuW+oURQDQo+Pj4NCj4+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiU temHjuW4gue3keeUujMtOS0xMQ0KPj4+IFRFTDogMDQyMi01OS0zNDg2DQo+Pj4gRS1NQUlMOiBo b21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwDQo+Pj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pg0KPg0KPg0KPiAt LQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNodW5zdWtlIEhvbW1h DQo+IDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPg0KPiBURUw6ICs4MSAwNDIyIDU5IDM0 ODYNCj4gRkFYOiArODEgMDQyMiA2MCA3NDYwDQo+DQo+IE5UVCBOZXR3b3JrIFNlcnZpY2UgU3lz dGVtIExhYnMuDQo+IE11c2FzaGlubyBjaXR5LCBUb2t5bywgSmFwYW4NCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPg0KDQoNCi0tDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTaHVuc3VrZSBIb21tYQ0KPGhvbW1h LnNodW5zdWtlQGxhYi5udHQuY28uanA+DQpURUw6ICs4MSAwNDIyIDU5IDM0ODYNCkZBWDogKzgx IDA0MjIgNjAgNzQ2MA0KDQpOVFQgTmV0d29yayBTZXJ2aWNlIFN5c3RlbSBMYWJzLg0KTXVzYXNo aW5vIGNpdHksIFRva3lvLCBKYXBhbg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0K From nobody Tue Feb 25 07:42:24 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE6D1A0795 for ; Tue, 25 Feb 2014 07:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YnRHOrqXOVzS for ; Tue, 25 Feb 2014 07:42:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id C8BCE1A0793 for ; Tue, 25 Feb 2014 07:42:19 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 43B49C05B3; Tue, 25 Feb 2014 16:42:18 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 147AE3841F7; Tue, 25 Feb 2014 16:42:18 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 25 Feb 2014 16:42:18 +0100 From: To: "Pham, Chuong D" , Ron Parker , =?utf-8?B?5pys6ZaT5L+K5LuL?= Date: Tue, 25 Feb 2014 16:42:16 +0100 Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8xh0FGxlIHvY6jRfaEniTWM93LqQAK5MVgACL3WzA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F4E4D79FE@PUEXCB1B.nanterre.francetelecom.fr> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C14E78F19@WSMSG3154V.srv.dir.telstra.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.25.85115 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mQW-6EYfGUFTFfk2X9UHQ_NjdOM Cc: "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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, 25 Feb 2014 15:42:22 -0000 SGkgQ2h1b25nLA0KDQpJIGFncmVlIGNsYXNzaWZpY2F0aW9uIGNhbiBiZSBzdWJzY3JpYmVyLWF3 YXJlLiANCg0KQlRXLCB0aGlzIHJlcXVpcmVtZW50IGRyYWZ0IGFscmVhZHkgY292ZXJzIHRoaXMg cG9pbnQ6IGNsYXNzaWZpY2F0aW9uIHJ1bGVzIGFyZSBwb2xpY3ktYmFzZWQgYW5kIGRlcGxveW1l bnQtc3BlY2lmaWMuIFRoZSB3b3JkaW5nIGNhbiBiZSBlbmhhbmNlZCB0byBjYWxsIG91dCAic3Vi c2NyaWJlci1hd2FyZSIgaW4gYWRkaXRpb24gdG8gZmxvdyBjaGFyYWN0ZXJpc3RpY3M6DQoNCiAg IFJFUSMxODogIFRoZSBzb2x1dGlvbiBNVVNUIE5PVCBtYWtlIGFueSBhc3N1bXB0aW9uIG9uIGhv dyB0aGUgdHJhZmZpYw0KICAgICAgICAgICAgaXMgdG8gYmUgYm91bmQgdG8gYSBnaXZlbiBjaGFp bmluZyBwb2xpY3kuICBJbiBvdGhlciB3b3JkcywNCiAgICAgICAgICAgIGNsYXNzaWZpY2F0aW9u IHJ1bGVzIGFyZSBkZXBsb3ltZW50LXNwZWNpZmljIGFuZCBwb2xpY3ktDQogICAgICAgICAgICBi YXNlZC4gIEZvciBpbnN0YW5jZSwgY2xhc3NpZmljYXRpb24gY2FuIHJlbHkgb24gYSBzdWJzZXQg b2YNCiAgICAgICAgICAgIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIGEgcmVjZWl2ZWQgcGFj a2V0IHN1Y2ggYXMgNS10dXBsZQ0KICAgICAgICAgICAgY2xhc3NpZmljYXRpb24uDQoNCkNoZWVy cywNCk1lZA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgUGhhbSwgQ2h1b25nIEQNCj5F bnZvecOpwqA6IG1hcmRpIDI1IGbDqXZyaWVyIDIwMTQgMDA6MTINCj7DgMKgOiBSb24gUGFya2Vy OyDmnKzplpPkv4rku4sNCj5DY8KgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBzZmNAaWV0 Zi5vcmcNCj5PYmpldMKgOiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFp ci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPg0KPkhpIGFsbCwNCj4NCj5JbiBNb2JpbGUsIHBl ci1zdWJzY3JpYmVyIHZhbHVlLWFkZGVkLXNlcnZpY2UgKFZBUykgaXMgdmFsdWFibGUgYW5kIGlz IGENCj5jdWx0dXJlIG9mIHBlcnNvbmFsaXNhdGlvbiBpLmUuIGEgdXNlciBpcyBhIHNvbGUgb3du ZXIgb2YgYSBkZXZpY2UuIFRvIGRhdGUNCj53aXRoIHRoZSBsZWdhY3kgY2lyY3VpdC1zd2l0Y2hl ZCB2b2ljZS1jZW50cmljIG5ldHdvcmsgYWthIENTIHZvaWNlLCB3ZQ0KPmFscmVhZHkgaGF2ZSBw ZXItc3Vic2NyaWJlciBWQVMgaW4gdGhlIGZvcm0gb2Ygc3VwcGxlbWVudGFyeSBzZXJ2aWNlcyBp LmUuDQo+dm9pY2UgbWFpbCwgZGl2ZXJzaW9uIGV0Yy4gYW5kIGluIHRoZSBQYWNrZXQgRGF0YSB3 b3JsZCwgdGhlIFBDUkYNCj5hcmNoaXRlY3R1cmUgd2FzIGRldmVsb3BlZCB3aXRoIHRoYXQgKHBl ci1zdWJzY3JpYmVyIHNlcnZpY2UpIGluIG1pbmQuIFdoYXQNCj5pcyBsYWNraW5nIGF0IHRoZSBt b21lbnQgaXMgdGhlIHBlci1zdWJzY3JpYmVyIFNGQyBvbiB0aGUgR2kvU0dpIHVzZXIgcGxhbmUN Cj5jYXBhYmlsaXR5IHRvIG1vbmV0aXplIHdpdGggVkFTIGFzIHdoYXQgd2UgaGF2ZSBiZWVuIGRv aW5nIHdpdGggQ1MuDQo+DQo+SW4gbXkgb3BpbmlvbiwgaXQgaXMgYSB2ZXJ5IGltcG9ydGFudCBh c3BlY3Qgb2YgU0ZDLiBJIGFncmVlIHRoZXJlIHdpbGwgYmUNCj5zY2FsYWJpbGl0eSBjaGFsbGVu Z2UgYnV0IHRoZSB2YWx1ZSBvZiB0aGlzIGNhcGFiaWxpdHkganVzdGlmaWVzIHRoZQ0KPmNoYWxs ZW5nZS4gVGhlIHNjYWxhYmlsaXR5IGFzIFJvbiBoYXMgaW5kaWNhdGVkLCB3aWxsIGJlIG1vcmUg b24gdGhlDQo+ImNvbnRyb2wgcGxhbmUiIHdoaWNoIG5lZWRzIHRvIGEpIGlkZW50aWZ5IHRoZSB1 c2VyIGFuZCBiKWRldGVybWluZSB0aGUgU0ZzDQo+cmVxdWlyZWQgYW5kIGMpc2lnbmFsIHRoZSBu ZXR3b3JrIGFuZCB0aGUgU0ZzIGZvciBTRkMuIFRoZSBNb2JpbGUgbmV0d29yaw0KPndpdGggcGVy c29uYWxpc2F0aW9uIGN1bHR1cmUgaW4gbWluZCBoYXMgcGxlbnR5IG9mIHJlc291cmNlcyBmb3Ig dGhlIFNGQyB0bw0KPmxldmVyYWdlIGZvciBwZXItc3Vic2NyaWJlcnMgc2VydmljZS4NCj4NCj5U aGUgbnVtYmVyIG9mIFNGQ3MgbWF5IG5vdCBiZSBoaWdoIGFzIHRoZSBudW1iZXIgb2YgVkFTZXMg bm9ybWFsbHkgd2lsbCBiZQ0KPmxpbWl0ZWQgdG8gYSBzbWFsbCBudW1iZXIuIFdlIGRvbid0IG5l ZWQgcGVyLXN1YnNjcmliZXIgU0ZDIGJ1dCBhDQo+Y2FwYWJpbGl0eSB0byBtYXAgZWFjaCBzdWJz Y3JpYmVyIHRvIG9uZSBvZiB0aGUgU0ZDIGluIHRoZSBWQVMgY2F0YWxvZ3VlLg0KPlRha2UgUm9u J3MgZXhhbXBsZSBvZiBhIHBlci1zdWJzY3JpYmVyJ3MgZmlyZXdhbGwuIEEgc2VydmljZSBwcm92 aWRlciB3b3VsZA0KPm5vdCBsaWtlbHkgdG8gb2ZmZXIgYSBwZXItc3Vic2NyaWJlciBuZXR3b3Jr LWJhc2VkIEZXIHdoZXJlIGEgc3Vic2NyaWJlcg0KPmNhbiB1c2UgYSBwb3J0YWwgdG8gY29uZmln dXJlIHRoZSB3YXkgdGhleSBjYW4gZG8gb24gYSBSRyBvciBhIHNvZnR3YXJlIEZXDQo+b24gYSBQ Qy4gSXQgd291bGQgbGlrZWx5IG9mZmVyIGEgZ2VuZXJpYyBHaSBzdGF0ZWZ1bCBmaXJld2FsbCBz byB0aGF0DQo+dW5zb2xpY2l0ZWQgdHJhZmZpYyBjYW5ub3QgYmUgc2VudCB0byB0aGUgVUUuDQo+ DQo+QXMgd2UgYXJlIGxvb2tpbmcgYXQgYSBSZXF1aXJlbWVudHMgZG9jdW1lbnQgaGVyZSwgd2Ug c2hvdWxkIGZvY3VzIG1vcmUgb24NCj50aGUgcmVxdWlyZW1lbnRzIChpbiB0aGlzIGRvY3VtZW50 KSByYXRoZXIgdGhhbiBnbyBpbnRvIHNvbHV0aW9uIG1vZGUgYW5kDQo+cGVyaGFwcyB0aGluayBh aGVhZCB0aGF0IGl0IG1heSBiZSB0b28gaGFyZCB0aGVuIGJhY2sgb3V0IHRoZSByZXF1aXJlbWVu dHMuDQo+DQo+SSBmdWxseSBhZ3JlZSwgc2NhbGFiaWxpdHkgd2lsbCBsaWtlbHkgaW5mbHVlbmNl IGFyY2hpdGVjdHVyZSAoc29sdXRpb24NCj5tb2RlKSBzbyBpdCBuZWVkcyB0byBiZSBpbmNsdWRl ZC4NCj4NCj5SZWdhcmRzLA0KPkNodW9uZw0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb21dDQo+U2VudDogTW9uZGF5LCAyNCBGZWJydWFyeSAyMDE0IDI6MzkgUE0NCj5Ubzog5pys 6ZaT5L+K5LuLDQo+Q2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9y Zw0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNm Yy1yZXF1aXJlbWVudHMtMDMudHh0DQo+DQo+U2h1bnN1a2Utc2FuLA0KPg0KPldoaWxlIGEgdGhl b3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9yIG1vcmUgU0ZDcyBwZXIgc3Vic2Ny aWJlciwNCj5mb3IgcmVhc29ucyB5b3Ugc3RhdGUsIGl0IGlzbid0IHByYWN0aWNhbC4gIEJ1dCwg dGhlcmUgaXMgYW5vdGhlciB3YXkgdG8NCj52aWV3IHRoaXMgYXNwZWN0IG9mIHRoZSBwcm9ibGVt LiAgTGV0J3MgdGFrZSB5b3VyIHBlci1zdWJzY3JpYmVyIGN1c3RvbWl6ZWQNCj5maXJld2FsbCBh cyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBvbmx5IG9uZSBmaXJld2Fs bCwNCj5pbnN0ZWFkLCBhbmQgaXQgd2FzIGNhcGFibGUgb2YgbG9jYWwgcG9saWN5IGV2YWx1YXRp b24gYmFzZWQgb24gc3Vic2NyaWJlciwNCj50aGUgbnVtYmVyIG9mIFNGQ3Mgd291bGQgYmUgdmFz dGx5IHJlZHVjZWQuICAgT25lIHdheSBmb3IgdGhhdCB0byBoYXBwZW4NCj53b3VsZCBiZSB0byBz aW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9tIHRoZSBwYWNr ZXQNCj5hbmQgc29tZSBvdXQgb2YgYmFuZCBsb29rdXAgbWVjaGFuaXNtIGxpa2UgTERBUCBvciBS QURJVVMgYXQgdGhlIGZpcmV3YWxsLg0KPkFub3RoZXIgYXBwcm9hY2ggdG8gZGV0ZXJtaW5lIHdo byB0aGUgc3Vic2NyaWJlciBpcyB3b3VsZCBiZSBmb3IgdGhlIFNGQw0KPmNsYXNzaWZpZXIgdG8g YWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2VydmljZQ0K PmhlYWRlciAoZWcsIGFuIElNU0kpIGFuZCBzdGlsbCB1c2UgTERBUCwgZXRjLiBhdCB0aGUgZmly ZXdhbGwuDQo+DQo+SWYgdGhlIHByb2JsZW0gaXMgY2hhbmdlZCBzbGlnaHRseSBzbyB0aGF0IHRo ZSBmaXJld2FsbCBwb2xpY3kgaXMgcGVyIGdyb3VwDQo+b2Ygc3Vic2NyaWJlcnMsIHdoZXJlIHRo ZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4geWV0IGFub3RoZXINCj5hcHByb2Fj aCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwgYXMgYSBkaXN0aW5jdCBsb2dpY2FsIGZpcmV3YWxs IHBlcg0KPmZpcmV3YWxsIHBvbGljeSBzZXQgKHRoZXkgY291bGQgYWxsIHJlc2lkZSBpbiB0aGUg c2FtZSBtYWNoaW5lIG9yIFZNKSBhbmQNCj50byBjb29yZGluYXRlIHRoZSBjbGFzc2lmaWVyJ3Mg cG9saWN5IGFjY29yZGluZ2x5Lg0KPg0KPiAgIFJvbg0KPg0KPg0KPj4gT24gRmViIDIzLCAyMDE0 LCBhdCAxMDowNCBQTSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28u anA+DQo+d3JvdGU6DQo+Pg0KPj4gSGkgTWVkLA0KPj4NCj4+IEluIHRlcm1zIG9mIHlvdXIgY29t bWVudCwgSSBhc3N1bWVkIHNvbWUgdXNlIGNhc2VzIGFib3V0IHNjYWxhYmlsaXR5IHNvDQo+dGhh dCB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lk ZXJhdGlvbnMuDQo+PiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0aG9yIG9mIHJlcXVpcmVt ZW50IGRyYWZ0IGFuZCB0aGluaw0KPnNjYWxhYmlsaXR5IGlzIG9uZSBvZiBpbXBvcnRhbnQgdGhp bmdzIHRvIGNvbnNpZGVyLg0KPj4NCj4+IEFzc3VtaW5nIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGZv bGxvd2luZywgdGhlIG1hbmFnZW1lbnQgbWVjaGFuaXNtIG9mDQo+U2VydmljZSBGdW5jdGlvbiBD aGFpbnMgbWlnaHQgcmVxdWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPj4NCj4+IDEuIFRoZSBjYXNl IHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPj4gSSBhc3N1bWVkIHRoYXQgdGhlIHVu aXQgb2YgYXBwbHlpbmcgU0ZDIHRvIHRyYWZmaWMgaXMgZm9sbG93aW5nOw0KPj4gIC0gZ3JvdXBp bmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzZXJ2aWNl LA0KPj4gICAgZW50ZXJwcmlzZSBjdXN0b21lciBvciByZWdpb24sDQo+PiAgLSBwZXItc3Vic2Ny aWJlcjogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBlYWNoDQo+PiAg ICBzdWJzY3JpYmVyIChlLmcuIHBlciBJUCBhZGRyZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4+ICAt IHBlci1mbG93OiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2gg c3Vic2NyaWJlciwNCj4+IOOAgOOAgGFuZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGlj YXRpb24gZXQuYWwpLg0KPj4NCj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUg ZW5vcm1vdXMgbnVtYmVyIG9mIHN1YnNjcmliZXJzLCBhbmQNCj50aGUgbnVtYmVyIG9mIHN1YnNj cmliZXJzIGlzIHVwIHRvIHNldmVyYWwgdGVucyBvciBodW5kcmVkcyBvZiBtaWxsaW9uLg0KPlRo ZXJlZm9yZSwgaW4gY2FzZXMgb2YgcGVyLXN1YnNjcmliZXIgYW5kIHBlci1mbG93LCB0aGUgbnVt YmVyIG9mIFNGQ3MNCj5taWdodCBpbmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIg U0ZDcyB3b3VsZCBiZSBuZWVkZWQgaW4gdGhlIGNhc2UNCj50aGF0IHRoZXJlIGFyZSBzb21lIFNG cyBkZWRpY2F0ZWQgdG8gZWFjaCB1c2VyKGUuZy4gdkNQRSBhcyB1c2VyDQo+Y3VzdG9taXplZCku DQo+Pg0KPj4gQWxzbywgaW4gY2FzZSBvZiBncm91cGluZywgaWYgdGhlcmUgYXJlIG11bHRpcGxl IGdyb3VwcyB3aG9zZSBwb2xpY2llcw0KPmFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVy cHJpc2UgY3VzdG9tZXIgYW5kIHBlciByZWdpb24sIHRoZSBudW1iZXINCj5vZiBTRkNzIHdvdWxk IGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBwb2xpY3kgZm9yIGVhY2gN Cj5lbnRlcnByaXNlIGN1c3RvbWVyKS4NCj4+DQo+PiAyLiBUaGUgY2FzZSB0aGF0IHRoZXJlIGFy ZSBzb21lIFNGcyB0aGF0IG11c3QgYmUgY2xhc3NpZmllZCBmb3IgZWFjaA0KPmluc3RhbmNlOg0K Pj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBmdW5jdGlvbiBpbiB0 aGUgbmV0d29yayBhbmQgdGhlDQo+U0ZzIG11c3QgYmUgY2xhc3NpZmllZCBmb3IgZWFjaCBpbnN0 YW5jZSwgdGhlIGNvbWJpbmF0aW9uIG9mIFNGcyBtaWdodA0KPmluY3JlYXNlLg0KPj4gVGhlIFNG cyB0aGF0IHByb2Nlc3Mgc3RhdGVmdWwgdHJhZmZpYyBhcmUgbmVlZGVkIHRvIGJlIGRpZmZlcmVu dGlhdGVkIHBlcg0KPmluc3RhbmNlIChlLmcuIEZpcmV3YWxsLCBDb250ZW50cy1DYWNoZSwgYW5k IFZpZGVvLU9wdGltaXplcikuDQo+Pg0KPj4gSU1ITyxyZXF1aXJlbWVudHMgZm9yIHNjYWxhYmls aXR5IHdpbGwgYWZmZWN0IFNGQyBhcmNoaXRlY3R1cmUgYW5kIGhlYWRlcg0KPmZvcm1hdC4NCj4+ DQo+PiBUaGFua3MsDQo+Pg0KPj4gU2h1bnN1a2UNCj4+DQo+PiAoMjAxNC8wMi8xMiAxODo0OSks IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+Pj4gRGVhciBhbGwsDQo+Pj4N Cj4+PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2Vu dGF0aXZlcy4NCj4+Pg0KPj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFja2VkIGhlcmU6DQo+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJl bWVudHMtMDEmDQo+Pj4gZGlmZnR5cGU9LS1odG1sJnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1ib3Vj YWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IE1lZA0KPj4+ DQo+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gRGUgOiBJLUQtQW5ub3VuY2Ug W21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydA0KPj4+IGRl IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTIgZsOpdnJpZXIg MjAxNCAxMDo0NiDDgA0KPj4+IDogaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFj dGlvbjoNCj4+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pg0K Pj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+Pj4NCj4+Pg0KPj4+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nDQo+Pj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcNCj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJvbiBQYXJrZXINCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxv cyBQaWduYXRhcm8NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEtlbmdvIE5haXRvDQo+ Pj4gICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMt MDMudHh0DQo+Pj4gICAgUGFnZXMgICAgICAgICAgIDogMTQNCj4+PiAgICBEYXRlICAgICAgICAg ICAgOiAyMDE0LTAyLTEyDQo+Pj4NCj4+PiBBYnN0cmFjdDoNCj4+PiAgICBUaGlzIGRvY3VtZW50 IGlkZW50aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+ PiAgICBDaGFpbmluZyAoU0ZDKS4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+Pg0K Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRz LTAzDQo+Pj4NCj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYm91Y2Fk YWlyLXNmYy1yZXF1aXJlbWVudHMtMDMNCj4+Pg0KPj4+DQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+PiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQNCj50b29scy5pZXRmLm9yZy4NCj4+Pg0KPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+Pj4gSS1ELUFu bm91bmNlQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pLWQtYW5ub3VuY2UNCj4+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+DQo+ PiAtLQ0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+ IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0KPj4NCj4+IOaXpeacrOmbu+S/oembu+ip seagquW8j+S8muekvg0KPj4g44ON44OD44OI44Ov44O844Kv44K144O844OT44K544K344K544OG 44Og56CU56m25omADQo+PiDou6LpgIHjgrXjg7zjg5Pjgrnln7rnm6Tjg5fjg63jgrjjgqfjgq/j g4gNCj4+IOi7oumAgeOCteODvOODk+OCueWItuW+oURQDQo+Pg0KPj4g44CSMTgwLTg1ODXjgIDm nbHkuqzpg73mrabolLXph47luILnt5HnlLozLTktMTENCj4+IFRFTDogMDQyMi01OS0zNDg2DQo+ PiBFLU1BSUw6IGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanANCj4+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNm Y0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBt YWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0K From nobody Tue Feb 25 08:00:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4481A00A3 for ; Tue, 25 Feb 2014 08:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 6FHqSI925h7T for ; Tue, 25 Feb 2014 08:00:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CD7761A07E4 for ; Tue, 25 Feb 2014 08:00:31 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 35A5A324535; Tue, 25 Feb 2014 17:00:30 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 164244C15B; Tue, 25 Feb 2014 17:00:30 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 25 Feb 2014 17:00:30 +0100 From: To: "wang.cui1@zte.com.cn" Date: Tue, 25 Feb 2014 17:00:28 +0100 Thread-Topic: [sfc] Framework & routing Thread-Index: Ac8t6OTxu9bU7qcmT9+vDm+97x4njQEWHb6A Message-ID: <94C682931C08B048B7A8645303FDC9F36F4E4D7A17@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F4E4D7A17PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.25.93015 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wUpgW54GFKmm29SygtfWcyM6qYg Cc: Wei Meng , "sfc@ietf.org" , Bhumip Khasnabish Subject: Re: [sfc] Framework & routing 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, 25 Feb 2014 16:00:34 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F4E4D7A17PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Please see inline. Cheers, Med De : wang.cui1@zte.com.cn [mailto:wang.cui1@zte.com.cn] Envoy=E9 : jeudi 20 f=E9vrier 2014 04:07 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Bhumip Khasnabish; Wei Meng; sfc@ietf.org; wang.cui1@zte.com.cn Objet : [sfc] Framework & routing Hi, med I was looking at your framework proposal. The proposal elaborates on framework & PDP architecture and some deployment considerations such as deployment models. In section 10.2 para 3, it describes a router-based mechanisam which offers a default router for the packets delivery between SF nodes. However,I would like to know how inbound traffic steer packets to the Ingress Node for inbound direction ? [Med] This deployment model assumes the SF router is responsible for managi= ng the order and the forwarding to the SFs to be invoked. SF applies its fu= nctionality to a received packet and then returns the outcome to the SF Rou= ter. Such as, there is a NAT44 SF node with public ipv4 address pool 12.3.4.0/24, then how to advertise this route to the legacy network for the inbound traffic ? [Med] If your question is about the router-based model, the routing adverti= sement can be made by the SF Router to attract incoming traffic. This maybe a deployment consideration need to point out. [Med] This point is specific to the SF(NAT) case. FYI, draft-liu-sfc-use-ca= ses tries to generalize this issue as follows: o Some stateful SFs (e.g., NAT or firewall) may need to treat both outgoing and incoming packets. The design of SF Maps must take into account such constraints, otherwise, the service may be disturbed. The set of SFs that need to be invoked for both direction is up to the responsibility of each administrative entity operating an SFC-enabled domain. --_000_94C682931C08B048B7A8645303FDC9F36F4E4D7A17PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Please see inline.

 <= /o:p>

Cheers,

Med

 

De : = wang.cui1@zte.com.cn [mailto:wang.cui1@zte.com.cn]
Envoy=E9 : jeudi 20 f=E9vrier 2014 04:07
=C0 : BOUCADAIR Mohamed IMT= /OLN
Cc : Bhumip Khasnabish; Wei Meng; sfc@ietf.org; wang.cu= i1@zte.com.cn
Objet : [sfc] Framework & routing

 


Hi, med

  I was looking= at your framework proposal.

  The proposal elaborates on framew= ork &  PDP architecture and
  some deployment consideration= s such as deployment models.
 
  In section 10.2 para 3, it d= escribes a router-based mechanisam
  which offers a default router f= or the packets delivery between
  SF nodes.

  However,I w= ould like to know how inbound traffic steer packets
  to the Ingres= s Node for inbound direction ?

[Med]= This deployment model assumes the SF router is responsible for managing th= e order and the forwarding to the SFs to be invoked. SF applies its functio= nality to a received packet and then returns the outcome to the SF Router.<= o:p>


  Such as, there is a NAT44 SF node with public ipv4 address pool
=   12.3.4.0/24, then how to advertise this route to the legacy network<= /span>
  for the inbound traffic ?

<= i>= [Med] If your question is about the router-based model, the routing adverti= sement can be made by the SF Router to attract incoming traffic.
=   This maybe a deployment consideration need to point out.

[Med] This point is specific to the SF(NAT) c= ase. FYI, draft-liu-sfc-use-cases tries to generalize this issue as follows= :

=A0=A0 o=A0 Some stateful SFs (e.g., NA=
T or firewall) may need to treat both
=A0=A0=A0=A0=A0 =
outgoing and incoming packets.=A0 The design of SF Maps must take
=A0=A0=A0=A0=A0 into account such constraints, otherwise, the s=
ervice may be
=A0=A0=A0=A0=A0 disturbed.=A0 The set of=
 SFs that need to be invoked for both
=A0=A0=A0=A0=A0 =
direction is up to the responsibility of each administrative
=A0=A0=A0=A0=A0 entity operating an SFC-enabled domain.
 
= --_000_94C682931C08B048B7A8645303FDC9F36F4E4D7A17PUEXCB1Bnante_-- From nobody Tue Feb 25 23:25:33 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989231A0022 for ; Tue, 25 Feb 2014 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 BWsSNstbiEpx for ; Tue, 25 Feb 2014 23:25:22 -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 6D7451A000B for ; Tue, 25 Feb 2014 23:25:22 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s1Q7PIOA012630; Wed, 26 Feb 2014 16:25:18 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 254CBE013E; Wed, 26 Feb 2014 16:25:18 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 18DB5E013B; Wed, 26 Feb 2014 16:25:18 +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 s1Q7PBQj016970; Wed, 26 Feb 2014 16:25:18 +0900 Message-ID: <530D9719.2090304@lab.ntt.co.jp> Date: Wed, 26 Feb 2014 16:26:17 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To: Ron Parker , Chris Frederick X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RyApI9hzt-LVUZUTClPDZRIjQT0 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 07:25:25 -0000 Hi Chris, Ron, Thank you for your reply. I understood that you said. And I agree with you that the method using metadata is one of the methods for recognizing subscribers. But this problem is implementation matters, so it is not at the stage for discussion yet, I think. What I want to say is that there are requests for distinct services per subscriber, so that SFC architecture should be scalable. Regards, Shunsuke (2014/02/25 23:49), Ron Parker wrote: > Expanding on Chris' comments, I don't think the practical limitations are wrt the number of fully-qualified 5-tuples, but rather the number of distinct treatment sequences that arise from those flows. Of the 100's of millions of flows that might be tracked by a high end classifier, perhaps the number of unique sequences that arise are in the 1000's. If applying a fixed-line or mobile service provider perspective, the number of chains would be proportional to the number of distinct end-to-end service plans offered and then multiplied by the flow-aware subsetting that can be managed by the classifier (i.e., subscriber is subject to service function A then B then C but B only needs TCP/80 traffic, A only needs UDP traffic, ...). > > Ron > > > -----Original Message----- > From: Chris Frederick [mailto:cfrederick@sandvine.com] > Sent: Tuesday, February 25, 2014 9:44 AM > To: Shunsuke Homma; Ron Parker > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Hi Shunsuke-san, > I recognize that ultimately, this is an implementation decision and not something to be mandated as a hard 'rule'. I just wanted to highlight what is possible + what we believe to be best practices in this area, based on our experience. > That said, yes, I believe that in practical (real-world) terms, it makes sense to deemphasize the '(re)classification' role of SFs in most cases, for reasons I've stated previously (questions of metadata sharing between SFs, issues related to retaining integrity of chains/breaking flows, etc.). > To your comment about scaling the SFC Controller, I would just say that there are commercially deployed SFC Controllers today that do this, i.e. sit inline in consumer networks, receive/inspect millions of concurrent bidirectional flows, + make real-time SFC steering and sequencing decisions based on flow, subscriber, session, and network conditions. > Obviously, differences in vendor capabilities, as well as architectural decisions viz consolidating vs. distributing different SFC functions like flow classification, PDP/SFC Controller, steering/lb, etc, all will have an impact here. Best, /c > > -----Original Message----- > From: Shunsuke Homma [mailto:homma.shunsuke@lab.ntt.co.jp] > Sent: Tuesday, February 25, 2014 7:25 AM > To: Chris Frederick; Ron Parker > Cc: mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt > > Hi Chris, > > Do you mean that, for retaining integrity of chains, management of subscribers should be provided not by SFs, but by SFC controller? > > If so, the problem is that the number of chains that SFC controller must manage is large, and it is the same problem I said, I think. > > Regards, > > Shunsuke > > (2014/02/25 14:17), Chris Frederick wrote: >> Hi Shunsuke-san, >> I acknowledge the comments about these being implementation matters, >> but I've offered some thoughts inline with your mail below. Thx, /c >> >> -----Original Message----- >> From: Shunsuke Homma [mailto:homma.shunsuke@lab.ntt.co.jp] >> Sent: Monday, February 24, 2014 9:00 PM >> To: Chris Frederick; Ron Parker >> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] TR: I-D Action: >> draft-boucadair-sfc-requirements-03.txt >> >> Hi Ron, Chris, >> >> Thank you for your reply. >> >> I think that your points are following: >> in case that there are some SFs as user customized, per-subscriber SFCs shouldn't be made, but the SFs should recognize subscribers by IP address or metadata. >> CF>> My point was that I don't see it as desirable to have specific per-subscriber SFC rules (as in static rules, like subscriber_Chris=SFC_a_b_c), with a rule for every sub, in that sense. Better is a scenario where the SFC chain controller is subscriber-aware + able to evaluate multiple orthogonal flow + subscriber conditions in real time, and formulate a chain on the basis of those dynamic conditions. >> >> Of course, it is one of the solutions. >> However, in this case, I think that SFs as user customized might be required to have a function to recognize each subscriber. >> CF>> I wasn't actually thinking in terms of SF (re)classification; I've previously commented on why I think that idea is somewhat fraught (i.e. because modification of the flow path by a service function within the chain could result in a 'breaking' of the chain or flow. If there is not bidirectional symmetry in the flow and service function elements in the chain can make routing decisions, then there's some metadata correlation to work out, at minimum). I do agree that the SFC chain controller would need to be subscriber-aware though. >> >> On the other hand, I think that there are cases when the function can't be adopted, such like SFs are current equipment that don't have function to recognize metadata. >> CF>> Agreed. This speaks to my comment above + to the advantages some of us have mentioned viz a consolidated policy-based steering/PDP/SFC chain controller entity. >> >> How do we handle these cases? >> Any new problems or requirements may occur? >> >> regards, >> >> Shunsuke >> >> (2014/02/25 8:46), Chris Frederick wrote: >>> Yes, agreed on that. >>> >>> -----Original Message----- >>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> Sent: Monday, February 24, 2014 6:45 PM >>> To: Chris Frederick; 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: RE: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Thanks, Chris. >>> >>> I do think there are lots of efficiencies when the flow learner (classifier) and policy evaluator (PDP) are co-located. However, architecturally, I wouldn't mandate that they be co-located. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Chris Frederick [mailto:cfrederick@sandvine.com] >>> Sent: Monday, February 24, 2014 5:26 PM >>> To: Ron Parker; 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: RE: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Agreed. >>> To restate this slightly, if the SFC steering/decision locus is capable of evaluating multiple orthogonal policy conditions then this issue is obviated; subscribers become an aggregate of 'what they are' + are not simply 'who they are'. >>> As Ron states, this awareness may be derived from LDAP lookup, RADIUS, Gx, pre-provisioned rules, etc. >>> To illustrate w/ an example, we might say something like this: >>> If subscriber X is using youtube, and is on a congested cell, and is on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the chain consists of service functions a, b, and c. >>> There's no need to enter a static SFC rule/chain for subscriber X (or any subscriber). In fact, it's not desirable anyway because all of the above conditions may evaluate to True, save one ("is on a congested cell"), and the resultant chain might be altered (perhaps to bypass a video optimization service function). >>> This also goes to the earlier comments Ron + I made about >>> consolidating the flow recognition + decision-making entity in a >>> single (suitably policy-aware) node to reduce the complexity + to >>> scale properly. Thx, /c >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Sunday, February 23, 2014 10:39 PM >>> To: 本間俊介 >>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] TR: I-D Action: >>> draft-boucadair-sfc-requirements-03.txt >>> >>> Shunsuke-san, >>> >>> While a theoretical case can be made for one or more SFCs per subscriber, for reasons you state, it isn't practical. But, there is another way to view this aspect of the problem. Let's take your per-subscriber customized firewall as a hypothetical example. If there were only one firewall, instead, and it was capable of local policy evaluation based on subscriber, the number of SFCs would be vastly reduced. One way for that to happen would be to simply use the source/destination IP address from the packet and some out of band lookup mechanism like LDAP or RADIUS at the firewall. Another approach to determine who the subscriber is would be for the SFC classifier to add a distinct subscriber id as metadata to the service header (eg, an IMSI) and still use LDAP, etc. at the firewall. >>> >>> If the problem is changed slightly so that the firewall policy is per group of subscribers, where there are perhaps 10s of groups, then yet another approach is to model the firewall as a distinct logical firewall per firewall policy set (they could all reside in the same machine or VM) and to coordinate the classifier's policy accordingly. >>> >>> Ron >>> >>> >>>> On Feb 23, 2014, at 10:04 PM, "本間俊介" wrote: >>>> >>>> Hi Med, >>>> >>>> In terms of your comment, I assumed some use cases about scalability so that we can continue the discussion about scalability considerations. >>>> #I work with K.Naito, co-author of requirement draft and think scalability is one of important things to consider. >>>> >>>> Assuming the use cases listed following, the management mechanism of Service Function Chains might require high scalability. >>>> >>>> 1. The case that the types of SF increase: >>>> I assumed that the unit of applying SFC to traffic is following; >>>> - grouping: traffic is applied with specific SFC for each service, >>>> enterprise customer or region, >>>> - per-subscriber: traffic is applied with specific SFC for each　 >>>> subscriber (e.g. per IP address, VLAN ID et.al), >>>> - per-flow: traffic is applied with specific SFC for each subscriber, >>>> 　　and objective (e.g. pre URL, application et.al). >>>> >>>> Some of the service providers have enormous number of subscribers, and the number of subscribers is up to several tens or hundreds of million. Therefore, in cases of per-subscriber and per-flow, the number of SFCs might increase explosively. Per-subscriber SFCs would be needed in the case that there are some SFs dedicated to each user(e.g. vCPE as user customized). >>>> >>>> Also, in case of grouping, if there are multiple groups whose policies are different, such as per enterprise customer and per region, the number of SFCs would increase (e.g. Firewalls have different policy for each enterprise customer). >>>> >>>> 2. The case that there are some SFs that must be classified for each instance: >>>> In case that there are SFs with the same function in the network and the SFs must be classified for each instance, the combination of SFs might increase. >>>> The SFs that process stateful traffic are needed to be differentiated per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>>> >>>> IMHO,requirements for scalability will affect SFC architecture and header format. >>>> >>>> Thanks, >>>> >>>> Shunsuke >>>> >>>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>>> Dear all, >>>>> >>>>> This new version integrates inputs from NTT representatives. >>>>> >>>>> The diff can be tracked here: >>>>> http://www.ietf.org/rfcdiff?url1=draft-boucadair-sfc-requirements-0 >>>>> 1 >>>>> & >>>>> difftype=--html&submit=Go!&url2=draft-boucadair-sfc-requirements-03 >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> -----Message d'origine----- >>>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part >>>>> de internet-drafts@ietf.org Envoyé : mercredi 12 février 2014 10:46 >>>>> À >>>>> : i-d-announce@ietf.org Objet : I-D Action: >>>>> draft-boucadair-sfc-requirements-03.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> >>>>> >>>>> Title : Requirements for Service Function Chaining >>>>> Authors : Mohamed Boucadair >>>>> Christian Jacquenet >>>>> Yuanlong Jiang >>>>> Ron Parker >>>>> Carlos Pignataro >>>>> Kengo Naito >>>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>>> Pages : 14 >>>>> Date : 2014-02-12 >>>>> >>>>> Abstract: >>>>> This document identifies the requirements for the Service Function >>>>> Chaining (SFC). >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-0 >>>>> 3 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> -- >>>> ******************************************** >>>> 本間 俊介 (Homma Shunsuke) >>>> >>>> 日本電信電話株å¼ä¼šç¤¾ >>>> ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ã‚µãƒ¼ãƒ“スシステム研究所 >>>> 転é€ã‚µãƒ¼ãƒ“ス基盤プロジェクト >>>> 転é€ã‚µãƒ¼ãƒ“ス制御DP >>>> >>>> 〒180-8585　æ±äº¬éƒ½æ­¦è”µé‡Žå¸‚緑町3-9-11 >>>> TEL: 0422-59-3486 >>>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>>> ******************************************** >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >> >> >> -- >> ---------------------------------- >> Shunsuke Homma >> >> TEL: +81 0422 59 3486 >> FAX: +81 0422 60 7460 >> >> NTT Network Service System Labs. >> Musashino city, Tokyo, Japan >> ---------------------------------- >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> > > > -- > ---------------------------------- > Shunsuke Homma > > TEL: +81 0422 59 3486 > FAX: +81 0422 60 7460 > > NTT Network Service System Labs. > Musashino city, Tokyo, Japan > ---------------------------------- > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------- Shunsuke Homma TEL: +81 0422 59 3486 FAX: +81 0422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Feb 26 02:25:21 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B971A01F1; Wed, 26 Feb 2014 02:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.947 X-Spam-Level: X-Spam-Status: No, score=-99.947 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WkHPCpiV2fg; Wed, 26 Feb 2014 02:25:00 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA9A51A0031; Wed, 26 Feb 2014 02:24:59 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 2686B12ADA14; Wed, 26 Feb 2014 18:24:44 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2BBDECC20CD; Wed, 26 Feb 2014 18:24:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s1QAOjYY042769; Wed, 26 Feb 2014 18:24:45 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4E4D7A17@PUEXCB1B.nanterre.francetelecom.fr> To: MIME-Version: 1.0 X-KeepSent: 3AC89747:228062DD-48257C8B:00361307; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 26 Feb 2014 18:24:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-02-26 18:24:42, Serialize complete at 2014-02-26 18:24:42 Content-Type: multipart/alternative; boundary="=_alternative 0039620248257C8B_=" X-MAIL: mse01.zte.com.cn s1QAOjYY042769 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ldajULXRgvPgZN_7bBDtr42fV6Q Cc: sfc , "wang.cui1@zte.com.cn" , "sfc@ietf.org" , Bhumip Khasnabish Subject: Re: [sfc] Framework & routing 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, 26 Feb 2014 10:25:08 -0000 This is a multipart message in MIME format. --=_alternative 0039620248257C8B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgTWVk77yMDQoNCiAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj4gW01lZF0gVGhpcyBkZXBsb3lt ZW50IG1vZGVsIGFzc3VtZXMgdGhlIFNGIHJvdXRlciBpcyByZXNwb25zaWJsZSBmb3INCj4gbWFu YWdpbmcgdGhlIG9yZGVyIGFuZCB0aGUgZm9yd2FyZGluZyB0byB0aGUgU0ZzIHRvIGJlIGludm9r ZWQuIFNGIA0KPiBhcHBsaWVzIGl0cyBmdW5jdGlvbmFsaXR5IHRvIGEgcmVjZWl2ZWQgcGFja2V0 IGFuZCB0aGVuIHJldHVybnMgdGhlIA0KPiBvdXRjb21lIHRvIHRoZSBTRiBSb3V0ZXIuDQpbV2Vp XTogSU1ITywgYmVjYXVzZSBhbGwgcGFja2V0cyBtdXN0IGJlIHJldHVybmVkIGJhY2ssIHRoaXMg ZGVwbG95bWVudCANCm1vZGVsIGlzIGNvc3RseSBpbiB0ZXJtcyBvZiBwZXJmb3JtYW5jZS4gSWYg SSB1bmRlcnN0YW5kIHdoYXQgeW91DQptZWFuIGNvcnJlY3RseS4NCiAgQW5vdGhlciBkZXBsb3lt ZW50IGlzIHRoYXQgU0ZzIGZvcndhcmQgcGFja2V0IGRpcmVjdGx5LiBIb3cgYWJvdXQgdGhlDQpz b2x1dGlvbiB1bmRlciB0aGlzIHNjZW5hcmlvPw0KDQo+IFtNZWRdIElmIHlvdXIgcXVlc3Rpb24g aXMgYWJvdXQgdGhlIHJvdXRlci1iYXNlZCBtb2RlbCwgdGhlIHJvdXRpbmcgDQo+IGFkdmVydGlz ZW1lbnQgY2FuIGJlIG1hZGUgYnkgdGhlIFNGIFJvdXRlciB0byBhdHRyYWN0IGluY29taW5nIHRy YWZmaWMuIA0KPiAgIFRoaXMgbWF5YmUgYSBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gbmVlZCB0 byBwb2ludCBvdXQuIA0KW1dlaV06IERvIHlvdSBtZWFuIHBvb2wgTVVTVCBjb25maWd1cmVkIGlu IFNGIHJvdXRlcnM/IA0KSSB0aGluayB0aGlzIGFzc3VtcHRpb24gaXMgYmFzZWQgb24gdGhlIGRl cGxveW1lbnQgdGhhdCBTRnMgcmV0dXJuIHRoZSANCm91dGNvbWUgdG8gdGhlIFNGIHJvdXRlcnMg Zm9yIGZvcndhcmRpbmcgcmF0aGVyIHRoYW4gZm9yd2FyZGluZyBwYWNrZXQNCmRpcmVjdGx5IGJ5 IFNGcy4gSWYgdGhlIGxhdGVyLCBob3cgdG8gc3RlZXIgcGFja2V0cyB0byB0aGUgSW5ncmVzcyBO b2RlIA0KZm9yIGluYm91bmQgZGlyZWN0aW9uID8NCg0KSW4gYSB3YXksIGl0IG1pZ2h0IG5vdCBi ZSBzdWl0ZWQgZm9yIGV2ZXJ5d2hlcmUgZm9yIHJldHVybmluZyB0aGUgb3V0Y29tZSANCnRvIFNG IHJvdXRlcnMgLg0KDQpUaGFua3MsDQpXZWkNCg0KDQoNCiJzZmMiIDxzZmMtYm91bmNlc0BpZXRm Lm9yZz4gIDIwMTQtMDItMjYgMDA6MDA6Mjg6DQoNCj4gSGkgTGluZGEsDQo+IA0KPiBQbGVhc2Ug c2VlIGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiBEZSA6IHdhbmcuY3VpMUB6 dGUuY29tLmNuIFttYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY25dIA0KPiBFbnZvecOpIDogamV1 ZGkgMjAgZsOpdnJpZXIgMjAxNCAwNDowNw0KPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE4NCj4gQ2MgOiBCaHVtaXAgS2hhc25hYmlzaDsgV2VpIE1lbmc7IHNmY0BpZXRmLm9yZzsgd2Fu Zy5jdWkxQHp0ZS5jb20uY24NCj4gT2JqZXQgOiBbc2ZjXSBGcmFtZXdvcmsgJiByb3V0aW5nDQo+ IA0KPiANCj4gSGksIG1lZCANCj4gDQo+ICAgSSB3YXMgbG9va2luZyBhdCB5b3VyIGZyYW1ld29y ayBwcm9wb3NhbC4gDQo+IA0KPiAgIFRoZSBwcm9wb3NhbCBlbGFib3JhdGVzIG9uIGZyYW1ld29y ayAmICBQRFAgYXJjaGl0ZWN0dXJlIGFuZCANCj4gICBzb21lIGRlcGxveW1lbnQgY29uc2lkZXJh dGlvbnMgc3VjaCBhcyBkZXBsb3ltZW50IG1vZGVscy4gDQo+IA0KPiAgIEluIHNlY3Rpb24gMTAu MiBwYXJhIDMsIGl0IGRlc2NyaWJlcyBhIHJvdXRlci1iYXNlZCBtZWNoYW5pc2FtIA0KPiAgIHdo aWNoIG9mZmVycyBhIGRlZmF1bHQgcm91dGVyIGZvciB0aGUgcGFja2V0cyBkZWxpdmVyeSBiZXR3 ZWVuIA0KPiAgIFNGIG5vZGVzLiANCj4gDQo+ICAgSG93ZXZlcixJIHdvdWxkIGxpa2UgdG8ga25v dyBob3cgaW5ib3VuZCB0cmFmZmljIHN0ZWVyIHBhY2tldHMgDQo+ICAgdG8gdGhlIEluZ3Jlc3Mg Tm9kZSBmb3IgaW5ib3VuZCBkaXJlY3Rpb24gPw0KPiBbTWVkXSBUaGlzIGRlcGxveW1lbnQgbW9k ZWwgYXNzdW1lcyB0aGUgU0Ygcm91dGVyIGlzIHJlc3BvbnNpYmxlIGZvcg0KPiBtYW5hZ2luZyB0 aGUgb3JkZXIgYW5kIHRoZSBmb3J3YXJkaW5nIHRvIHRoZSBTRnMgdG8gYmUgaW52b2tlZC4gU0Yg DQo+IGFwcGxpZXMgaXRzIGZ1bmN0aW9uYWxpdHkgdG8gYSByZWNlaXZlZCBwYWNrZXQgYW5kIHRo ZW4gcmV0dXJucyB0aGUgDQo+IG91dGNvbWUgdG8gdGhlIFNGIFJvdXRlci4NCj4gDQo+ICAgU3Vj aCBhcywgdGhlcmUgaXMgYSBOQVQ0NCBTRiBub2RlIHdpdGggcHVibGljIGlwdjQgYWRkcmVzcyBw b29sIA0KPiAgIDEyLjMuNC4wLzI0LCB0aGVuIGhvdyB0byBhZHZlcnRpc2UgdGhpcyByb3V0ZSB0 byB0aGUgbGVnYWN5IG5ldHdvcmsgDQo+ICAgZm9yIHRoZSBpbmJvdW5kIHRyYWZmaWMgPyANCj4g W01lZF0gSWYgeW91ciBxdWVzdGlvbiBpcyBhYm91dCB0aGUgcm91dGVyLWJhc2VkIG1vZGVsLCB0 aGUgcm91dGluZyANCj4gYWR2ZXJ0aXNlbWVudCBjYW4gYmUgbWFkZSBieSB0aGUgU0YgUm91dGVy IHRvIGF0dHJhY3QgaW5jb21pbmcgdHJhZmZpYy4gDQo+ICAgVGhpcyBtYXliZSBhIGRlcGxveW1l bnQgY29uc2lkZXJhdGlvbiBuZWVkIHRvIHBvaW50IG91dC4gDQo+IFtNZWRdIFRoaXMgcG9pbnQg aXMgc3BlY2lmaWMgdG8gdGhlIFNGKE5BVCkgY2FzZS4gRllJLCBkcmFmdC1saXUtDQo+IHNmYy11 c2UtY2FzZXMgdHJpZXMgdG8gZ2VuZXJhbGl6ZSB0aGlzIGlzc3VlIGFzIGZvbGxvd3M6DQo+ICAg IG8gIFNvbWUgc3RhdGVmdWwgU0ZzIChlLmcuLCBOQVQgb3IgZmlyZXdhbGwpIG1heSBuZWVkIHRv IHRyZWF0IGJvdGgNCj4gICAgICAgb3V0Z29pbmcgYW5kIGluY29taW5nIHBhY2tldHMuICBUaGUg ZGVzaWduIG9mIFNGIE1hcHMgbXVzdCB0YWtlDQo+ICAgICAgIGludG8gYWNjb3VudCBzdWNoIGNv bnN0cmFpbnRzLCBvdGhlcndpc2UsIHRoZSBzZXJ2aWNlIG1heSBiZQ0KPiAgICAgICBkaXN0dXJi ZWQuICBUaGUgc2V0IG9mIFNGcyB0aGF0IG5lZWQgdG8gYmUgaW52b2tlZCBmb3IgYm90aA0KPiAg ICAgICBkaXJlY3Rpb24gaXMgdXAgdG8gdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGVhY2ggYWRtaW5p c3RyYXRpdmUNCj4gICAgICAgZW50aXR5IG9wZXJhdGluZyBhbiBTRkMtZW5hYmxlZCBkb21haW4u DQo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz ZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --=_alternative 0039620248257C8B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1lZO+8jDwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyBQbGVhc2Ugc2VlIGlubGluZS48L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgW01lZF0gVGhpcyBkZXBsb3lt ZW50IG1vZGVsIGFzc3VtZXMgdGhlIFNGIHJvdXRlcg0KaXMgcmVzcG9uc2libGUgZm9yPGJyPg0K Jmd0OyBtYW5hZ2luZyB0aGUgb3JkZXIgYW5kIHRoZSBmb3J3YXJkaW5nIHRvIHRoZSBTRnMgdG8g YmUgaW52b2tlZC4gU0YNCjxicj4NCiZndDsgYXBwbGllcyBpdHMgZnVuY3Rpb25hbGl0eSB0byBh IHJlY2VpdmVkIHBhY2tldCBhbmQgdGhlbiByZXR1cm5zIHRoZQ0KPGJyPg0KJmd0OyBvdXRjb21l IHRvIHRoZSBTRiBSb3V0ZXIuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bV2Vp XTogSU1ITywgYmVjYXVzZSBhbGwgcGFja2V0cyBtdXN0IGJlIHJldHVybmVkDQpiYWNrLCB0aGlz IGRlcGxveW1lbnQgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5tb2RlbCBpcyBj b3N0bHkgaW4gdGVybXMgb2YgcGVyZm9ybWFuY2UuIElmIEkgdW5kZXJzdGFuZA0Kd2hhdCB5b3U8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm1lYW4gY29ycmVjdGx5LjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7IEFub3RoZXIgZGVwbG95bWVudCBpcyB0 aGF0IFNGcyBmb3J3YXJkIHBhY2tldA0KZGlyZWN0bHkuIEhvdyBhYm91dCB0aGU8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnNvbHV0aW9uIHVuZGVyIHRoaXMgc2NlbmFyaW8/PC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtNZWRdIElmIHlvdXIg cXVlc3Rpb24gaXMgYWJvdXQgdGhlIHJvdXRlci1iYXNlZA0KbW9kZWwsIHRoZSByb3V0aW5nIDxi cj4NCiZndDsgYWR2ZXJ0aXNlbWVudCBjYW4gYmUgbWFkZSBieSB0aGUgU0YgUm91dGVyIHRvIGF0 dHJhY3QgaW5jb21pbmcgdHJhZmZpYy4NCjxicj4NCiZndDsgJm5ic3A7IFRoaXMgbWF5YmUgYSBk ZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gbmVlZCB0byBwb2ludCBvdXQuIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+W1dlaV06IERvIHlvdSBtZWFuIHBvb2wgTVVTVCBjb25maWd1 cmVkIGluIFNGIHJvdXRlcnM/DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkg dGhpbmsgdGhpcyBhc3N1bXB0aW9uIGlzIGJhc2VkIG9uIHRoZSBkZXBsb3ltZW50DQp0aGF0IFNG cyByZXR1cm4gdGhlIDxicj4NCm91dGNvbWUgdG8gdGhlIFNGIHJvdXRlcnMgZm9yIGZvcndhcmRp bmcgcmF0aGVyIHRoYW4gZm9yd2FyZGluZyBwYWNrZXQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPmRpcmVjdGx5IGJ5IFNGcy4gSWYgdGhlIGxhdGVyLCBob3cgdG8gc3RlZXIgcGFj a2V0cw0KdG8gdGhlIEluZ3Jlc3MgTm9kZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPmZvciBpbmJvdW5kIGRpcmVjdGlvbiA/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIGEgd2F5LCA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9 Mj5pdA0KbWlnaHQgbm90IGJlIHN1aXRlZCBmb3IgZXZlcnl3aGVyZSBmb3IgcmV0dXJuaW5nIHRo ZSBvdXRjb21lIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dG8gU0Ygcm91dGVy cyAuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGFua3MsPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XZWk8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O3NmYyZxdW90OyAmbHQ7c2ZjLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7ICZuYnNwOzIwMTQtMDItMjYNCjAwOjAwOjI4Ojxicj4NCjxicj4NCiZn dDsgSGkgTGluZGEsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBQbGVhc2Ugc2VlIGlubGlu ZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENoZWVycyw8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgTWVkPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEZSA6 IHdhbmcuY3VpMUB6dGUuY29tLmNuIFttYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY25dDQo8YnI+ DQomZ3Q7IEVudm95w6kgOiBqZXVkaSAyMCBmw6l2cmllciAyMDE0IDA0OjA3PGJyPg0KJmd0OyDD gCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQomZ3Q7IENjIDogQmh1bWlwIEtoYXNu YWJpc2g7IFdlaSBNZW5nOyBzZmNAaWV0Zi5vcmc7IHdhbmcuY3VpMUB6dGUuY29tLmNuPGJyPg0K Jmd0OyBPYmpldCA6IFtzZmNdIEZyYW1ld29yayAmYW1wOyByb3V0aW5nPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEhpLCBtZWQgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZu YnNwOyBJIHdhcyBsb29raW5nIGF0IHlvdXIgZnJhbWV3b3JrIHByb3Bvc2FsLiA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7IFRoZSBwcm9wb3NhbCBlbGFib3JhdGVzIG9uIGZyYW1ld29yayAm YW1wOyAmbmJzcDtQRFAgYXJjaGl0ZWN0dXJlDQphbmQgPGJyPg0KJmd0OyAmbmJzcDsgc29tZSBk ZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zIHN1Y2ggYXMgZGVwbG95bWVudCBtb2RlbHMuIDxicj4N CiZndDsgJm5ic3A7IDxicj4NCiZndDsgJm5ic3A7IEluIHNlY3Rpb24gMTAuMiBwYXJhIDMsIGl0 IGRlc2NyaWJlcyBhIHJvdXRlci1iYXNlZCBtZWNoYW5pc2FtDQo8YnI+DQomZ3Q7ICZuYnNwOyB3 aGljaCBvZmZlcnMgYSBkZWZhdWx0IHJvdXRlciBmb3IgdGhlIHBhY2tldHMgZGVsaXZlcnkgYmV0 d2Vlbg0KPGJyPg0KJmd0OyAmbmJzcDsgU0Ygbm9kZXMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAm bmJzcDsgSG93ZXZlcixJIHdvdWxkIGxpa2UgdG8ga25vdyBob3cgaW5ib3VuZCB0cmFmZmljIHN0 ZWVyIHBhY2tldHMNCjxicj4NCiZndDsgJm5ic3A7IHRvIHRoZSBJbmdyZXNzIE5vZGUgZm9yIGlu Ym91bmQgZGlyZWN0aW9uID88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg W01lZF0gVGhpcyBkZXBsb3ltZW50IG1vZGVsIGFzc3VtZXMgdGhlIFNGIHJvdXRlcg0KaXMgcmVz cG9uc2libGUgZm9yPGJyPg0KJmd0OyBtYW5hZ2luZyB0aGUgb3JkZXIgYW5kIHRoZSBmb3J3YXJk aW5nIHRvIHRoZSBTRnMgdG8gYmUgaW52b2tlZC4gU0YNCjxicj4NCiZndDsgYXBwbGllcyBpdHMg ZnVuY3Rpb25hbGl0eSB0byBhIHJlY2VpdmVkIHBhY2tldCBhbmQgdGhlbiByZXR1cm5zIHRoZQ0K PGJyPg0KJmd0OyBvdXRjb21lIHRvIHRoZSBTRiBSb3V0ZXIuPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7IFN1Y2ggYXMsIHRoZXJlIGlzIGEg TkFUNDQgU0Ygbm9kZSB3aXRoIHB1YmxpYyBpcHY0IGFkZHJlc3MNCnBvb2wgPGJyPg0KJmd0OyAm bmJzcDsgMTIuMy40LjAvMjQsIHRoZW4gaG93IHRvIGFkdmVydGlzZSB0aGlzIHJvdXRlIHRvIHRo ZSBsZWdhY3kNCm5ldHdvcmsgPGJyPg0KJmd0OyAmbmJzcDsgZm9yIHRoZSBpbmJvdW5kIHRyYWZm aWMgPyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgW01lZF0gSWYgeW91 ciBxdWVzdGlvbiBpcyBhYm91dCB0aGUgcm91dGVyLWJhc2VkDQptb2RlbCwgdGhlIHJvdXRpbmcg PGJyPg0KJmd0OyBhZHZlcnRpc2VtZW50IGNhbiBiZSBtYWRlIGJ5IHRoZSBTRiBSb3V0ZXIgdG8g YXR0cmFjdCBpbmNvbWluZyB0cmFmZmljLg0KPGJyPg0KJmd0OyAmbmJzcDsgVGhpcyBtYXliZSBh IGRlcGxveW1lbnQgY29uc2lkZXJhdGlvbiBuZWVkIHRvIHBvaW50IG91dC4gPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtNZWRdIFRoaXMgcG9pbnQgaXMgc3BlY2lmaWMg dG8gdGhlIFNGKE5BVCkgY2FzZS4NCkZZSSwgZHJhZnQtbGl1LTxicj4NCiZndDsgc2ZjLXVzZS1j YXNlcyB0cmllcyB0byBnZW5lcmFsaXplIHRoaXMgaXNzdWUgYXMgZm9sbG93czo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7Jm5ic3A7IG8mbmJzcDsgU29tZSBz dGF0ZWZ1bCBTRnMgKGUuZy4sDQpOQVQgb3IgZmlyZXdhbGwpIG1heSBuZWVkIHRvIHRyZWF0IGJv dGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG91dGdvaW5nIGFuZCBpbmNvbWluZw0KcGFja2V0cy4mbmJzcDsgVGhl IGRlc2lnbiBvZiBTRiBNYXBzIG11c3QgdGFrZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50byBhY2NvdW50IHN1 Y2gNCmNvbnN0cmFpbnRzLCBvdGhlcndpc2UsIHRoZSBzZXJ2aWNlIG1heSBiZTwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZGlzdHVyYmVkLiZuYnNwOw0KVGhlIHNldCBvZiBTRnMgdGhhdCBuZWVkIHRvIGJlIGludm9r ZWQgZm9yIGJvdGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpcmVjdGlvbiBpcyB1cA0KdG8gdGhlIHJlc3BvbnNp YmlsaXR5IG9mIGVhY2ggYWRtaW5pc3RyYXRpdmU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudGl0eSBvcGVyYXRp bmcNCmFuIFNGQy1lbmFibGVkIGRvbWFpbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNmY0BpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+DQo8 L2ZvbnQ+PC90dD4NCg== --=_alternative 0039620248257C8B_=-- From nobody Wed Feb 26 04:31:56 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2281A02E2 for ; Wed, 26 Feb 2014 04:31:50 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDTMVm6gur1j for ; Wed, 26 Feb 2014 04:31:44 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id E18AF1A02DF for ; Wed, 26 Feb 2014 04:31:43 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Wed, 26 Feb 2014 04:31:42 -0800 From: Ron Parker To: Shunsuke Homma Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAlJICAADdIgIAAd4eAgAAmpID//3oy0IABnfKA///POEA= Date: Wed, 26 Feb 2014 12:31:41 +0000 Message-ID: <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp> In-Reply-To: <530D9719.2090304@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/npcysFCJFL6sG9MV9eMdLJuZnlQ Cc: Chris Frederick , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 12:31:50 -0000 RXZlbiBpZiBzdWJzY3JpYmVycyBjYW4gc2VsZiBjb25maWd1cmUgdGhlaXIgc2VydmljZXMgdmlh IGEgcG9ydGFsLCB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IGNvbWJpbmF0aW9ucyB0aGF0IGFyaXNl IHdpbGwgc3RpbGwgYmUgZmluaXRlLiAgVGhhdCBpcywgaW4gYSBwb3B1bGF0aW9uIG9mIDEwMDAw MDAwMCBzdWJzY3JpYmVycywgc3VyZWx5IHNvbWUgd2lsbCBlbmQgdXAgd2l0aCBlcXVpdmFsZW50 IHNlcnZpY2VzPw0KDQogICBSb24NCg0KPiBPbiBGZWIgMjYsIDIwMTQsIGF0IDI6MjUgQU0sICJT aHVuc3VrZSBIb21tYSIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPiAN Cj4gSGkgQ2hyaXMsIFJvbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4NCj4gDQo+ IEkgdW5kZXJzdG9vZCB0aGF0IHlvdSBzYWlkLg0KPiBBbmQgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0 IHRoZSBtZXRob2QgdXNpbmcgbWV0YWRhdGEgaXMgb25lIG9mIHRoZSBtZXRob2RzIGZvciByZWNv Z25pemluZyBzdWJzY3JpYmVycy4NCj4gQnV0IHRoaXMgcHJvYmxlbSBpcyBpbXBsZW1lbnRhdGlv biBtYXR0ZXJzLCBzbyBpdCBpcyBub3QgYXQgdGhlIHN0YWdlIGZvciBkaXNjdXNzaW9uIHlldCwg SSB0aGluay4NCj4gDQo+IFdoYXQgSSB3YW50IHRvIHNheSBpcyB0aGF0IHRoZXJlIGFyZSByZXF1 ZXN0cyBmb3IgZGlzdGluY3Qgc2VydmljZXMgcGVyIHN1YnNjcmliZXIsIHNvIHRoYXQgU0ZDIGFy Y2hpdGVjdHVyZSBzaG91bGQgYmUgc2NhbGFibGUuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gU2h1 bnN1a2UNCj4gDQo+IA0KPiAoMjAxNC8wMi8yNSAyMzo0OSksIFJvbiBQYXJrZXIgd3JvdGU6DQo+ PiBFeHBhbmRpbmcgb24gQ2hyaXMnIGNvbW1lbnRzLCBJIGRvbid0IHRoaW5rIHRoZSBwcmFjdGlj YWwgbGltaXRhdGlvbnMgYXJlIHdydCB0aGUgbnVtYmVyIG9mIGZ1bGx5LXF1YWxpZmllZCA1LXR1 cGxlcywgYnV0IHJhdGhlciB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IHRyZWF0bWVudCBzZXF1ZW5j ZXMgdGhhdCBhcmlzZSBmcm9tIHRob3NlIGZsb3dzLiAgIE9mIHRoZSAxMDAncyBvZiBtaWxsaW9u cyBvZiBmbG93cyB0aGF0IG1pZ2h0IGJlIHRyYWNrZWQgYnkgYSBoaWdoIGVuZCBjbGFzc2lmaWVy LCBwZXJoYXBzIHRoZSBudW1iZXIgb2YgdW5pcXVlIHNlcXVlbmNlcyB0aGF0IGFyaXNlIGFyZSBp biB0aGUgMTAwMCdzLiAgICBJZiBhcHBseWluZyBhIGZpeGVkLWxpbmUgb3IgbW9iaWxlIHNlcnZp Y2UgcHJvdmlkZXIgcGVyc3BlY3RpdmUsIHRoZSBudW1iZXIgb2YgY2hhaW5zIHdvdWxkIGJlIHBy b3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IGVuZC10by1lbmQgc2VydmljZSBw bGFucyBvZmZlcmVkIGFuZCB0aGVuIG11bHRpcGxpZWQgYnkgdGhlIGZsb3ctYXdhcmUgc3Vic2V0 dGluZyB0aGF0IGNhbiBiZSBtYW5hZ2VkIGJ5IHRoZSBjbGFzc2lmaWVyIChpLmUuLCBzdWJzY3Jp YmVyIGlzIHN1YmplY3QgdG8gc2VydmljZSBmdW5jdGlvbiBBIHRoZW4gQiB0aGVuIEMgYnV0IEIg b25seSBuZWVkcyBUQ1AvODAgdHJhZmZpYywgQSBvbmx5IG5lZWRzIFVEUCB0cmFmZmljLCAuLi4p Lg0KPj4gDQo+PiAgICBSb24NCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0BzYW5kdmluZS5j b21dDQo+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNSwgMjAxNCA5OjQ0IEFNDQo+PiBUbzog U2h1bnN1a2UgSG9tbWE7IFJvbiBQYXJrZXINCj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFjdGlv bjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+PiANCj4+IEhpIFNo dW5zdWtlLXNhbiwNCj4+IEkgcmVjb2duaXplIHRoYXQgdWx0aW1hdGVseSwgdGhpcyBpcyBhbiBp bXBsZW1lbnRhdGlvbiBkZWNpc2lvbiBhbmQgbm90IHNvbWV0aGluZyB0byBiZSBtYW5kYXRlZCBh cyBhIGhhcmQgJ3J1bGUnLiBJIGp1c3Qgd2FudGVkIHRvIGhpZ2hsaWdodCB3aGF0IGlzIHBvc3Np YmxlICsgd2hhdCB3ZSBiZWxpZXZlIHRvIGJlIGJlc3QgcHJhY3RpY2VzIGluIHRoaXMgYXJlYSwg YmFzZWQgb24gb3VyIGV4cGVyaWVuY2UuDQo+PiBUaGF0IHNhaWQsIHllcywgSSBiZWxpZXZlIHRo YXQgaW4gcHJhY3RpY2FsIChyZWFsLXdvcmxkKSB0ZXJtcywgaXQgbWFrZXMgc2Vuc2UgdG8gZGVl bXBoYXNpemUgdGhlICcocmUpY2xhc3NpZmljYXRpb24nIHJvbGUgb2YgU0ZzIGluIG1vc3QgY2Fz ZXMsIGZvciByZWFzb25zIEkndmUgc3RhdGVkIHByZXZpb3VzbHkgKHF1ZXN0aW9ucyBvZiBtZXRh ZGF0YSBzaGFyaW5nIGJldHdlZW4gU0ZzLCBpc3N1ZXMgcmVsYXRlZCB0byByZXRhaW5pbmcgaW50 ZWdyaXR5IG9mIGNoYWlucy9icmVha2luZyBmbG93cywgZXRjLikuDQo+PiBUbyB5b3VyIGNvbW1l bnQgYWJvdXQgc2NhbGluZyB0aGUgU0ZDIENvbnRyb2xsZXIsIEkgd291bGQganVzdCBzYXkgdGhh dCB0aGVyZSBhcmUgY29tbWVyY2lhbGx5IGRlcGxveWVkIFNGQyBDb250cm9sbGVycyB0b2RheSB0 aGF0IGRvIHRoaXMsIGkuZS4gc2l0IGlubGluZSBpbiBjb25zdW1lciBuZXR3b3JrcywgcmVjZWl2 ZS9pbnNwZWN0IG1pbGxpb25zIG9mIGNvbmN1cnJlbnQgYmlkaXJlY3Rpb25hbCBmbG93cywgKyBt YWtlIHJlYWwtdGltZSBTRkMgc3RlZXJpbmcgYW5kIHNlcXVlbmNpbmcgZGVjaXNpb25zIGJhc2Vk IG9uIGZsb3csIHN1YnNjcmliZXIsIHNlc3Npb24sIGFuZCBuZXR3b3JrIGNvbmRpdGlvbnMuDQo+ PiBPYnZpb3VzbHksIGRpZmZlcmVuY2VzIGluIHZlbmRvciBjYXBhYmlsaXRpZXMsIGFzIHdlbGwg YXMgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgdml6IGNvbnNvbGlkYXRpbmcgdnMuIGRpc3RyaWJ1 dGluZyBkaWZmZXJlbnQgU0ZDIGZ1bmN0aW9ucyBsaWtlIGZsb3cgY2xhc3NpZmljYXRpb24sIFBE UC9TRkMgQ29udHJvbGxlciwgc3RlZXJpbmcvbGIsIGV0YywgYWxsIHdpbGwgaGF2ZSBhbiBpbXBh Y3QgaGVyZS4gQmVzdCwgL2MNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IFNodW5zdWtlIEhvbW1hIFttYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5q cF0NCj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE0IDc6MjUgQU0NCj4+IFRvOiBD aHJpcyBGcmVkZXJpY2s7IFJvbiBQYXJrZXINCj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlv bjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+PiANCj4+IEhpIENo cmlzLA0KPj4gDQo+PiBEbyB5b3UgbWVhbiB0aGF0LCBmb3IgcmV0YWluaW5nIGludGVncml0eSBv ZiBjaGFpbnMsIG1hbmFnZW1lbnQgb2Ygc3Vic2NyaWJlcnMgc2hvdWxkIGJlIHByb3ZpZGVkIG5v dCBieSBTRnMsIGJ1dCBieSBTRkMgY29udHJvbGxlcj8NCj4+IA0KPj4gSWYgc28sIHRoZSBwcm9i bGVtIGlzIHRoYXQgdGhlIG51bWJlciBvZiBjaGFpbnMgdGhhdCBTRkMgY29udHJvbGxlciBtdXN0 IG1hbmFnZSBpcyBsYXJnZSwgYW5kIGl0IGlzIHRoZSBzYW1lIHByb2JsZW0gSSBzYWlkLCBJIHRo aW5rLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBTaHVuc3VrZQ0KPj4gDQo+PiAoMjAxNC8w Mi8yNSAxNDoxNyksIENocmlzIEZyZWRlcmljayB3cm90ZToNCj4+PiBIaSBTaHVuc3VrZS1zYW4s DQo+Pj4gSSBhY2tub3dsZWRnZSB0aGUgY29tbWVudHMgYWJvdXQgdGhlc2UgYmVpbmcgaW1wbGVt ZW50YXRpb24gbWF0dGVycywNCj4+PiBidXQgSSd2ZSBvZmZlcmVkIHNvbWUgdGhvdWdodHMgaW5s aW5lIHdpdGggeW91ciBtYWlsIGJlbG93LiBUaHgsIC9jDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBTaHVuc3VrZSBIb21tYSBbbWFpbHRvOmhvbW1hLnNo dW5zdWtlQGxhYi5udHQuY28uanBdDQo+Pj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAx NCA5OjAwIFBNDQo+Pj4gVG86IENocmlzIEZyZWRlcmljazsgUm9uIFBhcmtlcg0KPj4+IENjOiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBS ZTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJl bWVudHMtMDMudHh0DQo+Pj4gDQo+Pj4gSGkgUm9uLCBDaHJpcywNCj4+PiANCj4+PiBUaGFuayB5 b3UgZm9yIHlvdXIgcmVwbHkuDQo+Pj4gDQo+Pj4gSSB0aGluayB0aGF0IHlvdXIgcG9pbnRzIGFy ZSBmb2xsb3dpbmc6DQo+Pj4gaW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBhcyB1c2Vy IGN1c3RvbWl6ZWQsIHBlci1zdWJzY3JpYmVyIFNGQ3Mgc2hvdWxkbid0IGJlIG1hZGUsIGJ1dCB0 aGUgU0ZzIHNob3VsZCByZWNvZ25pemUgc3Vic2NyaWJlcnMgYnkgSVAgYWRkcmVzcyBvciBtZXRh ZGF0YS4NCj4+PiBDRj4+IE15IHBvaW50IHdhcyB0aGF0IEkgZG9uJ3Qgc2VlIGl0IGFzIGRlc2ly YWJsZSB0byBoYXZlIHNwZWNpZmljIHBlci1zdWJzY3JpYmVyIFNGQyBydWxlcyAoYXMgaW4gc3Rh dGljIHJ1bGVzLCBsaWtlIHN1YnNjcmliZXJfQ2hyaXM9U0ZDX2FfYl9jKSwgd2l0aCBhIHJ1bGUg Zm9yIGV2ZXJ5IHN1YiwgaW4gdGhhdCBzZW5zZS4gQmV0dGVyIGlzIGEgc2NlbmFyaW8gd2hlcmUg dGhlIFNGQyBjaGFpbiBjb250cm9sbGVyIGlzIHN1YnNjcmliZXItYXdhcmUgKyBhYmxlIHRvIGV2 YWx1YXRlIG11bHRpcGxlIG9ydGhvZ29uYWwgZmxvdyArIHN1YnNjcmliZXIgY29uZGl0aW9ucyBp biByZWFsIHRpbWUsIGFuZCBmb3JtdWxhdGUgYSBjaGFpbiBvbiB0aGUgYmFzaXMgb2YgdGhvc2Ug ZHluYW1pYyBjb25kaXRpb25zLg0KPj4+IA0KPj4+IE9mIGNvdXJzZSwgaXQgaXMgb25lIG9mIHRo ZSBzb2x1dGlvbnMuDQo+Pj4gSG93ZXZlciwgaW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoYXQgU0Zz IGFzIHVzZXIgY3VzdG9taXplZCBtaWdodCBiZSByZXF1aXJlZCB0byBoYXZlIGEgZnVuY3Rpb24g dG8gcmVjb2duaXplIGVhY2ggc3Vic2NyaWJlci4NCj4+PiBDRj4+IEkgd2Fzbid0IGFjdHVhbGx5 IHRoaW5raW5nIGluIHRlcm1zIG9mIFNGIChyZSljbGFzc2lmaWNhdGlvbjsgSSd2ZSBwcmV2aW91 c2x5IGNvbW1lbnRlZCBvbiB3aHkgSSB0aGluayB0aGF0IGlkZWEgaXMgc29tZXdoYXQgZnJhdWdo dCAoaS5lLiBiZWNhdXNlIG1vZGlmaWNhdGlvbiBvZiB0aGUgZmxvdyBwYXRoIGJ5IGEgc2Vydmlj ZSBmdW5jdGlvbiB3aXRoaW4gdGhlIGNoYWluIGNvdWxkIHJlc3VsdCBpbiBhICdicmVha2luZycg b2YgdGhlIGNoYWluIG9yIGZsb3cuIElmIHRoZXJlIGlzIG5vdCBiaWRpcmVjdGlvbmFsIHN5bW1l dHJ5IGluIHRoZSBmbG93IGFuZCBzZXJ2aWNlIGZ1bmN0aW9uIGVsZW1lbnRzIGluIHRoZSBjaGFp biBjYW4gbWFrZSByb3V0aW5nIGRlY2lzaW9ucywgdGhlbiB0aGVyZSdzIHNvbWUgbWV0YWRhdGEg Y29ycmVsYXRpb24gdG8gd29yayBvdXQsIGF0IG1pbmltdW0pLiBJIGRvIGFncmVlIHRoYXQgdGhl IFNGQyBjaGFpbiBjb250cm9sbGVyIHdvdWxkIG5lZWQgdG8gYmUgc3Vic2NyaWJlci1hd2FyZSB0 aG91Z2guDQo+Pj4gDQo+Pj4gT24gdGhlIG90aGVyIGhhbmQsIEkgdGhpbmsgdGhhdCB0aGVyZSBh cmUgY2FzZXMgd2hlbiB0aGUgZnVuY3Rpb24gY2FuJ3QgYmUgYWRvcHRlZCwgc3VjaCBsaWtlIFNG cyBhcmUgY3VycmVudCBlcXVpcG1lbnQgdGhhdCBkb24ndCBoYXZlIGZ1bmN0aW9uIHRvIHJlY29n bml6ZSBtZXRhZGF0YS4NCj4+PiBDRj4+IEFncmVlZC4gVGhpcyBzcGVha3MgdG8gbXkgY29tbWVu dCBhYm92ZSArIHRvIHRoZSBhZHZhbnRhZ2VzIHNvbWUgb2YgdXMgaGF2ZSBtZW50aW9uZWQgdml6 IGEgY29uc29saWRhdGVkIHBvbGljeS1iYXNlZCBzdGVlcmluZy9QRFAvU0ZDIGNoYWluIGNvbnRy b2xsZXIgZW50aXR5Lg0KPj4+IA0KPj4+IEhvdyBkbyB3ZSBoYW5kbGUgdGhlc2UgY2FzZXM/DQo+ Pj4gQW55IG5ldyBwcm9ibGVtcyBvciByZXF1aXJlbWVudHMgbWF5IG9jY3VyPw0KPj4+IA0KPj4+ IHJlZ2FyZHMsDQo+Pj4gDQo+Pj4gU2h1bnN1a2UNCj4+PiANCj4+PiAoMjAxNC8wMi8yNSA4OjQ2 KSwgQ2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPj4+PiBZZXMsIGFncmVlZCBvbiB0aGF0Lg0KPj4+ PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogUm9uIFBhcmtl ciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+Pj4+IFNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNjo0NSBQTQ0KPj4+PiBUbzogQ2hyaXMgRnJlZGVyaWNr OyDmnKzplpPkv4rku4sNCj4+Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNm Y0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+Pj4+ IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+PiANCj4+Pj4gVGhh bmtzLCBDaHJpcy4NCj4+Pj4gDQo+Pj4+IEkgZG8gdGhpbmsgdGhlcmUgYXJlIGxvdHMgb2YgZWZm aWNpZW5jaWVzIHdoZW4gdGhlIGZsb3cgbGVhcm5lciAoY2xhc3NpZmllcikgYW5kIHBvbGljeSBl dmFsdWF0b3IgKFBEUCkgYXJlIGNvLWxvY2F0ZWQuICAgSG93ZXZlciwgYXJjaGl0ZWN0dXJhbGx5 LCBJIHdvdWxkbid0IG1hbmRhdGUgdGhhdCB0aGV5IGJlIGNvLWxvY2F0ZWQuDQo+Pj4+IA0KPj4+ PiAgICAgICBSb24NCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+PiBGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNrQHNhbmR2aW5l LmNvbV0NCj4+Pj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1OjI2IFBNDQo+Pj4+ IFRvOiBSb24gUGFya2VyOyDmnKzplpPkv4rku4sNCj4+Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEkt RCBBY3Rpb246DQo+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0K Pj4+PiANCj4+Pj4gQWdyZWVkLg0KPj4+PiBUbyByZXN0YXRlIHRoaXMgc2xpZ2h0bHksIGlmIHRo ZSBTRkMgc3RlZXJpbmcvZGVjaXNpb24gbG9jdXMgaXMgY2FwYWJsZSBvZiBldmFsdWF0aW5nIG11 bHRpcGxlIG9ydGhvZ29uYWwgcG9saWN5IGNvbmRpdGlvbnMgdGhlbiB0aGlzIGlzc3VlIGlzIG9i dmlhdGVkOyBzdWJzY3JpYmVycyBiZWNvbWUgYW4gYWdncmVnYXRlIG9mICd3aGF0IHRoZXkgYXJl JyArIGFyZSBub3Qgc2ltcGx5ICd3aG8gdGhleSBhcmUnLg0KPj4+PiBBcyBSb24gc3RhdGVzLCB0 aGlzIGF3YXJlbmVzcyBtYXkgYmUgZGVyaXZlZCBmcm9tIExEQVAgbG9va3VwLCBSQURJVVMsIEd4 LCBwcmUtcHJvdmlzaW9uZWQgcnVsZXMsIGV0Yy4NCj4+Pj4gVG8gaWxsdXN0cmF0ZSB3LyBhbiBl eGFtcGxlLCB3ZSBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4+Pj4gSWYgc3Vic2Ny aWJlciBYIGlzIHVzaW5nIHlvdXR1YmUsIGFuZCBpcyBvbiBhIGNvbmdlc3RlZCBjZWxsLCBhbmQg aXMgb24gYW4gaVBob25lLCBhbmQgaXMgaW4gdGhlICJHb2xkIFRpZXIiLCBhbmQsIGFuZCwgYW5k LCBhbmQsIGV0YywgdGhlbiB0aGUgY2hhaW4gY29uc2lzdHMgb2Ygc2VydmljZSBmdW5jdGlvbnMg YSwgYiwgYW5kIGMuDQo+Pj4+IFRoZXJlJ3Mgbm8gbmVlZCB0byBlbnRlciBhIHN0YXRpYyBTRkMg cnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChvciBhbnkgc3Vic2NyaWJlcikuIEluIGZhY3Qs IGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVjYXVzZSBhbGwgb2YgdGhlIGFib3ZlIGNvbmRp dGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNhdmUgb25lICgiaXMgb24gYSBjb25nZXN0ZWQg Y2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFpbiBtaWdodCBiZSBhbHRlcmVkIChwZXJoYXBz IHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlvbiBzZXJ2aWNlIGZ1bmN0aW9uKS4NCj4+Pj4g VGhpcyBhbHNvIGdvZXMgdG8gdGhlIGVhcmxpZXIgY29tbWVudHMgUm9uICsgSSBtYWRlIGFib3V0 DQo+Pj4+IGNvbnNvbGlkYXRpbmcgdGhlIGZsb3cgcmVjb2duaXRpb24gKyBkZWNpc2lvbi1tYWtp bmcgZW50aXR5IGluIGENCj4+Pj4gc2luZ2xlIChzdWl0YWJseSBwb2xpY3ktYXdhcmUpIG5vZGUg dG8gcmVkdWNlIHRoZSBjb21wbGV4aXR5ICsgdG8NCj4+Pj4gc2NhbGUgcHJvcGVybHkuIFRoeCwg L2MNCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0K Pj4+PiBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDIzLCAyMDE0IDEwOjM5IFBNDQo+Pj4+IFRvOiDm nKzplpPkv4rku4sNCj4+Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+Pj4+IGRy YWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+PiANCj4+Pj4gU2h1bnN1 a2Utc2FuLA0KPj4+PiANCj4+Pj4gV2hpbGUgYSB0aGVvcmV0aWNhbCBjYXNlIGNhbiBiZSBtYWRl IGZvciBvbmUgb3IgbW9yZSBTRkNzIHBlciBzdWJzY3JpYmVyLCBmb3IgcmVhc29ucyB5b3Ugc3Rh dGUsIGl0IGlzbid0IHByYWN0aWNhbC4gIEJ1dCwgdGhlcmUgaXMgYW5vdGhlciB3YXkgdG8gdmll dyB0aGlzIGFzcGVjdCBvZiB0aGUgcHJvYmxlbS4gIExldCdzIHRha2UgeW91ciBwZXItc3Vic2Ny aWJlciBjdXN0b21pemVkIGZpcmV3YWxsIGFzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuICBJZiB0 aGVyZSB3ZXJlIG9ubHkgb25lIGZpcmV3YWxsLCBpbnN0ZWFkLCBhbmQgaXQgd2FzIGNhcGFibGUg b2YgbG9jYWwgcG9saWN5IGV2YWx1YXRpb24gYmFzZWQgb24gc3Vic2NyaWJlciwgdGhlIG51bWJl ciBvZiBTRkNzIHdvdWxkIGJlIHZhc3RseSByZWR1Y2VkLiAgIE9uZSB3YXkgZm9yIHRoYXQgdG8g aGFwcGVuIHdvdWxkIGJlIHRvIHNpbXBseSB1c2UgdGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBJUCBh ZGRyZXNzIGZyb20gdGhlIHBhY2tldCBhbmQgc29tZSBvdXQgb2YgYmFuZCBsb29rdXAgbWVjaGFu aXNtIGxpa2UgTERBUCBvciBSQURJVVMgYXQgdGhlIGZpcmV3YWxsLiAgICBBbm90aGVyIGFwcHJv YWNoIHRvIGRldGVybWluZSB3aG8gdGhlIHN1YnNjcmliZXIgaXMgd291bGQgYmUgZm9yIHRoZSBT RkMgY2xhc3NpZmllciB0byBhZGQgYSBkaXN0aW5jdCBzdWJzY3JpYmVyIGlkIGFzIG1ldGFkYXRh IHRvIHRoZSBzZXJ2aWNlIGhlYWRlciAoZWcsIGFuIElNU0kpIGFuZCBzdGlsbCB1c2UgTERBUCwg ZXRjLiBhdCB0aGUgZmlyZXdhbGwuDQo+Pj4+IA0KPj4+PiBJZiB0aGUgcHJvYmxlbSBpcyBjaGFu Z2VkIHNsaWdodGx5IHNvIHRoYXQgdGhlIGZpcmV3YWxsIHBvbGljeSBpcyBwZXIgZ3JvdXAgb2Yg c3Vic2NyaWJlcnMsIHdoZXJlIHRoZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4g eWV0IGFub3RoZXIgYXBwcm9hY2ggaXMgdG8gbW9kZWwgdGhlIGZpcmV3YWxsIGFzIGEgZGlzdGlu Y3QgbG9naWNhbCBmaXJld2FsbCBwZXIgZmlyZXdhbGwgcG9saWN5IHNldCAodGhleSBjb3VsZCBh bGwgcmVzaWRlIGluIHRoZSBzYW1lIG1hY2hpbmUgb3IgVk0pIGFuZCB0byBjb29yZGluYXRlIHRo ZSBjbGFzc2lmaWVyJ3MgcG9saWN5IGFjY29yZGluZ2x5Lg0KPj4+PiANCj4+Pj4gICAgICBSb24N Cj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDowNCBQTSwgIuacrOmW k+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPj4+Pj4gDQo+ Pj4+PiBIaSBNZWQsDQo+Pj4+PiANCj4+Pj4+IEluIHRlcm1zIG9mIHlvdXIgY29tbWVudCwgSSBh c3N1bWVkIHNvbWUgdXNlIGNhc2VzIGFib3V0IHNjYWxhYmlsaXR5IHNvIHRoYXQgd2UgY2FuIGNv bnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFib3V0IHNjYWxhYmlsaXR5IGNvbnNpZGVyYXRpb25zLg0K Pj4+Pj4gI0kgd29yayB3aXRoIEsuTmFpdG8sIGNvLWF1dGhvciBvZiByZXF1aXJlbWVudCBkcmFm dCBhbmQgdGhpbmsgc2NhbGFiaWxpdHkgaXMgb25lIG9mIGltcG9ydGFudCB0aGluZ3MgdG8gY29u c2lkZXIuDQo+Pj4+PiANCj4+Pj4+IEFzc3VtaW5nIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGZvbGxv d2luZywgdGhlIG1hbmFnZW1lbnQgbWVjaGFuaXNtIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5z IG1pZ2h0IHJlcXVpcmUgaGlnaCBzY2FsYWJpbGl0eS4NCj4+Pj4+IA0KPj4+Pj4gMS4gVGhlIGNh c2UgdGhhdCB0aGUgdHlwZXMgb2YgU0YgaW5jcmVhc2U6DQo+Pj4+PiBJIGFzc3VtZWQgdGhhdCB0 aGUgdW5pdCBvZiBhcHBseWluZyBTRkMgdG8gdHJhZmZpYyBpcyBmb2xsb3dpbmc7DQo+Pj4+PiAg ICAtIGdyb3VwaW5nOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVh Y2ggc2VydmljZSwNCj4+Pj4+ICAgICAgZW50ZXJwcmlzZSBjdXN0b21lciBvciByZWdpb24sDQo+ Pj4+PiAgICAtIHBlci1zdWJzY3JpYmVyOiB0cmFmZmljIGlzIGFwcGxpZWQgd2l0aCBzcGVjaWZp YyBTRkMgZm9yIGVhY2jjgIANCj4+Pj4+ICAgICAgc3Vic2NyaWJlciAoZS5nLiBwZXIgSVAgYWRk cmVzcywgVkxBTiBJRCBldC5hbCksDQo+Pj4+PiAgICAtIHBlci1mbG93OiB0cmFmZmljIGlzIGFw cGxpZWQgd2l0aCBzcGVjaWZpYyBTRkMgZm9yIGVhY2ggc3Vic2NyaWJlciwNCj4+Pj4+IOOAgOOA gGFuZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0KPj4+Pj4g DQo+Pj4+PiBTb21lIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBoYXZlIGVub3Jtb3VzIG51bWJl ciBvZiBzdWJzY3JpYmVycywgYW5kIHRoZSBudW1iZXIgb2Ygc3Vic2NyaWJlcnMgaXMgdXAgdG8g c2V2ZXJhbCB0ZW5zIG9yIGh1bmRyZWRzIG9mIG1pbGxpb24uIFRoZXJlZm9yZSwgaW4gY2FzZXMg b2YgcGVyLXN1YnNjcmliZXIgYW5kIHBlci1mbG93LCB0aGUgbnVtYmVyIG9mIFNGQ3MgbWlnaHQg aW5jcmVhc2UgZXhwbG9zaXZlbHkuIFBlci1zdWJzY3JpYmVyIFNGQ3Mgd291bGQgYmUgbmVlZGVk IGluIHRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIGRlZGljYXRlZCB0byBlYWNoIHVz ZXIoZS5nLiB2Q1BFIGFzIHVzZXIgY3VzdG9taXplZCkuDQo+Pj4+PiANCj4+Pj4+IEFsc28sIGlu IGNhc2Ugb2YgZ3JvdXBpbmcsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hvc2UgcG9s aWNpZXMgYXJlIGRpZmZlcmVudCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21lciBhbmQg cGVyIHJlZ2lvbiwgdGhlIG51bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcuIEZpcmV3 YWxscyBoYXZlIGRpZmZlcmVudCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0b21lciku DQo+Pj4+PiANCj4+Pj4+IDIuIFRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIHRoYXQg bXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlOg0KPj4+Pj4gSW4gY2FzZSB0aGF0 IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBmdW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQg dGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5h dGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+Pj4+PiBUaGUgU0ZzIHRoYXQgcHJvY2VzcyBz dGF0ZWZ1bCB0cmFmZmljIGFyZSBuZWVkZWQgdG8gYmUgZGlmZmVyZW50aWF0ZWQgcGVyIGluc3Rh bmNlIChlLmcuIEZpcmV3YWxsLCBDb250ZW50cy1DYWNoZSwgYW5kIFZpZGVvLU9wdGltaXplciku DQo+Pj4+PiANCj4+Pj4+IElNSE8scmVxdWlyZW1lbnRzIGZvciBzY2FsYWJpbGl0eSB3aWxsIGFm ZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIgZm9ybWF0Lg0KPj4+Pj4gDQo+Pj4+PiBU aGFua3MsDQo+Pj4+PiANCj4+Pj4+IFNodW5zdWtlDQo+Pj4+PiANCj4+Pj4+ICgyMDE0LzAyLzEy IDE4OjQ5KSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4+PiBEZWFy IGFsbCwNCj4+Pj4+PiANCj4+Pj4+PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRz IGZyb20gTlRUIHJlcHJlc2VudGF0aXZlcy4NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgZGlmZiBjYW4g YmUgdHJhY2tlZCBoZXJlOg0KPj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwx PWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTANCj4+Pj4+PiAxDQo+Pj4+Pj4gJg0K Pj4+Pj4+IGRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNm Yy1yZXF1aXJlbWVudHMtMDMNCj4+Pj4+PiANCj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4gTWVkDQo+ Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+Pj4gRGUgOiBJ LUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydA0KPj4+Pj4+IGRlIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3Jl ZGkgMTIgZsOpdnJpZXIgMjAxNCAxMDo0Ng0KPj4+Pj4+IMOADQo+Pj4+Pj4gOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0KPj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1z ZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAgICAgICAgICAgVGl0bGUg ICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nDQo+ Pj4+Pj4gICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQNCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcNCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtlcg0KPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDYXJsb3MgUGlnbmF0YXJvDQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEtlbmdvIE5haXRvDQo+Pj4+Pj4gICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+PiAgICAgIFBhZ2VzICAg ICAgICAgICA6IDE0DQo+Pj4+Pj4gICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAyLTEyDQo+ Pj4+Pj4gDQo+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4gICAgICBUaGlzIGRvY3VtZW50IGlkZW50 aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+Pj4+PiAg ICAgIENoYWluaW5nIChTRkMpLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVx dWlyZW1lbnRzLw0KPj4+Pj4+IA0KPj4+Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+Pj4+Pj4gDQo+Pj4+Pj4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRz LTANCj4+Pj4+PiAzDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4+PiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBJLUQtQW5ub3VuY2UgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+Pj4+PiBJbnRlcm5l dC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0K Pj4+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+Pj4+Pj4g DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiAtLQ0KPj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCj4+Pj4+IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0KPj4+Pj4gDQo+Pj4+PiDm l6XmnKzpm7vkv6Hpm7voqbHmoKrlvI/kvJrnpL4NCj4+Pj4+IOODjeODg+ODiOODr+ODvOOCr+OC teODvOODk+OCueOCt+OCueODhuODoOeglOeptuaJgA0KPj4+Pj4g6Lui6YCB44K144O844OT44K5 5Z+655uk44OX44Ot44K444Kn44Kv44OIDQo+Pj4+PiDou6LpgIHjgrXjg7zjg5PjgrnliLblvqFE UA0KPj4+Pj4gDQo+Pj4+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiUtemHjuW4gue3keeU ujMtOS0xMQ0KPj4+Pj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4+Pj4+IEUtTUFJTDogaG9tbWEuc2h1 bnN1a2VAbGFiLm50dC5jby5qcA0KPj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0Bp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBz ZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IC0tDQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFNodW5zdWtlIEhvbW1hDQo+Pj4gPGhvbW1hLnNodW5z dWtlQGxhYi5udHQuY28uanA+DQo+Pj4gVEVMOiArODEgMDQyMiA1OSAzNDg2DQo+Pj4gRkFYOiAr ODEgMDQyMiA2MCA3NDYwDQo+Pj4gDQo+Pj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0gTGFi cy4NCj4+PiBNdXNhc2hpbm8gY2l0eSwgVG9reW8sIEphcGFuDQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gDQo+Pj4g DQo+PiANCj4+IA0KPj4gLS0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+IFNodW5zdWtlIEhvbW1hDQo+PiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+ IFRFTDogKzgxIDA0MjIgNTkgMzQ4Ng0KPj4gRkFYOiArODEgMDQyMiA2MCA3NDYwDQo+PiANCj4+ IE5UVCBOZXR3b3JrIFNlcnZpY2UgU3lzdGVtIExhYnMuDQo+PiBNdXNhc2hpbm8gY2l0eSwgVG9r eW8sIEphcGFuDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxp bmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPj4gDQo+PiANCj4gDQo+IA0KPiAtLSANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBTaHVuc3VrZSBIb21tYQ0KPiA8aG9tbWEuc2h1bnN1a2VA bGFiLm50dC5jby5qcD4NCj4gVEVMOiArODEgMDQyMiA1OSAzNDg2DQo+IEZBWDogKzgxIDA0MjIg NjAgNzQ2MA0KPiANCj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4gTXVzYXNo aW5vIGNpdHksIFRva3lvLCBKYXBhbg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo= From nobody Wed Feb 26 06:42:36 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F4E1A0393 for ; Wed, 26 Feb 2014 06:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-JANzi1DRN0 for ; Wed, 26 Feb 2014 06:42:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 173271A0390 for ; Wed, 26 Feb 2014 06:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24234; q=dns/txt; s=iport; t=1393425742; x=1394635342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QPa1/LYo18NOqE3uuSoCxZJX7ylcTp7GsGm00kxqxjo=; b=g/HE0+b1VbO4Boa3Ga6GZbjMXCdZ0EW4PDisndJULWUoUJ3kwglABEwd g7QCB/m7Xp+9etDKx/8CsgyTOTqVMrijqO+9rPvEhQmndYLaakTatCl/h 7JuvuSKAP+6BDuEaldbWK5glBvbGq2OpYy4rnfR3uXenQ0IkfjTthymkN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAFP8DVOtJXG//2dsb2JhbABagwY7UYMJvW8YgQIWdIInAQEBAwEBAQEgEToGBQUHBAIBBgIRAQMBAQECAiMDAgICJQsUAQIGCAIEDgUJEodWCAgFjBecB6EDF4EpjFoBARwIEBsHBAKCaDWBFASYNoEyizKFRIMtgXE X-IronPort-AV: E=Sophos;i="4.97,548,1389744000"; d="scan'208";a="306650298" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2014 14:42:21 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1QEgKd8014243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 14:42:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 08:42:20 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0mB55qmIXvGECzMQp245pSWprEJmeAgAE6xICAABZGAIAAAGGAgAAlJICAADdIgIAAd4eAgAAmpICAAAHAgIABFmSAgABVVID//7/sHw== Date: Wed, 26 Feb 2014 14:42:20 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> In-Reply-To: <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ynCmhwWd6btUNwpVQWjjx2nuhkE Cc: Chris Frederick , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 14:42:31 -0000 UmlnaHQgYW5kIHRoZSBwb2ludCBiZWluZyB3aGF0IHlvdSB3YW50IHRvIGRvIGlzIHNoYXJlIFNG Q3MgYWNyb3NzIHN1YnNjcmliZXJzIGFuZCBpbXBsZW1lbnQgd2l0aGluIHRoZSBTRkMgYW55IGRp ZmZlcmVudGlhdGlvbiBpbiB0ZXJtcyBvZiBwb2xpY3kgZm9yIHN1YnNjcmliZXJzIHRoYXQgY29u c3VtZSB0aGUgc2FtZSBzZXQgb2Ygc2VydmljZXMuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0K PiBPbiBGZWIgMjYsIDIwMTQsIGF0IDc6MzIgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBFdmVuIGlmIHN1YnNjcmliZXJzIGNh biBzZWxmIGNvbmZpZ3VyZSB0aGVpciBzZXJ2aWNlcyB2aWEgYSBwb3J0YWwsIHRoZSBudW1iZXIg b2YgZGlzdGluY3QgY29tYmluYXRpb25zIHRoYXQgYXJpc2Ugd2lsbCBzdGlsbCBiZSBmaW5pdGUu ICBUaGF0IGlzLCBpbiBhIHBvcHVsYXRpb24gb2YgMTAwMDAwMDAwIHN1YnNjcmliZXJzLCBzdXJl bHkgc29tZSB3aWxsIGVuZCB1cCB3aXRoIGVxdWl2YWxlbnQgc2VydmljZXM/DQo+IA0KPiAgIFJv bg0KPiANCj4+IE9uIEZlYiAyNiwgMjAxNCwgYXQgMjoyNSBBTSwgIlNodW5zdWtlIEhvbW1hIiA8 aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4gd3JvdGU6DQo+PiANCj4+IEhpIENocmlzLCBS b24sDQo+PiANCj4+IFRoYW5rIHlvdSBmb3IgeW91ciByZXBseS4NCj4+IA0KPj4gSSB1bmRlcnN0 b29kIHRoYXQgeW91IHNhaWQuDQo+PiBBbmQgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBtZXRo b2QgdXNpbmcgbWV0YWRhdGEgaXMgb25lIG9mIHRoZSBtZXRob2RzIGZvciByZWNvZ25pemluZyBz dWJzY3JpYmVycy4NCj4+IEJ1dCB0aGlzIHByb2JsZW0gaXMgaW1wbGVtZW50YXRpb24gbWF0dGVy cywgc28gaXQgaXMgbm90IGF0IHRoZSBzdGFnZSBmb3IgZGlzY3Vzc2lvbiB5ZXQsIEkgdGhpbmsu DQo+PiANCj4+IFdoYXQgSSB3YW50IHRvIHNheSBpcyB0aGF0IHRoZXJlIGFyZSByZXF1ZXN0cyBm b3IgZGlzdGluY3Qgc2VydmljZXMgcGVyIHN1YnNjcmliZXIsIHNvIHRoYXQgU0ZDIGFyY2hpdGVj dHVyZSBzaG91bGQgYmUgc2NhbGFibGUuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IFNodW5z dWtlDQo+PiANCj4+IA0KPj4gKDIwMTQvMDIvMjUgMjM6NDkpLCBSb24gUGFya2VyIHdyb3RlOg0K Pj4+IEV4cGFuZGluZyBvbiBDaHJpcycgY29tbWVudHMsIEkgZG9uJ3QgdGhpbmsgdGhlIHByYWN0 aWNhbCBsaW1pdGF0aW9ucyBhcmUgd3J0IHRoZSBudW1iZXIgb2YgZnVsbHktcXVhbGlmaWVkIDUt dHVwbGVzLCBidXQgcmF0aGVyIHRoZSBudW1iZXIgb2YgZGlzdGluY3QgdHJlYXRtZW50IHNlcXVl bmNlcyB0aGF0IGFyaXNlIGZyb20gdGhvc2UgZmxvd3MuICAgT2YgdGhlIDEwMCdzIG9mIG1pbGxp b25zIG9mIGZsb3dzIHRoYXQgbWlnaHQgYmUgdHJhY2tlZCBieSBhIGhpZ2ggZW5kIGNsYXNzaWZp ZXIsIHBlcmhhcHMgdGhlIG51bWJlciBvZiB1bmlxdWUgc2VxdWVuY2VzIHRoYXQgYXJpc2UgYXJl IGluIHRoZSAxMDAwJ3MuICAgIElmIGFwcGx5aW5nIGEgZml4ZWQtbGluZSBvciBtb2JpbGUgc2Vy dmljZSBwcm92aWRlciBwZXJzcGVjdGl2ZSwgdGhlIG51bWJlciBvZiBjaGFpbnMgd291bGQgYmUg cHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgZGlzdGluY3QgZW5kLXRvLWVuZCBzZXJ2aWNl IHBsYW5zIG9mZmVyZWQgYW5kIHRoZW4gbXVsdGlwbGllZCBieSB0aGUgZmxvdy1hd2FyZSBzdWJz ZXR0aW5nIHRoYXQgY2FuIGJlIG1hbmFnZWQgYnkgdGhlIGNsYXNzaWZpZXIgKGkuZS4sIHN1YnNj cmliZXIgaXMgc3ViamVjdCB0byBzZXJ2aWNlIGZ1bmN0aW9uIEEgdGhlbiBCIHRoZW4gQyBidXQg QiBvbmx5IG5lZWRzIFRDUC84MCB0cmFmZmljLCBBIG9ubHkgbmVlZHMgVURQIHRyYWZmaWMsIC4u LikuDQo+Pj4gDQo+Pj4gICBSb24NCj4+PiANCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+IEZyb206IENocmlzIEZyZWRlcmljayBbbWFpbHRvOmNmcmVkZXJpY2tAc2Fu ZHZpbmUuY29tXQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE0IDk6NDQgQU0N Cj4+PiBUbzogU2h1bnN1a2UgSG9tbWE7IFJvbiBQYXJrZXINCj4+PiBDYzogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6IFtzZmNdIFRS OiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+ PiANCj4+PiBIaSBTaHVuc3VrZS1zYW4sDQo+Pj4gSSByZWNvZ25pemUgdGhhdCB1bHRpbWF0ZWx5 LCB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIGFuZCBub3Qgc29tZXRoaW5nIHRv IGJlIG1hbmRhdGVkIGFzIGEgaGFyZCAncnVsZScuIEkganVzdCB3YW50ZWQgdG8gaGlnaGxpZ2h0 IHdoYXQgaXMgcG9zc2libGUgKyB3aGF0IHdlIGJlbGlldmUgdG8gYmUgYmVzdCBwcmFjdGljZXMg aW4gdGhpcyBhcmVhLCBiYXNlZCBvbiBvdXIgZXhwZXJpZW5jZS4NCj4+PiBUaGF0IHNhaWQsIHll cywgSSBiZWxpZXZlIHRoYXQgaW4gcHJhY3RpY2FsIChyZWFsLXdvcmxkKSB0ZXJtcywgaXQgbWFr ZXMgc2Vuc2UgdG8gZGVlbXBoYXNpemUgdGhlICcocmUpY2xhc3NpZmljYXRpb24nIHJvbGUgb2Yg U0ZzIGluIG1vc3QgY2FzZXMsIGZvciByZWFzb25zIEkndmUgc3RhdGVkIHByZXZpb3VzbHkgKHF1 ZXN0aW9ucyBvZiBtZXRhZGF0YSBzaGFyaW5nIGJldHdlZW4gU0ZzLCBpc3N1ZXMgcmVsYXRlZCB0 byByZXRhaW5pbmcgaW50ZWdyaXR5IG9mIGNoYWlucy9icmVha2luZyBmbG93cywgZXRjLikuDQo+ Pj4gVG8geW91ciBjb21tZW50IGFib3V0IHNjYWxpbmcgdGhlIFNGQyBDb250cm9sbGVyLCBJIHdv dWxkIGp1c3Qgc2F5IHRoYXQgdGhlcmUgYXJlIGNvbW1lcmNpYWxseSBkZXBsb3llZCBTRkMgQ29u dHJvbGxlcnMgdG9kYXkgdGhhdCBkbyB0aGlzLCBpLmUuIHNpdCBpbmxpbmUgaW4gY29uc3VtZXIg bmV0d29ya3MsIHJlY2VpdmUvaW5zcGVjdCBtaWxsaW9ucyBvZiBjb25jdXJyZW50IGJpZGlyZWN0 aW9uYWwgZmxvd3MsICsgbWFrZSByZWFsLXRpbWUgU0ZDIHN0ZWVyaW5nIGFuZCBzZXF1ZW5jaW5n IGRlY2lzaW9ucyBiYXNlZCBvbiBmbG93LCBzdWJzY3JpYmVyLCBzZXNzaW9uLCBhbmQgbmV0d29y ayBjb25kaXRpb25zLg0KPj4+IE9idmlvdXNseSwgZGlmZmVyZW5jZXMgaW4gdmVuZG9yIGNhcGFi aWxpdGllcywgYXMgd2VsbCBhcyBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucyB2aXogY29uc29saWRh dGluZyB2cy4gZGlzdHJpYnV0aW5nIGRpZmZlcmVudCBTRkMgZnVuY3Rpb25zIGxpa2UgZmxvdyBj bGFzc2lmaWNhdGlvbiwgUERQL1NGQyBDb250cm9sbGVyLCBzdGVlcmluZy9sYiwgZXRjLCBhbGwg d2lsbCBoYXZlIGFuIGltcGFjdCBoZXJlLiBCZXN0LCAvYw0KPj4+IA0KPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogU2h1bnN1a2UgSG9tbWEgW21haWx0bzpob21tYS5z aHVuc3VrZUBsYWIubnR0LmNvLmpwXQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI1LCAy MDE0IDc6MjUgQU0NCj4+PiBUbzogQ2hyaXMgRnJlZGVyaWNrOyBSb24gUGFya2VyDQo+Pj4gQ2M6 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVu dHMtMDMudHh0DQo+Pj4gDQo+Pj4gSGkgQ2hyaXMsDQo+Pj4gDQo+Pj4gRG8geW91IG1lYW4gdGhh dCwgZm9yIHJldGFpbmluZyBpbnRlZ3JpdHkgb2YgY2hhaW5zLCBtYW5hZ2VtZW50IG9mIHN1YnNj cmliZXJzIHNob3VsZCBiZSBwcm92aWRlZCBub3QgYnkgU0ZzLCBidXQgYnkgU0ZDIGNvbnRyb2xs ZXI/DQo+Pj4gDQo+Pj4gSWYgc28sIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG51bWJlciBvZiBj aGFpbnMgdGhhdCBTRkMgY29udHJvbGxlciBtdXN0IG1hbmFnZSBpcyBsYXJnZSwgYW5kIGl0IGlz IHRoZSBzYW1lIHByb2JsZW0gSSBzYWlkLCBJIHRoaW5rLg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+ Pj4gDQo+Pj4gU2h1bnN1a2UNCj4+PiANCj4+PiAoMjAxNC8wMi8yNSAxNDoxNyksIENocmlzIEZy ZWRlcmljayB3cm90ZToNCj4+Pj4gSGkgU2h1bnN1a2Utc2FuLA0KPj4+PiBJIGFja25vd2xlZGdl IHRoZSBjb21tZW50cyBhYm91dCB0aGVzZSBiZWluZyBpbXBsZW1lbnRhdGlvbiBtYXR0ZXJzLA0K Pj4+PiBidXQgSSd2ZSBvZmZlcmVkIHNvbWUgdGhvdWdodHMgaW5saW5lIHdpdGggeW91ciBtYWls IGJlbG93LiBUaHgsIC9jDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+PiBGcm9tOiBTaHVuc3VrZSBIb21tYSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQu Y28uanBdDQo+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgOTowMCBQTQ0KPj4+ PiBUbzogQ2hyaXMgRnJlZGVyaWNrOyBSb24gUGFya2VyDQo+Pj4+IENjOiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRS OiBJLUQgQWN0aW9uOg0KPj4+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50 eHQNCj4+Pj4gDQo+Pj4+IEhpIFJvbiwgQ2hyaXMsDQo+Pj4+IA0KPj4+PiBUaGFuayB5b3UgZm9y IHlvdXIgcmVwbHkuDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIHRoYXQgeW91ciBwb2ludHMgYXJlIGZv bGxvd2luZzoNCj4+Pj4gaW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBhcyB1c2VyIGN1 c3RvbWl6ZWQsIHBlci1zdWJzY3JpYmVyIFNGQ3Mgc2hvdWxkbid0IGJlIG1hZGUsIGJ1dCB0aGUg U0ZzIHNob3VsZCByZWNvZ25pemUgc3Vic2NyaWJlcnMgYnkgSVAgYWRkcmVzcyBvciBtZXRhZGF0 YS4NCj4+Pj4gQ0Y+PiBNeSBwb2ludCB3YXMgdGhhdCBJIGRvbid0IHNlZSBpdCBhcyBkZXNpcmFi bGUgdG8gaGF2ZSBzcGVjaWZpYyBwZXItc3Vic2NyaWJlciBTRkMgcnVsZXMgKGFzIGluIHN0YXRp YyBydWxlcywgbGlrZSBzdWJzY3JpYmVyX0NocmlzPVNGQ19hX2JfYyksIHdpdGggYSBydWxlIGZv ciBldmVyeSBzdWIsIGluIHRoYXQgc2Vuc2UuIEJldHRlciBpcyBhIHNjZW5hcmlvIHdoZXJlIHRo ZSBTRkMgY2hhaW4gY29udHJvbGxlciBpcyBzdWJzY3JpYmVyLWF3YXJlICsgYWJsZSB0byBldmFs dWF0ZSBtdWx0aXBsZSBvcnRob2dvbmFsIGZsb3cgKyBzdWJzY3JpYmVyIGNvbmRpdGlvbnMgaW4g cmVhbCB0aW1lLCBhbmQgZm9ybXVsYXRlIGEgY2hhaW4gb24gdGhlIGJhc2lzIG9mIHRob3NlIGR5 bmFtaWMgY29uZGl0aW9ucy4NCj4+Pj4gDQo+Pj4+IE9mIGNvdXJzZSwgaXQgaXMgb25lIG9mIHRo ZSBzb2x1dGlvbnMuDQo+Pj4+IEhvd2V2ZXIsIGluIHRoaXMgY2FzZSwgSSB0aGluayB0aGF0IFNG cyBhcyB1c2VyIGN1c3RvbWl6ZWQgbWlnaHQgYmUgcmVxdWlyZWQgdG8gaGF2ZSBhIGZ1bmN0aW9u IHRvIHJlY29nbml6ZSBlYWNoIHN1YnNjcmliZXIuDQo+Pj4+IENGPj4gSSB3YXNuJ3QgYWN0dWFs bHkgdGhpbmtpbmcgaW4gdGVybXMgb2YgU0YgKHJlKWNsYXNzaWZpY2F0aW9uOyBJJ3ZlIHByZXZp b3VzbHkgY29tbWVudGVkIG9uIHdoeSBJIHRoaW5rIHRoYXQgaWRlYSBpcyBzb21ld2hhdCBmcmF1 Z2h0IChpLmUuIGJlY2F1c2UgbW9kaWZpY2F0aW9uIG9mIHRoZSBmbG93IHBhdGggYnkgYSBzZXJ2 aWNlIGZ1bmN0aW9uIHdpdGhpbiB0aGUgY2hhaW4gY291bGQgcmVzdWx0IGluIGEgJ2JyZWFraW5n JyBvZiB0aGUgY2hhaW4gb3IgZmxvdy4gSWYgdGhlcmUgaXMgbm90IGJpZGlyZWN0aW9uYWwgc3lt bWV0cnkgaW4gdGhlIGZsb3cgYW5kIHNlcnZpY2UgZnVuY3Rpb24gZWxlbWVudHMgaW4gdGhlIGNo YWluIGNhbiBtYWtlIHJvdXRpbmcgZGVjaXNpb25zLCB0aGVuIHRoZXJlJ3Mgc29tZSBtZXRhZGF0 YSBjb3JyZWxhdGlvbiB0byB3b3JrIG91dCwgYXQgbWluaW11bSkuIEkgZG8gYWdyZWUgdGhhdCB0 aGUgU0ZDIGNoYWluIGNvbnRyb2xsZXIgd291bGQgbmVlZCB0byBiZSBzdWJzY3JpYmVyLWF3YXJl IHRob3VnaC4NCj4+Pj4gDQo+Pj4+IE9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHRoYXQgdGhl cmUgYXJlIGNhc2VzIHdoZW4gdGhlIGZ1bmN0aW9uIGNhbid0IGJlIGFkb3B0ZWQsIHN1Y2ggbGlr ZSBTRnMgYXJlIGN1cnJlbnQgZXF1aXBtZW50IHRoYXQgZG9uJ3QgaGF2ZSBmdW5jdGlvbiB0byBy ZWNvZ25pemUgbWV0YWRhdGEuDQo+Pj4+IENGPj4gQWdyZWVkLiBUaGlzIHNwZWFrcyB0byBteSBj b21tZW50IGFib3ZlICsgdG8gdGhlIGFkdmFudGFnZXMgc29tZSBvZiB1cyBoYXZlIG1lbnRpb25l ZCB2aXogYSBjb25zb2xpZGF0ZWQgcG9saWN5LWJhc2VkIHN0ZWVyaW5nL1BEUC9TRkMgY2hhaW4g Y29udHJvbGxlciBlbnRpdHkuDQo+Pj4+IA0KPj4+PiBIb3cgZG8gd2UgaGFuZGxlIHRoZXNlIGNh c2VzPw0KPj4+PiBBbnkgbmV3IHByb2JsZW1zIG9yIHJlcXVpcmVtZW50cyBtYXkgb2NjdXI/DQo+ Pj4+IA0KPj4+PiByZWdhcmRzLA0KPj4+PiANCj4+Pj4gU2h1bnN1a2UNCj4+Pj4gDQo+Pj4+ICgy MDE0LzAyLzI1IDg6NDYpLCBDaHJpcyBGcmVkZXJpY2sgd3JvdGU6DQo+Pj4+PiBZZXMsIGFncmVl ZCBvbiB0aGF0Lg0KPj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b21dDQo+Pj4+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDY6NDUgUE0NCj4+Pj4+ IFRvOiBDaHJpcyBGcmVkZXJpY2s7IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6IFtzZmNd IFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMt MDMudHh0DQo+Pj4+PiANCj4+Pj4+IFRoYW5rcywgQ2hyaXMuDQo+Pj4+PiANCj4+Pj4+IEkgZG8g dGhpbmsgdGhlcmUgYXJlIGxvdHMgb2YgZWZmaWNpZW5jaWVzIHdoZW4gdGhlIGZsb3cgbGVhcm5l ciAoY2xhc3NpZmllcikgYW5kIHBvbGljeSBldmFsdWF0b3IgKFBEUCkgYXJlIGNvLWxvY2F0ZWQu ICAgSG93ZXZlciwgYXJjaGl0ZWN0dXJhbGx5LCBJIHdvdWxkbid0IG1hbmRhdGUgdGhhdCB0aGV5 IGJlIGNvLWxvY2F0ZWQuDQo+Pj4+PiANCj4+Pj4+ICAgICAgUm9uDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IENocmlzIEZyZWRl cmljayBbbWFpbHRvOmNmcmVkZXJpY2tAc2FuZHZpbmUuY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5 LCBGZWJydWFyeSAyNCwgMjAxNCA1OjI2IFBNDQo+Pj4+PiBUbzogUm9uIFBhcmtlcjsg5pys6ZaT 5L+K5LuLDQo+Pj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQo+Pj4+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+Pj4+PiBkcmFm dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+IA0KPj4+Pj4gQWdyZWVk Lg0KPj4+Pj4gVG8gcmVzdGF0ZSB0aGlzIHNsaWdodGx5LCBpZiB0aGUgU0ZDIHN0ZWVyaW5nL2Rl Y2lzaW9uIGxvY3VzIGlzIGNhcGFibGUgb2YgZXZhbHVhdGluZyBtdWx0aXBsZSBvcnRob2dvbmFs IHBvbGljeSBjb25kaXRpb25zIHRoZW4gdGhpcyBpc3N1ZSBpcyBvYnZpYXRlZDsgc3Vic2NyaWJl cnMgYmVjb21lIGFuIGFnZ3JlZ2F0ZSBvZiAnd2hhdCB0aGV5IGFyZScgKyBhcmUgbm90IHNpbXBs eSAnd2hvIHRoZXkgYXJlJy4NCj4+Pj4+IEFzIFJvbiBzdGF0ZXMsIHRoaXMgYXdhcmVuZXNzIG1h eSBiZSBkZXJpdmVkIGZyb20gTERBUCBsb29rdXAsIFJBRElVUywgR3gsIHByZS1wcm92aXNpb25l ZCBydWxlcywgZXRjLg0KPj4+Pj4gVG8gaWxsdXN0cmF0ZSB3LyBhbiBleGFtcGxlLCB3ZSBtaWdo dCBzYXkgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4+Pj4+IElmIHN1YnNjcmliZXIgWCBpcyB1c2lu ZyB5b3V0dWJlLCBhbmQgaXMgb24gYSBjb25nZXN0ZWQgY2VsbCwgYW5kIGlzIG9uIGFuIGlQaG9u ZSwgYW5kIGlzIGluIHRoZSAiR29sZCBUaWVyIiwgYW5kLCBhbmQsIGFuZCwgYW5kLCBldGMsIHRo ZW4gdGhlIGNoYWluIGNvbnNpc3RzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGEsIGIsIGFuZCBjLg0K Pj4+Pj4gVGhlcmUncyBubyBuZWVkIHRvIGVudGVyIGEgc3RhdGljIFNGQyBydWxlL2NoYWluIGZv ciBzdWJzY3JpYmVyIFggKG9yIGFueSBzdWJzY3JpYmVyKS4gSW4gZmFjdCwgaXQncyBub3QgZGVz aXJhYmxlIGFueXdheSBiZWNhdXNlIGFsbCBvZiB0aGUgYWJvdmUgY29uZGl0aW9ucyBtYXkgZXZh bHVhdGUgdG8gVHJ1ZSwgc2F2ZSBvbmUgKCJpcyBvbiBhIGNvbmdlc3RlZCBjZWxsIiksIGFuZCB0 aGUgcmVzdWx0YW50IGNoYWluIG1pZ2h0IGJlIGFsdGVyZWQgKHBlcmhhcHMgdG8gYnlwYXNzIGEg dmlkZW8gb3B0aW1pemF0aW9uIHNlcnZpY2UgZnVuY3Rpb24pLg0KPj4+Pj4gVGhpcyBhbHNvIGdv ZXMgdG8gdGhlIGVhcmxpZXIgY29tbWVudHMgUm9uICsgSSBtYWRlIGFib3V0DQo+Pj4+PiBjb25z b2xpZGF0aW5nIHRoZSBmbG93IHJlY29nbml0aW9uICsgZGVjaXNpb24tbWFraW5nIGVudGl0eSBp biBhDQo+Pj4+PiBzaW5nbGUgKHN1aXRhYmx5IHBvbGljeS1hd2FyZSkgbm9kZSB0byByZWR1Y2Ug dGhlIGNvbXBsZXhpdHkgKyB0bw0KPj4+Pj4gc2NhbGUgcHJvcGVybHkuIFRoeCwgL2MNCj4+Pj4+ IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4g U2VudDogU3VuZGF5LCBGZWJydWFyeSAyMywgMjAxNCAxMDozOSBQTQ0KPj4+Pj4gVG86IOacrOmW k+S/iuS7iw0KPj4+Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRm Lm9yZw0KPj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJh ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+IFNodW5z dWtlLXNhbiwNCj4+Pj4+IA0KPj4+Pj4gV2hpbGUgYSB0aGVvcmV0aWNhbCBjYXNlIGNhbiBiZSBt YWRlIGZvciBvbmUgb3IgbW9yZSBTRkNzIHBlciBzdWJzY3JpYmVyLCBmb3IgcmVhc29ucyB5b3Ug c3RhdGUsIGl0IGlzbid0IHByYWN0aWNhbC4gIEJ1dCwgdGhlcmUgaXMgYW5vdGhlciB3YXkgdG8g dmlldyB0aGlzIGFzcGVjdCBvZiB0aGUgcHJvYmxlbS4gIExldCdzIHRha2UgeW91ciBwZXItc3Vi c2NyaWJlciBjdXN0b21pemVkIGZpcmV3YWxsIGFzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuICBJ ZiB0aGVyZSB3ZXJlIG9ubHkgb25lIGZpcmV3YWxsLCBpbnN0ZWFkLCBhbmQgaXQgd2FzIGNhcGFi bGUgb2YgbG9jYWwgcG9saWN5IGV2YWx1YXRpb24gYmFzZWQgb24gc3Vic2NyaWJlciwgdGhlIG51 bWJlciBvZiBTRkNzIHdvdWxkIGJlIHZhc3RseSByZWR1Y2VkLiAgIE9uZSB3YXkgZm9yIHRoYXQg dG8gaGFwcGVuIHdvdWxkIGJlIHRvIHNpbXBseSB1c2UgdGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBJ UCBhZGRyZXNzIGZyb20gdGhlIHBhY2tldCBhbmQgc29tZSBvdXQgb2YgYmFuZCBsb29rdXAgbWVj aGFuaXNtIGxpa2UgTERBUCBvciBSQURJVVMgYXQgdGhlIGZpcmV3YWxsLiAgICBBbm90aGVyIGFw cHJvYWNoIHRvIGRldGVybWluZSB3aG8gdGhlIHN1YnNjcmliZXIgaXMgd291bGQgYmUgZm9yIHRo ZSBTRkMgY2xhc3NpZmllciB0byBhZGQgYSBkaXN0aW5jdCBzdWJzY3JpYmVyIGlkIGFzIG1ldGFk YXRhIHRvIHRoZSBzZXJ2aWNlIGhlYWRlciAoZWcsIGFuIElNU0kpIGFuZCBzdGlsbCB1c2UgTERB UCwgZXRjLiBhdCB0aGUgZmlyZXdhbGwuDQo+Pj4+PiANCj4+Pj4+IElmIHRoZSBwcm9ibGVtIGlz IGNoYW5nZWQgc2xpZ2h0bHkgc28gdGhhdCB0aGUgZmlyZXdhbGwgcG9saWN5IGlzIHBlciBncm91 cCBvZiBzdWJzY3JpYmVycywgd2hlcmUgdGhlcmUgYXJlIHBlcmhhcHMgMTBzIG9mIGdyb3Vwcywg dGhlbiB5ZXQgYW5vdGhlciBhcHByb2FjaCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwgYXMgYSBk aXN0aW5jdCBsb2dpY2FsIGZpcmV3YWxsIHBlciBmaXJld2FsbCBwb2xpY3kgc2V0ICh0aGV5IGNv dWxkIGFsbCByZXNpZGUgaW4gdGhlIHNhbWUgbWFjaGluZSBvciBWTSkgYW5kIHRvIGNvb3JkaW5h dGUgdGhlIGNsYXNzaWZpZXIncyBwb2xpY3kgYWNjb3JkaW5nbHkuDQo+Pj4+PiANCj4+Pj4+ICAg ICBSb24NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDowNCBQ TSwgIuacrOmWk+S/iuS7iyIgPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0K Pj4+Pj4+IA0KPj4+Pj4+IEhpIE1lZCwNCj4+Pj4+PiANCj4+Pj4+PiBJbiB0ZXJtcyBvZiB5b3Vy IGNvbW1lbnQsIEkgYXNzdW1lZCBzb21lIHVzZSBjYXNlcyBhYm91dCBzY2FsYWJpbGl0eSBzbyB0 aGF0IHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhYm91dCBzY2FsYWJpbGl0eSBjb25z aWRlcmF0aW9ucy4NCj4+Pj4+PiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0aG9yIG9mIHJl cXVpcmVtZW50IGRyYWZ0IGFuZCB0aGluayBzY2FsYWJpbGl0eSBpcyBvbmUgb2YgaW1wb3J0YW50 IHRoaW5ncyB0byBjb25zaWRlci4NCj4+Pj4+PiANCj4+Pj4+PiBBc3N1bWluZyB0aGUgdXNlIGNh c2VzIGxpc3RlZCBmb2xsb3dpbmcsIHRoZSBtYW5hZ2VtZW50IG1lY2hhbmlzbSBvZiBTZXJ2aWNl IEZ1bmN0aW9uIENoYWlucyBtaWdodCByZXF1aXJlIGhpZ2ggc2NhbGFiaWxpdHkuDQo+Pj4+Pj4g DQo+Pj4+Pj4gMS4gVGhlIGNhc2UgdGhhdCB0aGUgdHlwZXMgb2YgU0YgaW5jcmVhc2U6DQo+Pj4+ Pj4gSSBhc3N1bWVkIHRoYXQgdGhlIHVuaXQgb2YgYXBwbHlpbmcgU0ZDIHRvIHRyYWZmaWMgaXMg Zm9sbG93aW5nOw0KPj4+Pj4+ICAgLSBncm91cGluZzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGgg c3BlY2lmaWMgU0ZDIGZvciBlYWNoIHNlcnZpY2UsDQo+Pj4+Pj4gICAgIGVudGVycHJpc2UgY3Vz dG9tZXIgb3IgcmVnaW9uLA0KPj4+Pj4+ICAgLSBwZXItc3Vic2NyaWJlcjogdHJhZmZpYyBpcyBh cHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBlYWNo44CADQo+Pj4+Pj4gICAgIHN1YnNjcmli ZXIgKGUuZy4gcGVyIElQIGFkZHJlc3MsIFZMQU4gSUQgZXQuYWwpLA0KPj4+Pj4+ICAgLSBwZXIt ZmxvdzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBlYWNoIHN1YnNj cmliZXIsDQo+Pj4+Pj4g44CA44CAYW5kIG9iamVjdGl2ZSAoZS5nLiBwcmUgVVJMLCBhcHBsaWNh dGlvbiBldC5hbCkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gU29tZSBvZiB0aGUgc2VydmljZSBwcm92aWRl cnMgaGF2ZSBlbm9ybW91cyBudW1iZXIgb2Ygc3Vic2NyaWJlcnMsIGFuZCB0aGUgbnVtYmVyIG9m IHN1YnNjcmliZXJzIGlzIHVwIHRvIHNldmVyYWwgdGVucyBvciBodW5kcmVkcyBvZiBtaWxsaW9u LiBUaGVyZWZvcmUsIGluIGNhc2VzIG9mIHBlci1zdWJzY3JpYmVyIGFuZCBwZXItZmxvdywgdGhl IG51bWJlciBvZiBTRkNzIG1pZ2h0IGluY3JlYXNlIGV4cGxvc2l2ZWx5LiBQZXItc3Vic2NyaWJl ciBTRkNzIHdvdWxkIGJlIG5lZWRlZCBpbiB0aGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNG cyBkZWRpY2F0ZWQgdG8gZWFjaCB1c2VyKGUuZy4gdkNQRSBhcyB1c2VyIGN1c3RvbWl6ZWQpLg0K Pj4+Pj4+IA0KPj4+Pj4+IEFsc28sIGluIGNhc2Ugb2YgZ3JvdXBpbmcsIGlmIHRoZXJlIGFyZSBt dWx0aXBsZSBncm91cHMgd2hvc2UgcG9saWNpZXMgYXJlIGRpZmZlcmVudCwgc3VjaCBhcyBwZXIg ZW50ZXJwcmlzZSBjdXN0b21lciBhbmQgcGVyIHJlZ2lvbiwgdGhlIG51bWJlciBvZiBTRkNzIHdv dWxkIGluY3JlYXNlIChlLmcuIEZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBwb2xpY3kgZm9yIGVh Y2ggZW50ZXJwcmlzZSBjdXN0b21lcikuDQo+Pj4+Pj4gDQo+Pj4+Pj4gMi4gVGhlIGNhc2UgdGhh dCB0aGVyZSBhcmUgc29tZSBTRnMgdGhhdCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5z dGFuY2U6DQo+Pj4+Pj4gSW4gY2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBm dW5jdGlvbiBpbiB0aGUgbmV0d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9y IGVhY2ggaW5zdGFuY2UsIHRoZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+ Pj4+Pj4gVGhlIFNGcyB0aGF0IHByb2Nlc3Mgc3RhdGVmdWwgdHJhZmZpYyBhcmUgbmVlZGVkIHRv IGJlIGRpZmZlcmVudGlhdGVkIHBlciBpbnN0YW5jZSAoZS5nLiBGaXJld2FsbCwgQ29udGVudHMt Q2FjaGUsIGFuZCBWaWRlby1PcHRpbWl6ZXIpLg0KPj4+Pj4+IA0KPj4+Pj4+IElNSE8scmVxdWly ZW1lbnRzIGZvciBzY2FsYWJpbGl0eSB3aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBo ZWFkZXIgZm9ybWF0Lg0KPj4+Pj4+IA0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiANCj4+Pj4+PiBT aHVuc3VrZQ0KPj4+Pj4+IA0KPj4+Pj4+ICgyMDE0LzAyLzEyIDE4OjQ5KSwgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4+Pj4gRGVhciBhbGwsDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBUaGlzIG5ldyB2ZXJzaW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2Vu dGF0aXZlcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFja2VkIGhlcmU6 DQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWJvdWNhZGFp ci1zZmMtcmVxdWlyZW1lbnRzLTANCj4+Pj4+Pj4gMQ0KPj4+Pj4+PiAmDQo+Pj4+Pj4+IGRpZmZ0 eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVu dHMtMDMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVkDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4gRGUgOiBJLUQtQW5u b3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydA0K Pj4+Pj4+PiBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1lcmNyZWRpIDEy IGbDqXZyaWVyIDIwMTQgMTA6NDYNCj4+Pj4+Pj4gw4ANCj4+Pj4+Pj4gOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0KPj4+Pj4+PiBkcmFmdC1ib3VjYWRhaXItc2Zj LXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gICAgICAgICAgVGl0 bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5n DQo+Pj4+Pj4+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcNCj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtlcg0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBDYXJsb3MgUGlnbmF0YXJvDQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEtlbmdvIE5haXRvDQo+Pj4+Pj4+ICAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+Pj4gICAgIFBhZ2Vz ICAgICAgICAgICA6IDE0DQo+Pj4+Pj4+ICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAyLTEy DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+Pj4gICAgIFRoaXMgZG9jdW1lbnQg aWRlbnRpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgU2VydmljZSBGdW5jdGlvbg0KPj4+ Pj4+PiAgICAgQ2hhaW5pbmcgKFNGQykuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3VjYWRh aXItc2ZjLXJlcXVpcmVtZW50cy8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+Pj4+PiANCj4+ Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K Pj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib3VjYWRhaXIt c2ZjLXJlcXVpcmVtZW50cy0wDQo+Pj4+Pj4+IDMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPj4+Pj4+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+Pj4+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IEktRC1Bbm5vdW5j ZUBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ktZC1hbm5vdW5jZQ0KPj4+Pj4+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAtLQ0KPj4+Pj4+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pj4+Pj4g5pys6ZaT IOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+Pj4+Pj4gDQo+Pj4+Pj4g5pel5pys6Zu75L+h6Zu7 6Kmx5qCq5byP5Lya56S+DQo+Pj4+Pj4g44ON44OD44OI44Ov44O844Kv44K144O844OT44K544K3 44K544OG44Og56CU56m25omADQo+Pj4+Pj4g6Lui6YCB44K144O844OT44K55Z+655uk44OX44Ot 44K444Kn44Kv44OIDQo+Pj4+Pj4g6Lui6YCB44K144O844OT44K55Yi25b6hRFANCj4+Pj4+PiAN Cj4+Pj4+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiUtemHjuW4gue3keeUujMtOS0xMQ0K Pj4+Pj4+IFRFTDogMDQyMi01OS0zNDg2DQo+Pj4+Pj4gRS1NQUlMOiBob21tYS5zaHVuc3VrZUBs YWIubnR0LmNvLmpwDQo+Pj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNAaWV0 Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+ Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBTaHVuc3VrZSBIb21tYQ0KPj4+PiA8aG9tbWEuc2h1bnN1 a2VAbGFiLm50dC5jby5qcD4NCj4+Pj4gVEVMOiArODEgMDQyMiA1OSAzNDg2DQo+Pj4+IEZBWDog KzgxIDA0MjIgNjAgNzQ2MA0KPj4+PiANCj4+Pj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0g TGFicy4NCj4+Pj4gTXVzYXNoaW5vIGNpdHksIFRva3lvLCBKYXBhbg0KPj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gU2h1bnN1a2UgSG9tbWENCj4+PiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4N Cj4+PiBURUw6ICs4MSAwNDIyIDU5IDM0ODYNCj4+PiBGQVg6ICs4MSAwNDIyIDYwIDc0NjANCj4+ PiANCj4+PiBOVFQgTmV0d29yayBTZXJ2aWNlIFN5c3RlbSBMYWJzLg0KPj4+IE11c2FzaGlubyBj aXR5LCBUb2t5bywgSmFwYW4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+IA0KPj4gDQo+PiAtLSANCj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFNodW5zdWtlIEhvbW1hDQo+PiA8aG9tbWEu c2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+IFRFTDogKzgxIDA0MjIgNTkgMzQ4Ng0KPj4gRkFY OiArODEgMDQyMiA2MCA3NDYwDQo+PiANCj4+IE5UVCBOZXR3b3JrIFNlcnZpY2UgU3lzdGVtIExh YnMuDQo+PiBNdXNhc2hpbm8gY2l0eSwgVG9reW8sIEphcGFuDQo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Feb 26 07:21:27 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6B1A065C for ; Wed, 26 Feb 2014 07:21:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlPpyUnKfRRN for ; Wed, 26 Feb 2014 07:21:04 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8C1A065A for ; Wed, 26 Feb 2014 07:21:04 -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; Wed, 26 Feb 2014 07:21:03 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAlJICAADdIgIAAd4eAgAAmpID//3oy0IABnfKA///POEAAFVOxAAAPntoA Date: Wed, 26 Feb 2014 15:21:02 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZvgkqRcY9ANHfLeGEqiL18yc9cE Cc: Chris Frederick , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 15:21:16 -0000 SSBhZ3JlZSB3aXRoIEppbS4NCg0KV2UgaGF2ZSBhbHNvIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUg YXJlIGF0IGxlYXN0IDIgYXBwcm9hY2hlcyB0byBkaWZmZXJlbnRpYXRlZCBwb2xpY3kgKip3aXRo aW4qKiBhIHNlcnZpY2UgZnVuY3Rpb24uICAgVGhlIGZpcnN0IGlzIHRoYXQgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gaXMgcmVzcG9uc2libGUgZm9yIGRldGVybWluaW5nIHdoaWNoIHBvbGljaWVzIHRv IGFwcGx5IGluIGEgbWFubmVyIHRoYXQgaXMgcHJpdmF0ZSB0byBpdCAocGVyaGFwcyB1c2luZyBS QURJVVMsIG9yIExEQVAsIG9yIHNvbWUgb3RoZXIgZXh0ZXJuYWwgbG9va3VwIG1lY2hhbmlzbSku ICAgIFRoaXMgYXBwcm9hY2ggbWF5LCBpbiBzb21lIGNhc2VzLCBiZW5lZml0IGZyb20gYSBzdWJz Y3JpYmVyIGlkZW50aXR5IGJlaW5nIHBhc3NlZCBpbiB0aGUgaW5iYW5kIG1ldGFkYXRhLg0KDQpU aGUgc2Vjb25kLCB3aGljaCBpcyB3ZWxsIHN1aXRlZCB3aGVuIHRoZSBudW1iZXIgb2YgZGlzdGlu Y3QgcG9saWN5IHNldHMgaXMgc21hbGwgKGUuZy4sIGNvbnRlbnQtZmlsdGVyLWFkdWx0LCBjb250 ZW50LWZpbHRlci1jaGlsZCksIGlzIHRvIG1vZGVsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGFzIGhh dmluZyBtdWx0aXBsZSBsb2dpY2FsIGluc3RhbmNlcyBvZiBpdHNlbGYsIGVhY2ggaW1wbHlpbmcg YSBkaXN0aW5jdCBwb2xpY3kgc2V0LiAgIEluIHRoaXMgYXBwcm9hY2gsIFNGQ3MgYXJlIGJ1aWx0 IHN1Y2ggdGhhdCBhbnkgZ2l2ZW4gY2hhaW4gd291bGQgaW5jbHVkZSBhdCBtb3N0IG9uZSBvZiB0 aGUgbG9naWNhbCBpbnN0YW5jZXMuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE0IDk6NDIgQU0NClRv OiBSb24gUGFya2VyDQpDYzogU2h1bnN1a2UgSG9tbWE7IENocmlzIEZyZWRlcmljazsgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g VFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0K DQpSaWdodCBhbmQgdGhlIHBvaW50IGJlaW5nIHdoYXQgeW91IHdhbnQgdG8gZG8gaXMgc2hhcmUg U0ZDcyBhY3Jvc3Mgc3Vic2NyaWJlcnMgYW5kIGltcGxlbWVudCB3aXRoaW4gdGhlIFNGQyBhbnkg ZGlmZmVyZW50aWF0aW9uIGluIHRlcm1zIG9mIHBvbGljeSBmb3Igc3Vic2NyaWJlcnMgdGhhdCBj b25zdW1lIHRoZSBzYW1lIHNldCBvZiBzZXJ2aWNlcy4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0K DQo+IE9uIEZlYiAyNiwgMjAxNCwgYXQgNzozMiBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IEV2ZW4gaWYgc3Vic2NyaWJlcnMg Y2FuIHNlbGYgY29uZmlndXJlIHRoZWlyIHNlcnZpY2VzIHZpYSBhIHBvcnRhbCwgdGhlIG51bWJl ciBvZiBkaXN0aW5jdCBjb21iaW5hdGlvbnMgdGhhdCBhcmlzZSB3aWxsIHN0aWxsIGJlIGZpbml0 ZS4gIFRoYXQgaXMsIGluIGEgcG9wdWxhdGlvbiBvZiAxMDAwMDAwMDAgc3Vic2NyaWJlcnMsIHN1 cmVseSBzb21lIHdpbGwgZW5kIHVwIHdpdGggZXF1aXZhbGVudCBzZXJ2aWNlcz8NCj4gDQo+ICAg Um9uDQo+IA0KPj4gT24gRmViIDI2LCAyMDE0LCBhdCAyOjI1IEFNLCAiU2h1bnN1a2UgSG9tbWEi IDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+IA0KPj4gSGkgQ2hyaXMs IFJvbiwNCj4+IA0KPj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4gDQo+PiBJIHVuZGVy c3Rvb2QgdGhhdCB5b3Ugc2FpZC4NCj4+IEFuZCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG1l dGhvZCB1c2luZyBtZXRhZGF0YSBpcyBvbmUgb2YgdGhlIG1ldGhvZHMgZm9yIHJlY29nbml6aW5n IHN1YnNjcmliZXJzLg0KPj4gQnV0IHRoaXMgcHJvYmxlbSBpcyBpbXBsZW1lbnRhdGlvbiBtYXR0 ZXJzLCBzbyBpdCBpcyBub3QgYXQgdGhlIHN0YWdlIGZvciBkaXNjdXNzaW9uIHlldCwgSSB0aGlu ay4NCj4+IA0KPj4gV2hhdCBJIHdhbnQgdG8gc2F5IGlzIHRoYXQgdGhlcmUgYXJlIHJlcXVlc3Rz IGZvciBkaXN0aW5jdCBzZXJ2aWNlcyBwZXIgc3Vic2NyaWJlciwgc28gdGhhdCBTRkMgYXJjaGl0 ZWN0dXJlIHNob3VsZCBiZSBzY2FsYWJsZS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gU2h1 bnN1a2UNCj4+IA0KPj4gDQo+PiAoMjAxNC8wMi8yNSAyMzo0OSksIFJvbiBQYXJrZXIgd3JvdGU6 DQo+Pj4gRXhwYW5kaW5nIG9uIENocmlzJyBjb21tZW50cywgSSBkb24ndCB0aGluayB0aGUgcHJh Y3RpY2FsIGxpbWl0YXRpb25zIGFyZSB3cnQgdGhlIG51bWJlciBvZiBmdWxseS1xdWFsaWZpZWQg NS10dXBsZXMsIGJ1dCByYXRoZXIgdGhlIG51bWJlciBvZiBkaXN0aW5jdCB0cmVhdG1lbnQgc2Vx dWVuY2VzIHRoYXQgYXJpc2UgZnJvbSB0aG9zZSBmbG93cy4gICBPZiB0aGUgMTAwJ3Mgb2YgbWls bGlvbnMgb2YgZmxvd3MgdGhhdCBtaWdodCBiZSB0cmFja2VkIGJ5IGEgaGlnaCBlbmQgY2xhc3Np ZmllciwgcGVyaGFwcyB0aGUgbnVtYmVyIG9mIHVuaXF1ZSBzZXF1ZW5jZXMgdGhhdCBhcmlzZSBh cmUgaW4gdGhlIDEwMDAncy4gICAgSWYgYXBwbHlpbmcgYSBmaXhlZC1saW5lIG9yIG1vYmlsZSBz ZXJ2aWNlIHByb3ZpZGVyIHBlcnNwZWN0aXZlLCB0aGUgbnVtYmVyIG9mIGNoYWlucyB3b3VsZCBi ZSBwcm9wb3J0aW9uYWwgdG8gdGhlIG51bWJlciBvZiBkaXN0aW5jdCBlbmQtdG8tZW5kIHNlcnZp Y2UgcGxhbnMgb2ZmZXJlZCBhbmQgdGhlbiBtdWx0aXBsaWVkIGJ5IHRoZSBmbG93LWF3YXJlIHN1 YnNldHRpbmcgdGhhdCBjYW4gYmUgbWFuYWdlZCBieSB0aGUgY2xhc3NpZmllciAoaS5lLiwgc3Vi c2NyaWJlciBpcyBzdWJqZWN0IHRvIHNlcnZpY2UgZnVuY3Rpb24gQSB0aGVuIEIgdGhlbiBDIGJ1 dCBCIG9ubHkgbmVlZHMgVENQLzgwIHRyYWZmaWMsIEEgb25seSBuZWVkcyBVRFAgdHJhZmZpYywg Li4uKS4NCj4+PiANCj4+PiAgIFJvbg0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gRnJvbTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0Bz YW5kdmluZS5jb21dDQo+Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjUsIDIwMTQgOTo0NCBB TQ0KPj4+IFRvOiBTaHVuc3VrZSBIb21tYTsgUm9uIFBhcmtlcg0KPj4+IENjOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW3NmY10g VFI6IEktRCBBY3Rpb246IA0KPj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAz LnR4dA0KPj4+IA0KPj4+IEhpIFNodW5zdWtlLXNhbiwNCj4+PiBJIHJlY29nbml6ZSB0aGF0IHVs dGltYXRlbHksIHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVjaXNpb24gYW5kIG5vdCBzb21l dGhpbmcgdG8gYmUgbWFuZGF0ZWQgYXMgYSBoYXJkICdydWxlJy4gSSBqdXN0IHdhbnRlZCB0byBo aWdobGlnaHQgd2hhdCBpcyBwb3NzaWJsZSArIHdoYXQgd2UgYmVsaWV2ZSB0byBiZSBiZXN0IHBy YWN0aWNlcyBpbiB0aGlzIGFyZWEsIGJhc2VkIG9uIG91ciBleHBlcmllbmNlLg0KPj4+IFRoYXQg c2FpZCwgeWVzLCBJIGJlbGlldmUgdGhhdCBpbiBwcmFjdGljYWwgKHJlYWwtd29ybGQpIHRlcm1z LCBpdCBtYWtlcyBzZW5zZSB0byBkZWVtcGhhc2l6ZSB0aGUgJyhyZSljbGFzc2lmaWNhdGlvbicg cm9sZSBvZiBTRnMgaW4gbW9zdCBjYXNlcywgZm9yIHJlYXNvbnMgSSd2ZSBzdGF0ZWQgcHJldmlv dXNseSAocXVlc3Rpb25zIG9mIG1ldGFkYXRhIHNoYXJpbmcgYmV0d2VlbiBTRnMsIGlzc3VlcyBy ZWxhdGVkIHRvIHJldGFpbmluZyBpbnRlZ3JpdHkgb2YgY2hhaW5zL2JyZWFraW5nIGZsb3dzLCBl dGMuKS4NCj4+PiBUbyB5b3VyIGNvbW1lbnQgYWJvdXQgc2NhbGluZyB0aGUgU0ZDIENvbnRyb2xs ZXIsIEkgd291bGQganVzdCBzYXkgdGhhdCB0aGVyZSBhcmUgY29tbWVyY2lhbGx5IGRlcGxveWVk IFNGQyBDb250cm9sbGVycyB0b2RheSB0aGF0IGRvIHRoaXMsIGkuZS4gc2l0IGlubGluZSBpbiBj b25zdW1lciBuZXR3b3JrcywgcmVjZWl2ZS9pbnNwZWN0IG1pbGxpb25zIG9mIGNvbmN1cnJlbnQg YmlkaXJlY3Rpb25hbCBmbG93cywgKyBtYWtlIHJlYWwtdGltZSBTRkMgc3RlZXJpbmcgYW5kIHNl cXVlbmNpbmcgZGVjaXNpb25zIGJhc2VkIG9uIGZsb3csIHN1YnNjcmliZXIsIHNlc3Npb24sIGFu ZCBuZXR3b3JrIGNvbmRpdGlvbnMuDQo+Pj4gT2J2aW91c2x5LCBkaWZmZXJlbmNlcyBpbiB2ZW5k b3IgY2FwYWJpbGl0aWVzLCBhcyB3ZWxsIGFzIA0KPj4+IGFyY2hpdGVjdHVyYWwgZGVjaXNpb25z IHZpeiBjb25zb2xpZGF0aW5nIHZzLiBkaXN0cmlidXRpbmcgZGlmZmVyZW50IA0KPj4+IFNGQyBm dW5jdGlvbnMgbGlrZSBmbG93IGNsYXNzaWZpY2F0aW9uLCBQRFAvU0ZDIENvbnRyb2xsZXIsIA0K Pj4+IHN0ZWVyaW5nL2xiLCBldGMsIGFsbCB3aWxsIGhhdmUgYW4gaW1wYWN0IGhlcmUuIEJlc3Qs IC9jDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBTaHVu c3VrZSBIb21tYSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanBdDQo+Pj4gU2Vu dDogVHVlc2RheSwgRmVicnVhcnkgMjUsIDIwMTQgNzoyNSBBTQ0KPj4+IFRvOiBDaHJpcyBGcmVk ZXJpY2s7IFJvbiBQYXJrZXINCj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsg c2ZjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiANCj4+ PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+PiANCj4+PiBIaSBD aHJpcywNCj4+PiANCj4+PiBEbyB5b3UgbWVhbiB0aGF0LCBmb3IgcmV0YWluaW5nIGludGVncml0 eSBvZiBjaGFpbnMsIG1hbmFnZW1lbnQgb2Ygc3Vic2NyaWJlcnMgc2hvdWxkIGJlIHByb3ZpZGVk IG5vdCBieSBTRnMsIGJ1dCBieSBTRkMgY29udHJvbGxlcj8NCj4+PiANCj4+PiBJZiBzbywgdGhl IHByb2JsZW0gaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGNoYWlucyB0aGF0IFNGQyBjb250cm9sbGVy IG11c3QgbWFuYWdlIGlzIGxhcmdlLCBhbmQgaXQgaXMgdGhlIHNhbWUgcHJvYmxlbSBJIHNhaWQs IEkgdGhpbmsuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBTaHVuc3VrZQ0KPj4+IA0K Pj4+ICgyMDE0LzAyLzI1IDE0OjE3KSwgQ2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPj4+PiBIaSBT aHVuc3VrZS1zYW4sDQo+Pj4+IEkgYWNrbm93bGVkZ2UgdGhlIGNvbW1lbnRzIGFib3V0IHRoZXNl IGJlaW5nIGltcGxlbWVudGF0aW9uIA0KPj4+PiBtYXR0ZXJzLCBidXQgSSd2ZSBvZmZlcmVkIHNv bWUgdGhvdWdodHMgaW5saW5lIHdpdGggeW91ciBtYWlsIA0KPj4+PiBiZWxvdy4gVGh4LCAvYw0K Pj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogU2h1bnN1 a2UgSG9tbWEgW21haWx0bzpob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwXQ0KPj4+PiBTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDk6MDAgUE0NCj4+Pj4gVG86IENocmlzIEZyZWRl cmljazsgUm9uIFBhcmtlcg0KPj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsg c2ZjQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+ Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+IA0KPj4+PiBI aSBSb24sIENocmlzLA0KPj4+PiANCj4+Pj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4+ PiANCj4+Pj4gSSB0aGluayB0aGF0IHlvdXIgcG9pbnRzIGFyZSBmb2xsb3dpbmc6DQo+Pj4+IGlu IGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgYXMgdXNlciBjdXN0b21pemVkLCBwZXItc3Vi c2NyaWJlciBTRkNzIHNob3VsZG4ndCBiZSBtYWRlLCBidXQgdGhlIFNGcyBzaG91bGQgcmVjb2du aXplIHN1YnNjcmliZXJzIGJ5IElQIGFkZHJlc3Mgb3IgbWV0YWRhdGEuDQo+Pj4+IENGPj4gTXkg cG9pbnQgd2FzIHRoYXQgSSBkb24ndCBzZWUgaXQgYXMgZGVzaXJhYmxlIHRvIGhhdmUgc3BlY2lm aWMgcGVyLXN1YnNjcmliZXIgU0ZDIHJ1bGVzIChhcyBpbiBzdGF0aWMgcnVsZXMsIGxpa2Ugc3Vi c2NyaWJlcl9DaHJpcz1TRkNfYV9iX2MpLCB3aXRoIGEgcnVsZSBmb3IgZXZlcnkgc3ViLCBpbiB0 aGF0IHNlbnNlLiBCZXR0ZXIgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgU0ZDIGNoYWluIGNvbnRy b2xsZXIgaXMgc3Vic2NyaWJlci1hd2FyZSArIGFibGUgdG8gZXZhbHVhdGUgbXVsdGlwbGUgb3J0 aG9nb25hbCBmbG93ICsgc3Vic2NyaWJlciBjb25kaXRpb25zIGluIHJlYWwgdGltZSwgYW5kIGZv cm11bGF0ZSBhIGNoYWluIG9uIHRoZSBiYXNpcyBvZiB0aG9zZSBkeW5hbWljIGNvbmRpdGlvbnMu DQo+Pj4+IA0KPj4+PiBPZiBjb3Vyc2UsIGl0IGlzIG9uZSBvZiB0aGUgc29sdXRpb25zLg0KPj4+ PiBIb3dldmVyLCBpbiB0aGlzIGNhc2UsIEkgdGhpbmsgdGhhdCBTRnMgYXMgdXNlciBjdXN0b21p emVkIG1pZ2h0IGJlIHJlcXVpcmVkIHRvIGhhdmUgYSBmdW5jdGlvbiB0byByZWNvZ25pemUgZWFj aCBzdWJzY3JpYmVyLg0KPj4+PiBDRj4+IEkgd2Fzbid0IGFjdHVhbGx5IHRoaW5raW5nIGluIHRl cm1zIG9mIFNGIChyZSljbGFzc2lmaWNhdGlvbjsgSSd2ZSBwcmV2aW91c2x5IGNvbW1lbnRlZCBv biB3aHkgSSB0aGluayB0aGF0IGlkZWEgaXMgc29tZXdoYXQgZnJhdWdodCAoaS5lLiBiZWNhdXNl IG1vZGlmaWNhdGlvbiBvZiB0aGUgZmxvdyBwYXRoIGJ5IGEgc2VydmljZSBmdW5jdGlvbiB3aXRo aW4gdGhlIGNoYWluIGNvdWxkIHJlc3VsdCBpbiBhICdicmVha2luZycgb2YgdGhlIGNoYWluIG9y IGZsb3cuIElmIHRoZXJlIGlzIG5vdCBiaWRpcmVjdGlvbmFsIHN5bW1ldHJ5IGluIHRoZSBmbG93 IGFuZCBzZXJ2aWNlIGZ1bmN0aW9uIGVsZW1lbnRzIGluIHRoZSBjaGFpbiBjYW4gbWFrZSByb3V0 aW5nIGRlY2lzaW9ucywgdGhlbiB0aGVyZSdzIHNvbWUgbWV0YWRhdGEgY29ycmVsYXRpb24gdG8g d29yayBvdXQsIGF0IG1pbmltdW0pLiBJIGRvIGFncmVlIHRoYXQgdGhlIFNGQyBjaGFpbiBjb250 cm9sbGVyIHdvdWxkIG5lZWQgdG8gYmUgc3Vic2NyaWJlci1hd2FyZSB0aG91Z2guDQo+Pj4+IA0K Pj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayB0aGF0IHRoZXJlIGFyZSBjYXNlcyB3aGVu IHRoZSBmdW5jdGlvbiBjYW4ndCBiZSBhZG9wdGVkLCBzdWNoIGxpa2UgU0ZzIGFyZSBjdXJyZW50 IGVxdWlwbWVudCB0aGF0IGRvbid0IGhhdmUgZnVuY3Rpb24gdG8gcmVjb2duaXplIG1ldGFkYXRh Lg0KPj4+PiBDRj4+IEFncmVlZC4gVGhpcyBzcGVha3MgdG8gbXkgY29tbWVudCBhYm92ZSArIHRv IHRoZSBhZHZhbnRhZ2VzIHNvbWUgb2YgdXMgaGF2ZSBtZW50aW9uZWQgdml6IGEgY29uc29saWRh dGVkIHBvbGljeS1iYXNlZCBzdGVlcmluZy9QRFAvU0ZDIGNoYWluIGNvbnRyb2xsZXIgZW50aXR5 Lg0KPj4+PiANCj4+Pj4gSG93IGRvIHdlIGhhbmRsZSB0aGVzZSBjYXNlcz8NCj4+Pj4gQW55IG5l dyBwcm9ibGVtcyBvciByZXF1aXJlbWVudHMgbWF5IG9jY3VyPw0KPj4+PiANCj4+Pj4gcmVnYXJk cywNCj4+Pj4gDQo+Pj4+IFNodW5zdWtlDQo+Pj4+IA0KPj4+PiAoMjAxNC8wMi8yNSA4OjQ2KSwg Q2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPj4+Pj4gWWVzLCBhZ3JlZWQgb24gdGhhdC4NCj4+Pj4+ IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IFJvbiBQYXJr ZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4gU2VudDog TW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA2OjQ1IFBNDQo+Pj4+PiBUbzogQ2hyaXMgRnJlZGVy aWNrOyDmnKzplpPkv4rku4sNCj4+Pj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t OyBzZmNAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoN Cj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+ Pj4+PiBUaGFua3MsIENocmlzLg0KPj4+Pj4gDQo+Pj4+PiBJIGRvIHRoaW5rIHRoZXJlIGFyZSBs b3RzIG9mIGVmZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNsYXNzaWZpZXIpIGFu ZCBwb2xpY3kgZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhvd2V2ZXIsIGFyY2hp dGVjdHVyYWxseSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBjby1sb2NhdGVkLg0K Pj4+Pj4gDQo+Pj4+PiAgICAgIFJvbg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJl ZGVyaWNrQHNhbmR2aW5lLmNvbV0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIw MTQgNToyNiBQTQ0KPj4+Pj4gVG86IFJvbiBQYXJrZXI7IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVj dDogUkU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1y ZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+IEFncmVlZC4NCj4+Pj4+IFRvIHJlc3Rh dGUgdGhpcyBzbGlnaHRseSwgaWYgdGhlIFNGQyBzdGVlcmluZy9kZWNpc2lvbiBsb2N1cyBpcyBj YXBhYmxlIG9mIGV2YWx1YXRpbmcgbXVsdGlwbGUgb3J0aG9nb25hbCBwb2xpY3kgY29uZGl0aW9u cyB0aGVuIHRoaXMgaXNzdWUgaXMgb2J2aWF0ZWQ7IHN1YnNjcmliZXJzIGJlY29tZSBhbiBhZ2dy ZWdhdGUgb2YgJ3doYXQgdGhleSBhcmUnICsgYXJlIG5vdCBzaW1wbHkgJ3dobyB0aGV5IGFyZScu DQo+Pj4+PiBBcyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkgYmUgZGVyaXZlZCBmcm9t IExEQVAgbG9va3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQgcnVsZXMsIGV0Yy4NCj4+ Pj4+IFRvIGlsbHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5IHNvbWV0aGluZyBs aWtlIHRoaXM6DQo+Pj4+PiBJZiBzdWJzY3JpYmVyIFggaXMgdXNpbmcgeW91dHViZSwgYW5kIGlz IG9uIGEgY29uZ2VzdGVkIGNlbGwsIGFuZCBpcyBvbiBhbiBpUGhvbmUsIGFuZCBpcyBpbiB0aGUg IkdvbGQgVGllciIsIGFuZCwgYW5kLCBhbmQsIGFuZCwgZXRjLCB0aGVuIHRoZSBjaGFpbiBjb25z aXN0cyBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyBhLCBiLCBhbmQgYy4NCj4+Pj4+IFRoZXJlJ3Mgbm8g bmVlZCB0byBlbnRlciBhIHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChv ciBhbnkgc3Vic2NyaWJlcikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVj YXVzZSBhbGwgb2YgdGhlIGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNh dmUgb25lICgiaXMgb24gYSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFp biBtaWdodCBiZSBhbHRlcmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlv biBzZXJ2aWNlIGZ1bmN0aW9uKS4NCj4+Pj4+IFRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJsaWVy IGNvbW1lbnRzIFJvbiArIEkgbWFkZSBhYm91dCANCj4+Pj4+IGNvbnNvbGlkYXRpbmcgdGhlIGZs b3cgcmVjb2duaXRpb24gKyBkZWNpc2lvbi1tYWtpbmcgZW50aXR5IGluIGEgDQo+Pj4+PiBzaW5n bGUgKHN1aXRhYmx5IHBvbGljeS1hd2FyZSkgbm9kZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkg KyB0byANCj4+Pj4+IHNjYWxlIHByb3Blcmx5LiBUaHgsIC9jDQo+Pj4+PiANCj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINCj4+Pj4+IFNlbnQ6IFN1bmRheSwg RmVicnVhcnkgMjMsIDIwMTQgMTA6MzkgUE0NCj4+Pj4+IFRvOiDmnKzplpPkv4rku4sNCj4+Pj4+ IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+Pj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1z ZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+Pj4+PiBTaHVuc3VrZS1zYW4sDQo+Pj4+ PiANCj4+Pj4+IFdoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9y IG1vcmUgU0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBpc24n dCBwcmFjdGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBhc3Bl Y3Qgb2YgdGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3VzdG9t aXplZCBmaXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBv bmx5IG9uZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2FsIHBv bGljeSBldmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZDcyB3 b3VsZCBiZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3b3Vs ZCBiZSB0byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9t IHRoZSBwYWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtlIExE QVAgb3IgUkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBkZXRl cm1pbmUgd2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNzaWZp ZXIgdG8gYWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2Vy dmljZSBoZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQgdGhl IGZpcmV3YWxsLg0KPj4+Pj4gDQo+Pj4+PiBJZiB0aGUgcHJvYmxlbSBpcyBjaGFuZ2VkIHNsaWdo dGx5IHNvIHRoYXQgdGhlIGZpcmV3YWxsIHBvbGljeSBpcyBwZXIgZ3JvdXAgb2Ygc3Vic2NyaWJl cnMsIHdoZXJlIHRoZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4geWV0IGFub3Ro ZXIgYXBwcm9hY2ggaXMgdG8gbW9kZWwgdGhlIGZpcmV3YWxsIGFzIGEgZGlzdGluY3QgbG9naWNh bCBmaXJld2FsbCBwZXIgZmlyZXdhbGwgcG9saWN5IHNldCAodGhleSBjb3VsZCBhbGwgcmVzaWRl IGluIHRoZSBzYW1lIG1hY2hpbmUgb3IgVk0pIGFuZCB0byBjb29yZGluYXRlIHRoZSBjbGFzc2lm aWVyJ3MgcG9saWN5IGFjY29yZGluZ2x5Lg0KPj4+Pj4gDQo+Pj4+PiAgICAgUm9uDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4+IE9uIEZlYiAyMywgMjAxNCwgYXQgMTA6MDQgUE0sICLmnKzplpPkv4rk u4siIDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+ PiBIaSBNZWQsDQo+Pj4+Pj4gDQo+Pj4+Pj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJIGFz c3VtZWQgc29tZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4gY29u dGludWUgdGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMuDQo+ Pj4+Pj4gI0kgd29yayB3aXRoIEsuTmFpdG8sIGNvLWF1dGhvciBvZiByZXF1aXJlbWVudCBkcmFm dCBhbmQgdGhpbmsgc2NhbGFiaWxpdHkgaXMgb25lIG9mIGltcG9ydGFudCB0aGluZ3MgdG8gY29u c2lkZXIuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9s bG93aW5nLCB0aGUgbWFuYWdlbWVudCBtZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFp bnMgbWlnaHQgcmVxdWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPj4+Pj4+IA0KPj4+Pj4+IDEuIFRo ZSBjYXNlIHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPj4+Pj4+IEkgYXNzdW1lZCB0 aGF0IHRoZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4+ Pj4+PiAgIC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBm b3IgZWFjaCBzZXJ2aWNlLA0KPj4+Pj4+ICAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9yIHJlZ2lv biwNCj4+Pj4+PiAgIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNw ZWNpZmljIFNGQyBmb3IgZWFjaOOAgA0KPj4+Pj4+ICAgICBzdWJzY3JpYmVyIChlLmcuIHBlciBJ UCBhZGRyZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4+Pj4+PiAgIC0gcGVyLWZsb3c6IHRyYWZmaWMg aXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPj4+Pj4+ IOOAgOOAgGFuZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0K Pj4+Pj4+IA0KPj4+Pj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1v dXMgbnVtYmVyIG9mIHN1YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBp cyB1cCB0byBzZXZlcmFsIHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBp biBjYXNlcyBvZiBwZXItc3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZD cyBtaWdodCBpbmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBi ZSBuZWVkZWQgaW4gdGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRv IGVhY2ggdXNlcihlLmcuIHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4+Pj4+PiANCj4+Pj4+ PiBBbHNvLCBpbiBjYXNlIG9mIGdyb3VwaW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBz IHdob3NlIHBvbGljaWVzIGFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3Vz dG9tZXIgYW5kIHBlciByZWdpb24sIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAo ZS5nLiBGaXJld2FsbHMgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2Ug Y3VzdG9tZXIpLg0KPj4+Pj4+IA0KPj4+Pj4+IDIuIFRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNv bWUgU0ZzIHRoYXQgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlOg0KPj4+Pj4+ IEluIGNhc2UgdGhhdCB0aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNhbWUgZnVuY3Rpb24gaW4gdGhl IG5ldHdvcmsgYW5kIHRoZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNl LCB0aGUgY29tYmluYXRpb24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNlLg0KPj4+Pj4+IFRoZSBTRnMg dGhhdCBwcm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBiZSBkaWZmZXJlbnRp YXRlZCBwZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNhY2hlLCBhbmQgVmlk ZW8tT3B0aW1pemVyKS4NCj4+Pj4+PiANCj4+Pj4+PiBJTUhPLHJlcXVpcmVtZW50cyBmb3Igc2Nh bGFiaWxpdHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1hdC4N Cj4+Pj4+PiANCj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gDQo+Pj4+Pj4gU2h1bnN1a2UNCj4+Pj4+ PiANCj4+Pj4+PiAoMjAxNC8wMi8xMiAxODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20gd3JvdGU6DQo+Pj4+Pj4+IERlYXIgYWxsLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhpcyBuZXcg dmVyc2lvbiBpbnRlZ3JhdGVzIGlucHV0cyBmcm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiBUaGUgZGlmZiBjYW4gYmUgdHJhY2tlZCBoZXJlOg0KPj4+Pj4+PiBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVt ZW50DQo+Pj4+Pj4+IHMtMA0KPj4+Pj4+PiAxDQo+Pj4+Pj4+ICYNCj4+Pj4+Pj4gZGlmZnR5cGU9 LS1odG1sJnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cw0K Pj4+Pj4+PiAtMDMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVkDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4gRGUgOiBJ LUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg DQo+Pj4+Pj4+IHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVudm95w6kgOiBtZXJj cmVkaSAxMiBmw6l2cmllciANCj4+Pj4+Pj4gMjAxNCAxMDo0NiDDgA0KPj4+Pj4+PiA6IGktZC1h bm5vdW5jZUBpZXRmLm9yZyBPYmpldCA6IEktRCBBY3Rpb246DQo+Pj4+Pj4+IGRyYWZ0LWJvdWNh ZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5pbmcNCj4+Pj4+Pj4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9oYW1lZCBCb3Vj YWRhaXINCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1 ZW5ldA0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFubG9uZyBKaWFuZw0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+Pj4+Pj4gICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4+PiAg ICAgUGFnZXMgICAgICAgICAgIDogMTQNCj4+Pj4+Pj4gICAgIERhdGUgICAgICAgICAgICA6IDIw MTQtMDItMTINCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+PiAgICAgVGhpcyBk b2N1bWVudCBpZGVudGlmaWVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBTZXJ2aWNlIEZ1bmN0 aW9uDQo+Pj4+Pj4+ICAgICBDaGFpbmluZyAoU0ZDKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnQNCj4+Pj4+Pj4gcy8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50 cy0wMw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50DQo+Pj4+Pj4+IHMtMA0KPj4+Pj4+PiAz DQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgDQo+Pj4+Pj4+IG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IEktRC1Bbm5vdW5jZSBtYWls aW5nIGxpc3QNCj4+Pj4+Pj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj4+Pj4+IEludGVy bmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9y IA0KPj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiAtLQ0KPj4+Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+Pj4+Pj4g5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+ Pj4+Pj4gDQo+Pj4+Pj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+Pj4+Pj4g44ON 44OD44OI44Ov44O844Kv44K144O844OT44K544K344K544OG44Og56CU56m25omADQo+Pj4+Pj4g 6Lui6YCB44K144O844OT44K55Z+655uk44OX44Ot44K444Kn44Kv44OIDQo+Pj4+Pj4g6Lui6YCB 44K144O844OT44K55Yi25b6hRFANCj4+Pj4+PiANCj4+Pj4+PiDjgJIxODAtODU4NeOAgOadseS6 rOmDveatpuiUtemHjuW4gue3keeUujMtOS0xMQ0KPj4+Pj4+IFRFTDogMDQyMi01OS0zNDg2DQo+ Pj4+Pj4gRS1NQUlMOiBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwDQo+Pj4+Pj4gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+Pj4+PiANCj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNm YyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+ IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gLS0NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBTaHVu c3VrZSBIb21tYQ0KPj4+PiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+Pj4gVEVM OiArODEgMDQyMiA1OSAzNDg2DQo+Pj4+IEZBWDogKzgxIDA0MjIgNjAgNzQ2MA0KPj4+PiANCj4+ Pj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4+Pj4gTXVzYXNoaW5vIGNpdHks IFRva3lvLCBKYXBhbg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gU2h1bnN1a2UgSG9tbWENCj4+PiA8 aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+PiBURUw6ICs4MSAwNDIyIDU5IDM0ODYN Cj4+PiBGQVg6ICs4MSAwNDIyIDYwIDc0NjANCj4+PiANCj4+PiBOVFQgTmV0d29yayBTZXJ2aWNl IFN5c3RlbSBMYWJzLg0KPj4+IE11c2FzaGlubyBjaXR5LCBUb2t5bywgSmFwYW4NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2Zj QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+IA0KPj4gDQo+PiAtLQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4gU2h1bnN1a2UgSG9tbWENCj4+IDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPg0KPj4g VEVMOiArODEgMDQyMiA1OSAzNDg2DQo+PiBGQVg6ICs4MSAwNDIyIDYwIDc0NjANCj4+IA0KPj4g TlRUIE5ldHdvcmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4+IE11c2FzaGlubyBjaXR5LCBUb2t5 bywgSmFwYW4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcg bGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg== From nobody Wed Feb 26 07:50:47 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B361A0677 for ; Wed, 26 Feb 2014 07:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 sOmJuWGBrVRf for ; Wed, 26 Feb 2014 07:50:32 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8911A0670 for ; Wed, 26 Feb 2014 07:50:31 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Wed, 26 Feb 2014 10:50:29 -0500 From: Dave Dolson To: Ron Parker , "Jim Guichard (jguichar)" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSAAA3T7AAACnDhIP//0f2AgAAociCAAIZdgIAAOz2A///tKICAARZkgIAAVVSAgAAkgACAAArQAIAATj1g Date: Wed, 26 Feb 2014 15:50:29 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xzflgJS4sFinN1hPVs9evcZdGnw Cc: Chris Frederick , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 15:50:39 -0000 QWxzbywgZWFybGllciB3ZSBkaXNjdXNzZWQgdGhlIGJlbmVmaXRzIG9mIG9ydGhvZ29uYWwgdHJl YXRtZW50IG9mIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gdnMuIG1ldGEtZGF0YS4NCkkuZS4sIHNv bWUgcGFydCBvZiB0aGUgcHJvdG9jb2wgc2hvdWxkIGluZGljYXRlIHRoYXQgcGF0aCwgYW5kIGEg ZGlmZmVyZW50IHBhcnQgb2YgdGhlIHByb3RvY29sIHNob3VsZCBpbmRpY2F0ZSB0aGUgdHJlYXRt ZW50IG9yIHBvbGljeSBzZXQgdG8gYmUgdXNlZC4NCkVhcmxpZXIgaXQgd2FzIHN1Z2dlc3RlZCB0 aGF0IHRoZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIHNob3VsZCBiZSBpbiBhIGZpeGVkLXNpemUg aGVhZGVyLg0KDQpTbywgaW4gdGhlIGxpbWl0LCB0aGVyZSBjb3VsZCBiZSBhIHNpbmdsZSAoYmkt ZGlyZWN0aW9uYWwpIGZvcndhcmRpbmcgcGF0aCBvdmVyIHdoaWNoIG1pbGxpb25zIG9mIGRpZmZl cmVudCBwb2xpY3kgdHJlYXRtZW50cyBhcmUgY29udmV5ZWQuDQpFLmcuLCBvbmUgZm9yd2FyZGlu ZyBwYXRoIGZvciBlYWNoIGRpcmVjdGlvbiAocmVhbGx5IHR3byBwYXRocyksIHdpdGggc3Vic2Ny aWJlciBpZGVudGlmaWVyIGluIHRoZSBtZXRhLWRhdGEuIA0KDQpCZW5lZml0czoNCi0gZm9yd2Fy ZGluZyBlbGVtZW50cyBhcmUgYWdub3N0aWMgYWJvdXQgdGhlIG1ldGEtZGF0YSwga2VlcGluZyB0 aGUgZm9yd2FyZGluZyB0YWJsZXMgYXMgc21hbGwgYXMgcG9zc2libGUgYW5kIHVzaW5nIGZpeGVk LXNpemUgaGVhZGVycyBmb3Igb3B0aW1hbCBwZXJmb3JtYW5jZQ0KLSBTRnMgYXJlIGFnbm9zdGlj IGFib3V0IHRoZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLCB1c2luZyBvbmx5IHRoZSByZWxldmFu dCBtZXRhLWRhdGEuDQotIHRoZSBtZXRhLWRhdGEgaXMgbm90IHJlcXVpcmVkIGluIGV2ZXJ5IHBh Y2tldC4gRS5nLiwgaXQgY291bGQgYmUgc2VudCB3aXRoIHRoZSBmaXJzdCBwYWNrZXQgb2YgYSBs YXllcjQgY29ubmVjdGlvbiwgb3IgcGVyaGFwcyBvdXQgb2YgYmFuZC4NCg0KDQoNCi1EYXZlDQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMjYsIDIwMTQgMTA6MjEgQU0NClRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFy KQ0KQ2M6IENocmlzIEZyZWRlcmljazsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgU2h1 bnN1a2UgSG9tbWE7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0 aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCg0KSSBhZ3JlZSB3 aXRoIEppbS4NCg0KV2UgaGF2ZSBhbHNvIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJlIGF0IGxl YXN0IDIgYXBwcm9hY2hlcyB0byBkaWZmZXJlbnRpYXRlZCBwb2xpY3kgKip3aXRoaW4qKiBhIHNl cnZpY2UgZnVuY3Rpb24uICAgVGhlIGZpcnN0IGlzIHRoYXQgdGhlIHNlcnZpY2UgZnVuY3Rpb24g aXMgcmVzcG9uc2libGUgZm9yIGRldGVybWluaW5nIHdoaWNoIHBvbGljaWVzIHRvIGFwcGx5IGlu IGEgbWFubmVyIHRoYXQgaXMgcHJpdmF0ZSB0byBpdCAocGVyaGFwcyB1c2luZyBSQURJVVMsIG9y IExEQVAsIG9yIHNvbWUgb3RoZXIgZXh0ZXJuYWwgbG9va3VwIG1lY2hhbmlzbSkuICAgIFRoaXMg YXBwcm9hY2ggbWF5LCBpbiBzb21lIGNhc2VzLCBiZW5lZml0IGZyb20gYSBzdWJzY3JpYmVyIGlk ZW50aXR5IGJlaW5nIHBhc3NlZCBpbiB0aGUgaW5iYW5kIG1ldGFkYXRhLg0KDQpUaGUgc2Vjb25k LCB3aGljaCBpcyB3ZWxsIHN1aXRlZCB3aGVuIHRoZSBudW1iZXIgb2YgZGlzdGluY3QgcG9saWN5 IHNldHMgaXMgc21hbGwgKGUuZy4sIGNvbnRlbnQtZmlsdGVyLWFkdWx0LCBjb250ZW50LWZpbHRl ci1jaGlsZCksIGlzIHRvIG1vZGVsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGFzIGhhdmluZyBtdWx0 aXBsZSBsb2dpY2FsIGluc3RhbmNlcyBvZiBpdHNlbGYsIGVhY2ggaW1wbHlpbmcgYSBkaXN0aW5j dCBwb2xpY3kgc2V0LiAgIEluIHRoaXMgYXBwcm9hY2gsIFNGQ3MgYXJlIGJ1aWx0IHN1Y2ggdGhh dCBhbnkgZ2l2ZW4gY2hhaW4gd291bGQgaW5jbHVkZSBhdCBtb3N0IG9uZSBvZiB0aGUgbG9naWNh bCBpbnN0YW5jZXMuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0g DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE0IDk6NDIgQU0NClRvOiBSb24gUGFy a2VyDQpDYzogU2h1bnN1a2UgSG9tbWE7IENocmlzIEZyZWRlcmljazsgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBB Y3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpSaWdodCBh bmQgdGhlIHBvaW50IGJlaW5nIHdoYXQgeW91IHdhbnQgdG8gZG8gaXMgc2hhcmUgU0ZDcyBhY3Jv c3Mgc3Vic2NyaWJlcnMgYW5kIGltcGxlbWVudCB3aXRoaW4gdGhlIFNGQyBhbnkgZGlmZmVyZW50 aWF0aW9uIGluIHRlcm1zIG9mIHBvbGljeSBmb3Igc3Vic2NyaWJlcnMgdGhhdCBjb25zdW1lIHRo ZSBzYW1lIHNldCBvZiBzZXJ2aWNlcy4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIEZl YiAyNiwgMjAxNCwgYXQgNzozMiBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IEV2ZW4gaWYgc3Vic2NyaWJlcnMgY2FuIHNlbGYg Y29uZmlndXJlIHRoZWlyIHNlcnZpY2VzIHZpYSBhIHBvcnRhbCwgdGhlIG51bWJlciBvZiBkaXN0 aW5jdCBjb21iaW5hdGlvbnMgdGhhdCBhcmlzZSB3aWxsIHN0aWxsIGJlIGZpbml0ZS4gIFRoYXQg aXMsIGluIGEgcG9wdWxhdGlvbiBvZiAxMDAwMDAwMDAgc3Vic2NyaWJlcnMsIHN1cmVseSBzb21l IHdpbGwgZW5kIHVwIHdpdGggZXF1aXZhbGVudCBzZXJ2aWNlcz8NCj4gDQo+ICAgUm9uDQo+IA0K Pj4gT24gRmViIDI2LCAyMDE0LCBhdCAyOjI1IEFNLCAiU2h1bnN1a2UgSG9tbWEiIDxob21tYS5z aHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+IA0KPj4gSGkgQ2hyaXMsIFJvbiwNCj4+ IA0KPj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4gDQo+PiBJIHVuZGVyc3Rvb2QgdGhh dCB5b3Ugc2FpZC4NCj4+IEFuZCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG1ldGhvZCB1c2lu ZyBtZXRhZGF0YSBpcyBvbmUgb2YgdGhlIG1ldGhvZHMgZm9yIHJlY29nbml6aW5nIHN1YnNjcmli ZXJzLg0KPj4gQnV0IHRoaXMgcHJvYmxlbSBpcyBpbXBsZW1lbnRhdGlvbiBtYXR0ZXJzLCBzbyBp dCBpcyBub3QgYXQgdGhlIHN0YWdlIGZvciBkaXNjdXNzaW9uIHlldCwgSSB0aGluay4NCj4+IA0K Pj4gV2hhdCBJIHdhbnQgdG8gc2F5IGlzIHRoYXQgdGhlcmUgYXJlIHJlcXVlc3RzIGZvciBkaXN0 aW5jdCBzZXJ2aWNlcyBwZXIgc3Vic2NyaWJlciwgc28gdGhhdCBTRkMgYXJjaGl0ZWN0dXJlIHNo b3VsZCBiZSBzY2FsYWJsZS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gU2h1bnN1a2UNCj4+ IA0KPj4gDQo+PiAoMjAxNC8wMi8yNSAyMzo0OSksIFJvbiBQYXJrZXIgd3JvdGU6DQo+Pj4gRXhw YW5kaW5nIG9uIENocmlzJyBjb21tZW50cywgSSBkb24ndCB0aGluayB0aGUgcHJhY3RpY2FsIGxp bWl0YXRpb25zIGFyZSB3cnQgdGhlIG51bWJlciBvZiBmdWxseS1xdWFsaWZpZWQgNS10dXBsZXMs IGJ1dCByYXRoZXIgdGhlIG51bWJlciBvZiBkaXN0aW5jdCB0cmVhdG1lbnQgc2VxdWVuY2VzIHRo YXQgYXJpc2UgZnJvbSB0aG9zZSBmbG93cy4gICBPZiB0aGUgMTAwJ3Mgb2YgbWlsbGlvbnMgb2Yg Zmxvd3MgdGhhdCBtaWdodCBiZSB0cmFja2VkIGJ5IGEgaGlnaCBlbmQgY2xhc3NpZmllciwgcGVy aGFwcyB0aGUgbnVtYmVyIG9mIHVuaXF1ZSBzZXF1ZW5jZXMgdGhhdCBhcmlzZSBhcmUgaW4gdGhl IDEwMDAncy4gICAgSWYgYXBwbHlpbmcgYSBmaXhlZC1saW5lIG9yIG1vYmlsZSBzZXJ2aWNlIHBy b3ZpZGVyIHBlcnNwZWN0aXZlLCB0aGUgbnVtYmVyIG9mIGNoYWlucyB3b3VsZCBiZSBwcm9wb3J0 aW9uYWwgdG8gdGhlIG51bWJlciBvZiBkaXN0aW5jdCBlbmQtdG8tZW5kIHNlcnZpY2UgcGxhbnMg b2ZmZXJlZCBhbmQgdGhlbiBtdWx0aXBsaWVkIGJ5IHRoZSBmbG93LWF3YXJlIHN1YnNldHRpbmcg dGhhdCBjYW4gYmUgbWFuYWdlZCBieSB0aGUgY2xhc3NpZmllciAoaS5lLiwgc3Vic2NyaWJlciBp cyBzdWJqZWN0IHRvIHNlcnZpY2UgZnVuY3Rpb24gQSB0aGVuIEIgdGhlbiBDIGJ1dCBCIG9ubHkg bmVlZHMgVENQLzgwIHRyYWZmaWMsIEEgb25seSBuZWVkcyBVRFAgdHJhZmZpYywgLi4uKS4NCj4+ PiANCj4+PiAgIFJvbg0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4gRnJvbTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0BzYW5kdmluZS5j b21dDQo+Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjUsIDIwMTQgOTo0NCBBTQ0KPj4+IFRv OiBTaHVuc3VrZSBIb21tYTsgUm9uIFBhcmtlcg0KPj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEktRCBB Y3Rpb246IA0KPj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+ IA0KPj4+IEhpIFNodW5zdWtlLXNhbiwNCj4+PiBJIHJlY29nbml6ZSB0aGF0IHVsdGltYXRlbHks IHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVjaXNpb24gYW5kIG5vdCBzb21ldGhpbmcgdG8g YmUgbWFuZGF0ZWQgYXMgYSBoYXJkICdydWxlJy4gSSBqdXN0IHdhbnRlZCB0byBoaWdobGlnaHQg d2hhdCBpcyBwb3NzaWJsZSArIHdoYXQgd2UgYmVsaWV2ZSB0byBiZSBiZXN0IHByYWN0aWNlcyBp biB0aGlzIGFyZWEsIGJhc2VkIG9uIG91ciBleHBlcmllbmNlLg0KPj4+IFRoYXQgc2FpZCwgeWVz LCBJIGJlbGlldmUgdGhhdCBpbiBwcmFjdGljYWwgKHJlYWwtd29ybGQpIHRlcm1zLCBpdCBtYWtl cyBzZW5zZSB0byBkZWVtcGhhc2l6ZSB0aGUgJyhyZSljbGFzc2lmaWNhdGlvbicgcm9sZSBvZiBT RnMgaW4gbW9zdCBjYXNlcywgZm9yIHJlYXNvbnMgSSd2ZSBzdGF0ZWQgcHJldmlvdXNseSAocXVl c3Rpb25zIG9mIG1ldGFkYXRhIHNoYXJpbmcgYmV0d2VlbiBTRnMsIGlzc3VlcyByZWxhdGVkIHRv IHJldGFpbmluZyBpbnRlZ3JpdHkgb2YgY2hhaW5zL2JyZWFraW5nIGZsb3dzLCBldGMuKS4NCj4+ PiBUbyB5b3VyIGNvbW1lbnQgYWJvdXQgc2NhbGluZyB0aGUgU0ZDIENvbnRyb2xsZXIsIEkgd291 bGQganVzdCBzYXkgdGhhdCB0aGVyZSBhcmUgY29tbWVyY2lhbGx5IGRlcGxveWVkIFNGQyBDb250 cm9sbGVycyB0b2RheSB0aGF0IGRvIHRoaXMsIGkuZS4gc2l0IGlubGluZSBpbiBjb25zdW1lciBu ZXR3b3JrcywgcmVjZWl2ZS9pbnNwZWN0IG1pbGxpb25zIG9mIGNvbmN1cnJlbnQgYmlkaXJlY3Rp b25hbCBmbG93cywgKyBtYWtlIHJlYWwtdGltZSBTRkMgc3RlZXJpbmcgYW5kIHNlcXVlbmNpbmcg ZGVjaXNpb25zIGJhc2VkIG9uIGZsb3csIHN1YnNjcmliZXIsIHNlc3Npb24sIGFuZCBuZXR3b3Jr IGNvbmRpdGlvbnMuDQo+Pj4gT2J2aW91c2x5LCBkaWZmZXJlbmNlcyBpbiB2ZW5kb3IgY2FwYWJp bGl0aWVzLCBhcyB3ZWxsIGFzIA0KPj4+IGFyY2hpdGVjdHVyYWwgZGVjaXNpb25zIHZpeiBjb25z b2xpZGF0aW5nIHZzLiBkaXN0cmlidXRpbmcgZGlmZmVyZW50IA0KPj4+IFNGQyBmdW5jdGlvbnMg bGlrZSBmbG93IGNsYXNzaWZpY2F0aW9uLCBQRFAvU0ZDIENvbnRyb2xsZXIsIA0KPj4+IHN0ZWVy aW5nL2xiLCBldGMsIGFsbCB3aWxsIGhhdmUgYW4gaW1wYWN0IGhlcmUuIEJlc3QsIC9jDQo+Pj4g DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBTaHVuc3VrZSBIb21t YSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanBdDQo+Pj4gU2VudDogVHVlc2Rh eSwgRmVicnVhcnkgMjUsIDIwMTQgNzoyNSBBTQ0KPj4+IFRvOiBDaHJpcyBGcmVkZXJpY2s7IFJv biBQYXJrZXINCj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiANCj4+PiBkcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+PiANCj4+PiBIaSBDaHJpcywNCj4+ PiANCj4+PiBEbyB5b3UgbWVhbiB0aGF0LCBmb3IgcmV0YWluaW5nIGludGVncml0eSBvZiBjaGFp bnMsIG1hbmFnZW1lbnQgb2Ygc3Vic2NyaWJlcnMgc2hvdWxkIGJlIHByb3ZpZGVkIG5vdCBieSBT RnMsIGJ1dCBieSBTRkMgY29udHJvbGxlcj8NCj4+PiANCj4+PiBJZiBzbywgdGhlIHByb2JsZW0g aXMgdGhhdCB0aGUgbnVtYmVyIG9mIGNoYWlucyB0aGF0IFNGQyBjb250cm9sbGVyIG11c3QgbWFu YWdlIGlzIGxhcmdlLCBhbmQgaXQgaXMgdGhlIHNhbWUgcHJvYmxlbSBJIHNhaWQsIEkgdGhpbmsu DQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBTaHVuc3VrZQ0KPj4+IA0KPj4+ICgyMDE0 LzAyLzI1IDE0OjE3KSwgQ2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPj4+PiBIaSBTaHVuc3VrZS1z YW4sDQo+Pj4+IEkgYWNrbm93bGVkZ2UgdGhlIGNvbW1lbnRzIGFib3V0IHRoZXNlIGJlaW5nIGlt cGxlbWVudGF0aW9uIA0KPj4+PiBtYXR0ZXJzLCBidXQgSSd2ZSBvZmZlcmVkIHNvbWUgdGhvdWdo dHMgaW5saW5lIHdpdGggeW91ciBtYWlsIA0KPj4+PiBiZWxvdy4gVGh4LCAvYw0KPj4+PiANCj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogU2h1bnN1a2UgSG9tbWEg W21haWx0bzpob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwXQ0KPj4+PiBTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDI0LCAyMDE0IDk6MDAgUE0NCj4+Pj4gVG86IENocmlzIEZyZWRlcmljazsgUm9u IFBhcmtlcg0KPj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4gZHJhZnQt Ym91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+IA0KPj4+PiBIaSBSb24sIENo cmlzLA0KPj4+PiANCj4+Pj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4+PiANCj4+Pj4g SSB0aGluayB0aGF0IHlvdXIgcG9pbnRzIGFyZSBmb2xsb3dpbmc6DQo+Pj4+IGluIGNhc2UgdGhh dCB0aGVyZSBhcmUgc29tZSBTRnMgYXMgdXNlciBjdXN0b21pemVkLCBwZXItc3Vic2NyaWJlciBT RkNzIHNob3VsZG4ndCBiZSBtYWRlLCBidXQgdGhlIFNGcyBzaG91bGQgcmVjb2duaXplIHN1YnNj cmliZXJzIGJ5IElQIGFkZHJlc3Mgb3IgbWV0YWRhdGEuDQo+Pj4+IENGPj4gTXkgcG9pbnQgd2Fz IHRoYXQgSSBkb24ndCBzZWUgaXQgYXMgZGVzaXJhYmxlIHRvIGhhdmUgc3BlY2lmaWMgcGVyLXN1 YnNjcmliZXIgU0ZDIHJ1bGVzIChhcyBpbiBzdGF0aWMgcnVsZXMsIGxpa2Ugc3Vic2NyaWJlcl9D aHJpcz1TRkNfYV9iX2MpLCB3aXRoIGEgcnVsZSBmb3IgZXZlcnkgc3ViLCBpbiB0aGF0IHNlbnNl LiBCZXR0ZXIgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgU0ZDIGNoYWluIGNvbnRyb2xsZXIgaXMg c3Vic2NyaWJlci1hd2FyZSArIGFibGUgdG8gZXZhbHVhdGUgbXVsdGlwbGUgb3J0aG9nb25hbCBm bG93ICsgc3Vic2NyaWJlciBjb25kaXRpb25zIGluIHJlYWwgdGltZSwgYW5kIGZvcm11bGF0ZSBh IGNoYWluIG9uIHRoZSBiYXNpcyBvZiB0aG9zZSBkeW5hbWljIGNvbmRpdGlvbnMuDQo+Pj4+IA0K Pj4+PiBPZiBjb3Vyc2UsIGl0IGlzIG9uZSBvZiB0aGUgc29sdXRpb25zLg0KPj4+PiBIb3dldmVy LCBpbiB0aGlzIGNhc2UsIEkgdGhpbmsgdGhhdCBTRnMgYXMgdXNlciBjdXN0b21pemVkIG1pZ2h0 IGJlIHJlcXVpcmVkIHRvIGhhdmUgYSBmdW5jdGlvbiB0byByZWNvZ25pemUgZWFjaCBzdWJzY3Jp YmVyLg0KPj4+PiBDRj4+IEkgd2Fzbid0IGFjdHVhbGx5IHRoaW5raW5nIGluIHRlcm1zIG9mIFNG IChyZSljbGFzc2lmaWNhdGlvbjsgSSd2ZSBwcmV2aW91c2x5IGNvbW1lbnRlZCBvbiB3aHkgSSB0 aGluayB0aGF0IGlkZWEgaXMgc29tZXdoYXQgZnJhdWdodCAoaS5lLiBiZWNhdXNlIG1vZGlmaWNh dGlvbiBvZiB0aGUgZmxvdyBwYXRoIGJ5IGEgc2VydmljZSBmdW5jdGlvbiB3aXRoaW4gdGhlIGNo YWluIGNvdWxkIHJlc3VsdCBpbiBhICdicmVha2luZycgb2YgdGhlIGNoYWluIG9yIGZsb3cuIElm IHRoZXJlIGlzIG5vdCBiaWRpcmVjdGlvbmFsIHN5bW1ldHJ5IGluIHRoZSBmbG93IGFuZCBzZXJ2 aWNlIGZ1bmN0aW9uIGVsZW1lbnRzIGluIHRoZSBjaGFpbiBjYW4gbWFrZSByb3V0aW5nIGRlY2lz aW9ucywgdGhlbiB0aGVyZSdzIHNvbWUgbWV0YWRhdGEgY29ycmVsYXRpb24gdG8gd29yayBvdXQs IGF0IG1pbmltdW0pLiBJIGRvIGFncmVlIHRoYXQgdGhlIFNGQyBjaGFpbiBjb250cm9sbGVyIHdv dWxkIG5lZWQgdG8gYmUgc3Vic2NyaWJlci1hd2FyZSB0aG91Z2guDQo+Pj4+IA0KPj4+PiBPbiB0 aGUgb3RoZXIgaGFuZCwgSSB0aGluayB0aGF0IHRoZXJlIGFyZSBjYXNlcyB3aGVuIHRoZSBmdW5j dGlvbiBjYW4ndCBiZSBhZG9wdGVkLCBzdWNoIGxpa2UgU0ZzIGFyZSBjdXJyZW50IGVxdWlwbWVu dCB0aGF0IGRvbid0IGhhdmUgZnVuY3Rpb24gdG8gcmVjb2duaXplIG1ldGFkYXRhLg0KPj4+PiBD Rj4+IEFncmVlZC4gVGhpcyBzcGVha3MgdG8gbXkgY29tbWVudCBhYm92ZSArIHRvIHRoZSBhZHZh bnRhZ2VzIHNvbWUgb2YgdXMgaGF2ZSBtZW50aW9uZWQgdml6IGEgY29uc29saWRhdGVkIHBvbGlj eS1iYXNlZCBzdGVlcmluZy9QRFAvU0ZDIGNoYWluIGNvbnRyb2xsZXIgZW50aXR5Lg0KPj4+PiAN Cj4+Pj4gSG93IGRvIHdlIGhhbmRsZSB0aGVzZSBjYXNlcz8NCj4+Pj4gQW55IG5ldyBwcm9ibGVt cyBvciByZXF1aXJlbWVudHMgbWF5IG9jY3VyPw0KPj4+PiANCj4+Pj4gcmVnYXJkcywNCj4+Pj4g DQo+Pj4+IFNodW5zdWtlDQo+Pj4+IA0KPj4+PiAoMjAxNC8wMi8yNSA4OjQ2KSwgQ2hyaXMgRnJl ZGVyaWNrIHdyb3RlOg0KPj4+Pj4gWWVzLCBhZ3JlZWQgb24gdGhhdC4NCj4+Pj4+IA0KPj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0 bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5LCBG ZWJydWFyeSAyNCwgMjAxNCA2OjQ1IFBNDQo+Pj4+PiBUbzogQ2hyaXMgRnJlZGVyaWNrOyDmnKzp lpPkv4rku4sNCj4+Pj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0 Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4+IGRy YWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+Pj4+PiBUaGFu a3MsIENocmlzLg0KPj4+Pj4gDQo+Pj4+PiBJIGRvIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9mIGVm ZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNsYXNzaWZpZXIpIGFuZCBwb2xpY3kg ZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhvd2V2ZXIsIGFyY2hpdGVjdHVyYWxs eSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBjby1sb2NhdGVkLg0KPj4+Pj4gDQo+ Pj4+PiAgICAgIFJvbg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNrQHNh bmR2aW5lLmNvbV0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNToyNiBQ TQ0KPj4+Pj4gVG86IFJvbiBQYXJrZXI7IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6IFtz ZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVu dHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+IEFncmVlZC4NCj4+Pj4+IFRvIHJlc3RhdGUgdGhpcyBz bGlnaHRseSwgaWYgdGhlIFNGQyBzdGVlcmluZy9kZWNpc2lvbiBsb2N1cyBpcyBjYXBhYmxlIG9m IGV2YWx1YXRpbmcgbXVsdGlwbGUgb3J0aG9nb25hbCBwb2xpY3kgY29uZGl0aW9ucyB0aGVuIHRo aXMgaXNzdWUgaXMgb2J2aWF0ZWQ7IHN1YnNjcmliZXJzIGJlY29tZSBhbiBhZ2dyZWdhdGUgb2Yg J3doYXQgdGhleSBhcmUnICsgYXJlIG5vdCBzaW1wbHkgJ3dobyB0aGV5IGFyZScuDQo+Pj4+PiBB cyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkgYmUgZGVyaXZlZCBmcm9tIExEQVAgbG9v a3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQgcnVsZXMsIGV0Yy4NCj4+Pj4+IFRvIGls bHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5IHNvbWV0aGluZyBsaWtlIHRoaXM6 DQo+Pj4+PiBJZiBzdWJzY3JpYmVyIFggaXMgdXNpbmcgeW91dHViZSwgYW5kIGlzIG9uIGEgY29u Z2VzdGVkIGNlbGwsIGFuZCBpcyBvbiBhbiBpUGhvbmUsIGFuZCBpcyBpbiB0aGUgIkdvbGQgVGll ciIsIGFuZCwgYW5kLCBhbmQsIGFuZCwgZXRjLCB0aGVuIHRoZSBjaGFpbiBjb25zaXN0cyBvZiBz ZXJ2aWNlIGZ1bmN0aW9ucyBhLCBiLCBhbmQgYy4NCj4+Pj4+IFRoZXJlJ3Mgbm8gbmVlZCB0byBl bnRlciBhIHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChvciBhbnkgc3Vi c2NyaWJlcikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVjYXVzZSBhbGwg b2YgdGhlIGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNhdmUgb25lICgi aXMgb24gYSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFpbiBtaWdodCBi ZSBhbHRlcmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlvbiBzZXJ2aWNl IGZ1bmN0aW9uKS4NCj4+Pj4+IFRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJsaWVyIGNvbW1lbnRz IFJvbiArIEkgbWFkZSBhYm91dCANCj4+Pj4+IGNvbnNvbGlkYXRpbmcgdGhlIGZsb3cgcmVjb2du aXRpb24gKyBkZWNpc2lvbi1tYWtpbmcgZW50aXR5IGluIGEgDQo+Pj4+PiBzaW5nbGUgKHN1aXRh Ymx5IHBvbGljeS1hd2FyZSkgbm9kZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgKyB0byANCj4+ Pj4+IHNjYWxlIHByb3Blcmx5LiBUaHgsIC9jDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINCj4+Pj4+IFNlbnQ6IFN1bmRheSwgRmVicnVhcnkg MjMsIDIwMTQgMTA6MzkgUE0NCj4+Pj4+IFRvOiDmnKzplpPkv4rku4sNCj4+Pj4+IENjOiBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWly ZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+Pj4+PiBTaHVuc3VrZS1zYW4sDQo+Pj4+PiANCj4+Pj4+ IFdoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9yIG1vcmUgU0ZD cyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBpc24ndCBwcmFjdGlj YWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBhc3BlY3Qgb2YgdGhl IHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3VzdG9taXplZCBmaXJl d2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBvbmx5IG9uZSBm aXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2FsIHBvbGljeSBldmFs dWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBiZSB2 YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3b3VsZCBiZSB0byBz aW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9tIHRoZSBwYWNr ZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtlIExEQVAgb3IgUkFE SVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBkZXRlcm1pbmUgd2hv IHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNzaWZpZXIgdG8gYWRk IGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2VydmljZSBoZWFk ZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQgdGhlIGZpcmV3YWxs Lg0KPj4+Pj4gDQo+Pj4+PiBJZiB0aGUgcHJvYmxlbSBpcyBjaGFuZ2VkIHNsaWdodGx5IHNvIHRo YXQgdGhlIGZpcmV3YWxsIHBvbGljeSBpcyBwZXIgZ3JvdXAgb2Ygc3Vic2NyaWJlcnMsIHdoZXJl IHRoZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4geWV0IGFub3RoZXIgYXBwcm9h Y2ggaXMgdG8gbW9kZWwgdGhlIGZpcmV3YWxsIGFzIGEgZGlzdGluY3QgbG9naWNhbCBmaXJld2Fs bCBwZXIgZmlyZXdhbGwgcG9saWN5IHNldCAodGhleSBjb3VsZCBhbGwgcmVzaWRlIGluIHRoZSBz YW1lIG1hY2hpbmUgb3IgVk0pIGFuZCB0byBjb29yZGluYXRlIHRoZSBjbGFzc2lmaWVyJ3MgcG9s aWN5IGFjY29yZGluZ2x5Lg0KPj4+Pj4gDQo+Pj4+PiAgICAgUm9uDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4+IE9uIEZlYiAyMywgMjAxNCwgYXQgMTA6MDQgUE0sICLmnKzplpPkv4rku4siIDxob21t YS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBIaSBNZWQs DQo+Pj4+Pj4gDQo+Pj4+Pj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJIGFzc3VtZWQgc29t ZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4gY29udGludWUgdGhl IGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMuDQo+Pj4+Pj4gI0kg d29yayB3aXRoIEsuTmFpdG8sIGNvLWF1dGhvciBvZiByZXF1aXJlbWVudCBkcmFmdCBhbmQgdGhp bmsgc2NhbGFiaWxpdHkgaXMgb25lIG9mIGltcG9ydGFudCB0aGluZ3MgdG8gY29uc2lkZXIuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gQXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5nLCB0 aGUgbWFuYWdlbWVudCBtZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWlnaHQg cmVxdWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPj4+Pj4+IA0KPj4+Pj4+IDEuIFRoZSBjYXNlIHRo YXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPj4+Pj4+IEkgYXNzdW1lZCB0aGF0IHRoZSB1 bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4+Pj4+PiAgIC0g Z3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBz ZXJ2aWNlLA0KPj4+Pj4+ICAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9yIHJlZ2lvbiwNCj4+Pj4+ PiAgIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNG QyBmb3IgZWFjaOOAgA0KPj4+Pj4+ICAgICBzdWJzY3JpYmVyIChlLmcuIHBlciBJUCBhZGRyZXNz LCBWTEFOIElEIGV0LmFsKSwNCj4+Pj4+PiAgIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMgYXBwbGll ZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPj4+Pj4+IOOAgOOAgGFu ZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0KPj4+Pj4+IA0K Pj4+Pj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVtYmVy IG9mIHN1YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0byBz ZXZlcmFsIHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNlcyBv ZiBwZXItc3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdodCBp bmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVkZWQg aW4gdGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2ggdXNl cihlLmcuIHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4+Pj4+PiANCj4+Pj4+PiBBbHNvLCBp biBjYXNlIG9mIGdyb3VwaW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3NlIHBv bGljaWVzIGFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIgYW5k IHBlciByZWdpb24sIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBGaXJl d2FsbHMgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9tZXIp Lg0KPj4+Pj4+IA0KPj4+Pj4+IDIuIFRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0ZzIHRo YXQgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlOg0KPj4+Pj4+IEluIGNhc2Ug dGhhdCB0aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNhbWUgZnVuY3Rpb24gaW4gdGhlIG5ldHdvcmsg YW5kIHRoZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlLCB0aGUgY29t YmluYXRpb24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNlLg0KPj4+Pj4+IFRoZSBTRnMgdGhhdCBwcm9j ZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBiZSBkaWZmZXJlbnRpYXRlZCBwZXIg aW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNhY2hlLCBhbmQgVmlkZW8tT3B0aW1p emVyKS4NCj4+Pj4+PiANCj4+Pj4+PiBJTUhPLHJlcXVpcmVtZW50cyBmb3Igc2NhbGFiaWxpdHkg d2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1hdC4NCj4+Pj4+PiAN Cj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gDQo+Pj4+Pj4gU2h1bnN1a2UNCj4+Pj4+PiANCj4+Pj4+ PiAoMjAxNC8wMi8xMiAxODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6 DQo+Pj4+Pj4+IERlYXIgYWxsLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhpcyBuZXcgdmVyc2lvbiBp bnRlZ3JhdGVzIGlucHV0cyBmcm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBUaGUgZGlmZiBjYW4gYmUgdHJhY2tlZCBoZXJlOg0KPj4+Pj4+PiBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50DQo+Pj4+ Pj4+IHMtMA0KPj4+Pj4+PiAxDQo+Pj4+Pj4+ICYNCj4+Pj4+Pj4gZGlmZnR5cGU9LS1odG1sJnN1 Ym1pdD1HbyEmdXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cw0KPj4+Pj4+PiAt MDMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVkDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4gRGUgOiBJLUQtQW5ub3Vu Y2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgDQo+Pj4+Pj4+ IHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVudm95w6kgOiBtZXJjcmVkaSAxMiBm w6l2cmllciANCj4+Pj4+Pj4gMjAxNCAxMDo0NiDDgA0KPj4+Pj4+PiA6IGktZC1hbm5vdW5jZUBp ZXRmLm9yZyBPYmpldCA6IEktRCBBY3Rpb246DQo+Pj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMt cmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcN Cj4+Pj4+Pj4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTW9oYW1lZCBCb3VjYWRhaXINCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0aWFuIEphY3F1ZW5ldA0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBZdWFubG9uZyBKaWFuZw0KPj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb24gUGFya2VyDQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgS2VuZ28gTmFpdG8NCj4+Pj4+Pj4gICAgIEZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4+PiAgICAgUGFnZXMg ICAgICAgICAgIDogMTQNCj4+Pj4+Pj4gICAgIERhdGUgICAgICAgICAgICA6IDIwMTQtMDItMTIN Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+PiAgICAgVGhpcyBkb2N1bWVudCBp ZGVudGlmaWVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uDQo+Pj4+ Pj4+ICAgICBDaGFpbmluZyAoU0ZDKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFp ci1zZmMtcmVxdWlyZW1lbnQNCj4+Pj4+Pj4gcy8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMw0KPj4+ Pj4+PiANCj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KPj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1i b3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50DQo+Pj4+Pj4+IHMtMA0KPj4+Pj4+PiAzDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgDQo+Pj4+Pj4+IG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QN Cj4+Pj4+Pj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+Pj4+Pj4+IEludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIA0KPj4+Pj4+ PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiAtLQ0KPj4+Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+Pj4+Pj4g5pys6ZaTIOS/iuS7iyAoSG9tbWEgU2h1bnN1a2UpDQo+Pj4+Pj4gDQo+ Pj4+Pj4g5pel5pys6Zu75L+h6Zu76Kmx5qCq5byP5Lya56S+DQo+Pj4+Pj4g44ON44OD44OI44Ov 44O844Kv44K144O844OT44K544K344K544OG44Og56CU56m25omADQo+Pj4+Pj4g6Lui6YCB44K1 44O844OT44K55Z+655uk44OX44Ot44K444Kn44Kv44OIDQo+Pj4+Pj4g6Lui6YCB44K144O844OT 44K55Yi25b6hRFANCj4+Pj4+PiANCj4+Pj4+PiDjgJIxODAtODU4NeOAgOadseS6rOmDveatpuiU temHjuW4gue3keeUujMtOS0xMQ0KPj4+Pj4+IFRFTDogMDQyMi01OS0zNDg2DQo+Pj4+Pj4gRS1N QUlMOiBob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwDQo+Pj4+Pj4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRm Lm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0NCj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBTaHVuc3VrZSBIb21t YQ0KPj4+PiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+Pj4gVEVMOiArODEgMDQy MiA1OSAzNDg2DQo+Pj4+IEZBWDogKzgxIDA0MjIgNjAgNzQ2MA0KPj4+PiANCj4+Pj4gTlRUIE5l dHdvcmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4+Pj4gTXVzYXNoaW5vIGNpdHksIFRva3lvLCBK YXBhbg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWls aW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gU2h1bnN1a2UgSG9tbWENCj4+PiA8aG9tbWEuc2h1 bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+PiBURUw6ICs4MSAwNDIyIDU5IDM0ODYNCj4+PiBGQVg6 ICs4MSAwNDIyIDYwIDc0NjANCj4+PiANCj4+PiBOVFQgTmV0d29yayBTZXJ2aWNlIFN5c3RlbSBM YWJzLg0KPj4+IE11c2FzaGlubyBjaXR5LCBUb2t5bywgSmFwYW4NCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3Jn DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+IA0KPj4g DQo+PiAtLQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gU2h1bnN1 a2UgSG9tbWENCj4+IDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPg0KPj4gVEVMOiArODEg MDQyMiA1OSAzNDg2DQo+PiBGQVg6ICs4MSAwNDIyIDYwIDc0NjANCj4+IA0KPj4gTlRUIE5ldHdv cmsgU2VydmljZSBTeXN0ZW0gTGFicy4NCj4+IE11c2FzaGlubyBjaXR5LCBUb2t5bywgSmFwYW4N Cj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBz ZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo= From nobody Wed Feb 26 08:03:30 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE4F1A06A4 for ; Wed, 26 Feb 2014 08:03:20 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnakzTEJrOdQ for ; Wed, 26 Feb 2014 08:03:13 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id C3DB01A0454 for ; Wed, 26 Feb 2014 08:03:13 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Wed, 26 Feb 2014 08:03:12 -0800 From: Ron Parker To: Dave Dolson , "Jim Guichard (jguichar)" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAlJICAADdIgIAAd4eAgAAmpID//3oy0IABnfKA///POEAAFVOxAAAPntoA//+WE4CAAIXEgA== Date: Wed, 26 Feb 2014 16:03:11 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/b1Ju68kBoB4wypbN_DzSK2AJwWE Cc: Chris Frederick , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 16:03:21 -0000 RGF2ZSwNCg0KSSBmaW5kIHRoZSBjb252ZXlhbmNlIG9mIGEgcG9saWN5IGtleSBmcm9tIHRoZSBj bGFzc2lmaWVyIHRvIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB2ZXJ5IGF0dHJhY3RpdmUuICAgDQoN Ckhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgYSBnbG9iYWwga2V5IHRoYXQgaXMgaW50ZXJwcmV0ZWQg ZXF1YWxseSBieSBhbGwgc2VydmljZSBmdW5jdGlvbnMgaXMgcHJhY3RpY2FsLiAgIFNvbWUgc2Vy dmljZSBmdW5jdGlvbnMgbWF5IGhhdmUgb25seSBhIHZlcnkgc21hbGwgcXVhbnRpdHkgb2YgcG9s aWN5IHNldHMgd2hpbGUgb3RoZXJzIG1heSBiZSB2ZXJ5IGdyYW51bGFyLiAgICAgV2l0aCBhIGds b2JhbCBrZXksIHdoZW4gYWRkaXRpb25hbCBwb2xpY3kgc2V0cyBhcmUgYWRkZWQgdG8gc29tZSBz ZXJ2aWNlIGZ1bmN0aW9uLCBhbGwgc2VydmljZSBmdW5jdGlvbnMgd291bGQgbmVlZCB0byBrbm93 IGhvdyB0byB0cmFuc2xhdGUgdGhvc2UgbmV3IGdsb2JhbCBrZXlzIGludG8gc29tZXRoaW5nIGxv Y2FsbHkgc2lnbmlmaWNhbnQuICAgIA0KDQpBbiBhbHRlcm5hdGl2ZSwgcHVzaGluZyBhIHN0YWNr IG9mIHBlci1zZXJ2aWNlLWZ1bmN0aW9uIHBvbGljeSBrZXlzIG9udG8gdGhlIHBhY2tldCBzbyB0 aGF0IGVhY2ggc2VydmljZSBmdW5jdGlvbiBjYW4gc2VlIGl0cyBvd24gbG9jYWxseSBzaWduaWZp Y2FudCBwb2xpY3kga2V5LCBoYXMgaXRzIGlzc3VlcywgdG9vLCBzaW5jZSBpdCBpcyB0aGVvcmV0 aWNhbGx5IHVuYm91bmRlZCBhbmQgYWRkcyBvdmVyaGVhZCB0byBldmVyeSBwYWNrZXQuDQoNCkEg cG9zc2libGUgd29ya2Fyb3VuZCB0byB0aGUgc3RhY2sgb2YgcG9saWN5IGtleXMgaXMgdG8gc2ln bmFsIHRoaXMgaW4gYSBjb250cm9sIHBsYW5lIGZyb20gdGhlIGNsYXNzaWZpZXIgdG8gdGhlIHNl cnZpY2UgZnVuY3Rpb25zLiAgIEJ1dCwgc2lnbmFsaW5nIGF0IHRoZSBtaWNyby1mbG93IGxldmVs IGlzIHZlcnkgaW1wcmFjdGljYWwgaW4gdGVybXMgb2Ygc2NhbGUgYW5kIGFkZHMgc2lnbmlmaWNh bnQgY29tcGxleGl0eSB0byBhdm9pZCB0aGUgZmlyc3QgcGFja2V0IHJhY2UgY29uZGl0aW9uIHRo YXQgY291bGQgYXJpc2UuICAgSW4gbXkgb3BpbmlvbiwgdGhlIGNvbnRyb2wgcGxhbmUgc2hvdWxk IG9wZXJhdGUgYXQgdGhlIGNoYWluIHNldHVwIGFuZCBtYWludGVuYW5jZSBsZXZlbCBhbmQgbm90 IGF0IHRoZSBtaWNyb2Zsb3cgbGV2ZWwuDQoNCkxhc3RseSwgYW4gYXBwcm9hY2ggdGhhdCBJIHRo aW5rIGNvdWxkIHdvcmsgZm9yIGJpZGlyZWN0aW9uYWwgZmxvd3MgKHRoZSB2YXN0IG1ham9yaXR5 IG9mIHByYWN0aWNhbCB1c2UgY2FzZXMsIElNTykgaXMgdG8gaGF2ZSBhbiBpbmJhbmQgbWVjaGFu aXNtIHRvIGRlbGl2ZXIgbG9uZyBsaXZlZCBtZXRhZGF0YS4gICAgVGhlIHN0YWNrIG9mIHBvbGlj eSBrZXlzIGNvdWxkIGJlIGRlbGl2ZXJlZCBpbmJhbmQgaW4gdGhlIGZpcnN0IE4gcGFja2V0cyBv ZiB0aGUgZmxvdy4gICAgVGhlIHJldmVyc2UgZmxvdyB3b3VsZCBwaWdneWJhY2sgaW5iYW5kIGFj a25vd2xlZGdlbWVudHMgZnJvbSB0aGUgc2VydmljZSBmdW5jdGlvbnMgdGhhdCB0aGUgbG9uZyB0 ZXJtIG1ldGFkYXRhIGhhcyBiZWVuIHJlY2VpdmVkLiAgICBBdCB0aGF0IHBvaW50LCB0aGUgY2xh c3NpZmllciB3b3VsZCBubyBsb25nZXIgYWRkIHRoZSBsb25nIGxpdmVkIG1ldGFkYXRhIHRvIHRo ZSBmbG93Lg0KDQogICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RGF2ZSBEb2xzb24gW21haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbV0gDQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDI2LCAyMDE0IDEwOjUwIEFNDQpUbzogUm9uIFBhcmtlcjsgSmltIEd1aWNo YXJkIChqZ3VpY2hhcikNCkNjOiBDaHJpcyBGcmVkZXJpY2s7IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb207IFNodW5zdWtlIEhvbW1hOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbc2Zj XSBUUjogSS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0 DQoNCkFsc28sIGVhcmxpZXIgd2UgZGlzY3Vzc2VkIHRoZSBiZW5lZml0cyBvZiBvcnRob2dvbmFs IHRyZWF0bWVudCBvZiBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIHZzLiBtZXRhLWRhdGEuDQpJLmUu LCBzb21lIHBhcnQgb2YgdGhlIHByb3RvY29sIHNob3VsZCBpbmRpY2F0ZSB0aGF0IHBhdGgsIGFu ZCBhIGRpZmZlcmVudCBwYXJ0IG9mIHRoZSBwcm90b2NvbCBzaG91bGQgaW5kaWNhdGUgdGhlIHRy ZWF0bWVudCBvciBwb2xpY3kgc2V0IHRvIGJlIHVzZWQuDQpFYXJsaWVyIGl0IHdhcyBzdWdnZXN0 ZWQgdGhhdCB0aGUgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgaW4gYSBmaXhlZC1z aXplIGhlYWRlci4NCg0KU28sIGluIHRoZSBsaW1pdCwgdGhlcmUgY291bGQgYmUgYSBzaW5nbGUg KGJpLWRpcmVjdGlvbmFsKSBmb3J3YXJkaW5nIHBhdGggb3ZlciB3aGljaCBtaWxsaW9ucyBvZiBk aWZmZXJlbnQgcG9saWN5IHRyZWF0bWVudHMgYXJlIGNvbnZleWVkLg0KRS5nLiwgb25lIGZvcndh cmRpbmcgcGF0aCBmb3IgZWFjaCBkaXJlY3Rpb24gKHJlYWxseSB0d28gcGF0aHMpLCB3aXRoIHN1 YnNjcmliZXIgaWRlbnRpZmllciBpbiB0aGUgbWV0YS1kYXRhLiANCg0KQmVuZWZpdHM6DQotIGZv cndhcmRpbmcgZWxlbWVudHMgYXJlIGFnbm9zdGljIGFib3V0IHRoZSBtZXRhLWRhdGEsIGtlZXBp bmcgdGhlIGZvcndhcmRpbmcgdGFibGVzIGFzIHNtYWxsIGFzIHBvc3NpYmxlIGFuZCB1c2luZyBm aXhlZC1zaXplIGhlYWRlcnMgZm9yIG9wdGltYWwgcGVyZm9ybWFuY2UNCi0gU0ZzIGFyZSBhZ25v c3RpYyBhYm91dCB0aGUgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiwgdXNpbmcgb25seSB0aGUgcmVs ZXZhbnQgbWV0YS1kYXRhLg0KLSB0aGUgbWV0YS1kYXRhIGlzIG5vdCByZXF1aXJlZCBpbiBldmVy eSBwYWNrZXQuIEUuZy4sIGl0IGNvdWxkIGJlIHNlbnQgd2l0aCB0aGUgZmlyc3QgcGFja2V0IG9m IGEgbGF5ZXI0IGNvbm5lY3Rpb24sIG9yIHBlcmhhcHMgb3V0IG9mIGJhbmQuDQoNCg0KDQotRGF2 ZQ0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQpTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE0IDEwOjIxIEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcikNCkNjOiBDaHJpcyBGcmVkZXJpY2s7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207 IFNodW5zdWtlIEhvbW1hOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1E IEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQoNCkkgYWdy ZWUgd2l0aCBKaW0uDQoNCldlIGhhdmUgYWxzbyBwb2ludGVkIG91dCB0aGF0IHRoZXJlIGFyZSBh dCBsZWFzdCAyIGFwcHJvYWNoZXMgdG8gZGlmZmVyZW50aWF0ZWQgcG9saWN5ICoqd2l0aGluKiog YSBzZXJ2aWNlIGZ1bmN0aW9uLiAgIFRoZSBmaXJzdCBpcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIGlzIHJlc3BvbnNpYmxlIGZvciBkZXRlcm1pbmluZyB3aGljaCBwb2xpY2llcyB0byBhcHBs eSBpbiBhIG1hbm5lciB0aGF0IGlzIHByaXZhdGUgdG8gaXQgKHBlcmhhcHMgdXNpbmcgUkFESVVT LCBvciBMREFQLCBvciBzb21lIG90aGVyIGV4dGVybmFsIGxvb2t1cCBtZWNoYW5pc20pLiAgICBU aGlzIGFwcHJvYWNoIG1heSwgaW4gc29tZSBjYXNlcywgYmVuZWZpdCBmcm9tIGEgc3Vic2NyaWJl ciBpZGVudGl0eSBiZWluZyBwYXNzZWQgaW4gdGhlIGluYmFuZCBtZXRhZGF0YS4NCg0KVGhlIHNl Y29uZCwgd2hpY2ggaXMgd2VsbCBzdWl0ZWQgd2hlbiB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IHBv bGljeSBzZXRzIGlzIHNtYWxsIChlLmcuLCBjb250ZW50LWZpbHRlci1hZHVsdCwgY29udGVudC1m aWx0ZXItY2hpbGQpLCBpcyB0byBtb2RlbCB0aGUgc2VydmljZSBmdW5jdGlvbiBhcyBoYXZpbmcg bXVsdGlwbGUgbG9naWNhbCBpbnN0YW5jZXMgb2YgaXRzZWxmLCBlYWNoIGltcGx5aW5nIGEgZGlz dGluY3QgcG9saWN5IHNldC4gICBJbiB0aGlzIGFwcHJvYWNoLCBTRkNzIGFyZSBidWlsdCBzdWNo IHRoYXQgYW55IGdpdmVuIGNoYWluIHdvdWxkIGluY2x1ZGUgYXQgbW9zdCBvbmUgb2YgdGhlIGxv Z2ljYWwgaW5zdGFuY2VzLg0KDQogICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5j b21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE0IDk6NDIgQU0NClRvOiBSb24g UGFya2VyDQpDYzogU2h1bnN1a2UgSG9tbWE7IENocmlzIEZyZWRlcmljazsgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gVFI6IEkt RCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KDQpSaWdo dCBhbmQgdGhlIHBvaW50IGJlaW5nIHdoYXQgeW91IHdhbnQgdG8gZG8gaXMgc2hhcmUgU0ZDcyBh Y3Jvc3Mgc3Vic2NyaWJlcnMgYW5kIGltcGxlbWVudCB3aXRoaW4gdGhlIFNGQyBhbnkgZGlmZmVy ZW50aWF0aW9uIGluIHRlcm1zIG9mIHBvbGljeSBmb3Igc3Vic2NyaWJlcnMgdGhhdCBjb25zdW1l IHRoZSBzYW1lIHNldCBvZiBzZXJ2aWNlcy4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9u IEZlYiAyNiwgMjAxNCwgYXQgNzozMiBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IEV2ZW4gaWYgc3Vic2NyaWJlcnMgY2FuIHNl bGYgY29uZmlndXJlIHRoZWlyIHNlcnZpY2VzIHZpYSBhIHBvcnRhbCwgdGhlIG51bWJlciBvZiBk aXN0aW5jdCBjb21iaW5hdGlvbnMgdGhhdCBhcmlzZSB3aWxsIHN0aWxsIGJlIGZpbml0ZS4gIFRo YXQgaXMsIGluIGEgcG9wdWxhdGlvbiBvZiAxMDAwMDAwMDAgc3Vic2NyaWJlcnMsIHN1cmVseSBz b21lIHdpbGwgZW5kIHVwIHdpdGggZXF1aXZhbGVudCBzZXJ2aWNlcz8NCj4gDQo+ICAgUm9uDQo+ IA0KPj4gT24gRmViIDI2LCAyMDE0LCBhdCAyOjI1IEFNLCAiU2h1bnN1a2UgSG9tbWEiIDxob21t YS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+IA0KPj4gSGkgQ2hyaXMsIFJvbiwN Cj4+IA0KPj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4gDQo+PiBJIHVuZGVyc3Rvb2Qg dGhhdCB5b3Ugc2FpZC4NCj4+IEFuZCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG1ldGhvZCB1 c2luZyBtZXRhZGF0YSBpcyBvbmUgb2YgdGhlIG1ldGhvZHMgZm9yIHJlY29nbml6aW5nIHN1YnNj cmliZXJzLg0KPj4gQnV0IHRoaXMgcHJvYmxlbSBpcyBpbXBsZW1lbnRhdGlvbiBtYXR0ZXJzLCBz byBpdCBpcyBub3QgYXQgdGhlIHN0YWdlIGZvciBkaXNjdXNzaW9uIHlldCwgSSB0aGluay4NCj4+ IA0KPj4gV2hhdCBJIHdhbnQgdG8gc2F5IGlzIHRoYXQgdGhlcmUgYXJlIHJlcXVlc3RzIGZvciBk aXN0aW5jdCBzZXJ2aWNlcyBwZXIgc3Vic2NyaWJlciwgc28gdGhhdCBTRkMgYXJjaGl0ZWN0dXJl IHNob3VsZCBiZSBzY2FsYWJsZS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gU2h1bnN1a2UN Cj4+IA0KPj4gDQo+PiAoMjAxNC8wMi8yNSAyMzo0OSksIFJvbiBQYXJrZXIgd3JvdGU6DQo+Pj4g RXhwYW5kaW5nIG9uIENocmlzJyBjb21tZW50cywgSSBkb24ndCB0aGluayB0aGUgcHJhY3RpY2Fs IGxpbWl0YXRpb25zIGFyZSB3cnQgdGhlIG51bWJlciBvZiBmdWxseS1xdWFsaWZpZWQgNS10dXBs ZXMsIGJ1dCByYXRoZXIgdGhlIG51bWJlciBvZiBkaXN0aW5jdCB0cmVhdG1lbnQgc2VxdWVuY2Vz IHRoYXQgYXJpc2UgZnJvbSB0aG9zZSBmbG93cy4gICBPZiB0aGUgMTAwJ3Mgb2YgbWlsbGlvbnMg b2YgZmxvd3MgdGhhdCBtaWdodCBiZSB0cmFja2VkIGJ5IGEgaGlnaCBlbmQgY2xhc3NpZmllciwg cGVyaGFwcyB0aGUgbnVtYmVyIG9mIHVuaXF1ZSBzZXF1ZW5jZXMgdGhhdCBhcmlzZSBhcmUgaW4g dGhlIDEwMDAncy4gICAgSWYgYXBwbHlpbmcgYSBmaXhlZC1saW5lIG9yIG1vYmlsZSBzZXJ2aWNl IHByb3ZpZGVyIHBlcnNwZWN0aXZlLCB0aGUgbnVtYmVyIG9mIGNoYWlucyB3b3VsZCBiZSBwcm9w b3J0aW9uYWwgdG8gdGhlIG51bWJlciBvZiBkaXN0aW5jdCBlbmQtdG8tZW5kIHNlcnZpY2UgcGxh bnMgb2ZmZXJlZCBhbmQgdGhlbiBtdWx0aXBsaWVkIGJ5IHRoZSBmbG93LWF3YXJlIHN1YnNldHRp bmcgdGhhdCBjYW4gYmUgbWFuYWdlZCBieSB0aGUgY2xhc3NpZmllciAoaS5lLiwgc3Vic2NyaWJl ciBpcyBzdWJqZWN0IHRvIHNlcnZpY2UgZnVuY3Rpb24gQSB0aGVuIEIgdGhlbiBDIGJ1dCBCIG9u bHkgbmVlZHMgVENQLzgwIHRyYWZmaWMsIEEgb25seSBuZWVkcyBVRFAgdHJhZmZpYywgLi4uKS4N Cj4+PiANCj4+PiAgIFJvbg0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogQ2hyaXMgRnJlZGVyaWNrIFttYWlsdG86Y2ZyZWRlcmlja0BzYW5kdmlu ZS5jb21dDQo+Pj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjUsIDIwMTQgOTo0NCBBTQ0KPj4+ IFRvOiBTaHVuc3VrZSBIb21tYTsgUm9uIFBhcmtlcg0KPj4+IENjOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW3NmY10gVFI6IEkt RCBBY3Rpb246IA0KPj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0K Pj4+IA0KPj4+IEhpIFNodW5zdWtlLXNhbiwNCj4+PiBJIHJlY29nbml6ZSB0aGF0IHVsdGltYXRl bHksIHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gZGVjaXNpb24gYW5kIG5vdCBzb21ldGhpbmcg dG8gYmUgbWFuZGF0ZWQgYXMgYSBoYXJkICdydWxlJy4gSSBqdXN0IHdhbnRlZCB0byBoaWdobGln aHQgd2hhdCBpcyBwb3NzaWJsZSArIHdoYXQgd2UgYmVsaWV2ZSB0byBiZSBiZXN0IHByYWN0aWNl cyBpbiB0aGlzIGFyZWEsIGJhc2VkIG9uIG91ciBleHBlcmllbmNlLg0KPj4+IFRoYXQgc2FpZCwg eWVzLCBJIGJlbGlldmUgdGhhdCBpbiBwcmFjdGljYWwgKHJlYWwtd29ybGQpIHRlcm1zLCBpdCBt YWtlcyBzZW5zZSB0byBkZWVtcGhhc2l6ZSB0aGUgJyhyZSljbGFzc2lmaWNhdGlvbicgcm9sZSBv ZiBTRnMgaW4gbW9zdCBjYXNlcywgZm9yIHJlYXNvbnMgSSd2ZSBzdGF0ZWQgcHJldmlvdXNseSAo cXVlc3Rpb25zIG9mIG1ldGFkYXRhIHNoYXJpbmcgYmV0d2VlbiBTRnMsIGlzc3VlcyByZWxhdGVk IHRvIHJldGFpbmluZyBpbnRlZ3JpdHkgb2YgY2hhaW5zL2JyZWFraW5nIGZsb3dzLCBldGMuKS4N Cj4+PiBUbyB5b3VyIGNvbW1lbnQgYWJvdXQgc2NhbGluZyB0aGUgU0ZDIENvbnRyb2xsZXIsIEkg d291bGQganVzdCBzYXkgdGhhdCB0aGVyZSBhcmUgY29tbWVyY2lhbGx5IGRlcGxveWVkIFNGQyBD b250cm9sbGVycyB0b2RheSB0aGF0IGRvIHRoaXMsIGkuZS4gc2l0IGlubGluZSBpbiBjb25zdW1l ciBuZXR3b3JrcywgcmVjZWl2ZS9pbnNwZWN0IG1pbGxpb25zIG9mIGNvbmN1cnJlbnQgYmlkaXJl Y3Rpb25hbCBmbG93cywgKyBtYWtlIHJlYWwtdGltZSBTRkMgc3RlZXJpbmcgYW5kIHNlcXVlbmNp bmcgZGVjaXNpb25zIGJhc2VkIG9uIGZsb3csIHN1YnNjcmliZXIsIHNlc3Npb24sIGFuZCBuZXR3 b3JrIGNvbmRpdGlvbnMuDQo+Pj4gT2J2aW91c2x5LCBkaWZmZXJlbmNlcyBpbiB2ZW5kb3IgY2Fw YWJpbGl0aWVzLCBhcyB3ZWxsIGFzIA0KPj4+IGFyY2hpdGVjdHVyYWwgZGVjaXNpb25zIHZpeiBj b25zb2xpZGF0aW5nIHZzLiBkaXN0cmlidXRpbmcgZGlmZmVyZW50IA0KPj4+IFNGQyBmdW5jdGlv bnMgbGlrZSBmbG93IGNsYXNzaWZpY2F0aW9uLCBQRFAvU0ZDIENvbnRyb2xsZXIsIA0KPj4+IHN0 ZWVyaW5nL2xiLCBldGMsIGFsbCB3aWxsIGhhdmUgYW4gaW1wYWN0IGhlcmUuIEJlc3QsIC9jDQo+ Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBTaHVuc3VrZSBI b21tYSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanBdDQo+Pj4gU2VudDogVHVl c2RheSwgRmVicnVhcnkgMjUsIDIwMTQgNzoyNSBBTQ0KPj4+IFRvOiBDaHJpcyBGcmVkZXJpY2s7 IFJvbiBQYXJrZXINCj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGll dGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOiANCj4+PiBkcmFm dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+PiANCj4+PiBIaSBDaHJpcywN Cj4+PiANCj4+PiBEbyB5b3UgbWVhbiB0aGF0LCBmb3IgcmV0YWluaW5nIGludGVncml0eSBvZiBj aGFpbnMsIG1hbmFnZW1lbnQgb2Ygc3Vic2NyaWJlcnMgc2hvdWxkIGJlIHByb3ZpZGVkIG5vdCBi eSBTRnMsIGJ1dCBieSBTRkMgY29udHJvbGxlcj8NCj4+PiANCj4+PiBJZiBzbywgdGhlIHByb2Js ZW0gaXMgdGhhdCB0aGUgbnVtYmVyIG9mIGNoYWlucyB0aGF0IFNGQyBjb250cm9sbGVyIG11c3Qg bWFuYWdlIGlzIGxhcmdlLCBhbmQgaXQgaXMgdGhlIHNhbWUgcHJvYmxlbSBJIHNhaWQsIEkgdGhp bmsuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBTaHVuc3VrZQ0KPj4+IA0KPj4+ICgy MDE0LzAyLzI1IDE0OjE3KSwgQ2hyaXMgRnJlZGVyaWNrIHdyb3RlOg0KPj4+PiBIaSBTaHVuc3Vr ZS1zYW4sDQo+Pj4+IEkgYWNrbm93bGVkZ2UgdGhlIGNvbW1lbnRzIGFib3V0IHRoZXNlIGJlaW5n IGltcGxlbWVudGF0aW9uIA0KPj4+PiBtYXR0ZXJzLCBidXQgSSd2ZSBvZmZlcmVkIHNvbWUgdGhv dWdodHMgaW5saW5lIHdpdGggeW91ciBtYWlsIA0KPj4+PiBiZWxvdy4gVGh4LCAvYw0KPj4+PiAN Cj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogU2h1bnN1a2UgSG9t bWEgW21haWx0bzpob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwXQ0KPj4+PiBTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDk6MDAgUE0NCj4+Pj4gVG86IENocmlzIEZyZWRlcmljazsg Um9uIFBhcmtlcg0KPj4+PiBDYzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGll dGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4gZHJh ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+IA0KPj4+PiBIaSBSb24s IENocmlzLA0KPj4+PiANCj4+Pj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPj4+PiANCj4+ Pj4gSSB0aGluayB0aGF0IHlvdXIgcG9pbnRzIGFyZSBmb2xsb3dpbmc6DQo+Pj4+IGluIGNhc2Ug dGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgYXMgdXNlciBjdXN0b21pemVkLCBwZXItc3Vic2NyaWJl ciBTRkNzIHNob3VsZG4ndCBiZSBtYWRlLCBidXQgdGhlIFNGcyBzaG91bGQgcmVjb2duaXplIHN1 YnNjcmliZXJzIGJ5IElQIGFkZHJlc3Mgb3IgbWV0YWRhdGEuDQo+Pj4+IENGPj4gTXkgcG9pbnQg d2FzIHRoYXQgSSBkb24ndCBzZWUgaXQgYXMgZGVzaXJhYmxlIHRvIGhhdmUgc3BlY2lmaWMgcGVy LXN1YnNjcmliZXIgU0ZDIHJ1bGVzIChhcyBpbiBzdGF0aWMgcnVsZXMsIGxpa2Ugc3Vic2NyaWJl cl9DaHJpcz1TRkNfYV9iX2MpLCB3aXRoIGEgcnVsZSBmb3IgZXZlcnkgc3ViLCBpbiB0aGF0IHNl bnNlLiBCZXR0ZXIgaXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgU0ZDIGNoYWluIGNvbnRyb2xsZXIg aXMgc3Vic2NyaWJlci1hd2FyZSArIGFibGUgdG8gZXZhbHVhdGUgbXVsdGlwbGUgb3J0aG9nb25h bCBmbG93ICsgc3Vic2NyaWJlciBjb25kaXRpb25zIGluIHJlYWwgdGltZSwgYW5kIGZvcm11bGF0 ZSBhIGNoYWluIG9uIHRoZSBiYXNpcyBvZiB0aG9zZSBkeW5hbWljIGNvbmRpdGlvbnMuDQo+Pj4+ IA0KPj4+PiBPZiBjb3Vyc2UsIGl0IGlzIG9uZSBvZiB0aGUgc29sdXRpb25zLg0KPj4+PiBIb3dl dmVyLCBpbiB0aGlzIGNhc2UsIEkgdGhpbmsgdGhhdCBTRnMgYXMgdXNlciBjdXN0b21pemVkIG1p Z2h0IGJlIHJlcXVpcmVkIHRvIGhhdmUgYSBmdW5jdGlvbiB0byByZWNvZ25pemUgZWFjaCBzdWJz Y3JpYmVyLg0KPj4+PiBDRj4+IEkgd2Fzbid0IGFjdHVhbGx5IHRoaW5raW5nIGluIHRlcm1zIG9m IFNGIChyZSljbGFzc2lmaWNhdGlvbjsgSSd2ZSBwcmV2aW91c2x5IGNvbW1lbnRlZCBvbiB3aHkg SSB0aGluayB0aGF0IGlkZWEgaXMgc29tZXdoYXQgZnJhdWdodCAoaS5lLiBiZWNhdXNlIG1vZGlm aWNhdGlvbiBvZiB0aGUgZmxvdyBwYXRoIGJ5IGEgc2VydmljZSBmdW5jdGlvbiB3aXRoaW4gdGhl IGNoYWluIGNvdWxkIHJlc3VsdCBpbiBhICdicmVha2luZycgb2YgdGhlIGNoYWluIG9yIGZsb3cu IElmIHRoZXJlIGlzIG5vdCBiaWRpcmVjdGlvbmFsIHN5bW1ldHJ5IGluIHRoZSBmbG93IGFuZCBz ZXJ2aWNlIGZ1bmN0aW9uIGVsZW1lbnRzIGluIHRoZSBjaGFpbiBjYW4gbWFrZSByb3V0aW5nIGRl Y2lzaW9ucywgdGhlbiB0aGVyZSdzIHNvbWUgbWV0YWRhdGEgY29ycmVsYXRpb24gdG8gd29yayBv dXQsIGF0IG1pbmltdW0pLiBJIGRvIGFncmVlIHRoYXQgdGhlIFNGQyBjaGFpbiBjb250cm9sbGVy IHdvdWxkIG5lZWQgdG8gYmUgc3Vic2NyaWJlci1hd2FyZSB0aG91Z2guDQo+Pj4+IA0KPj4+PiBP biB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayB0aGF0IHRoZXJlIGFyZSBjYXNlcyB3aGVuIHRoZSBm dW5jdGlvbiBjYW4ndCBiZSBhZG9wdGVkLCBzdWNoIGxpa2UgU0ZzIGFyZSBjdXJyZW50IGVxdWlw bWVudCB0aGF0IGRvbid0IGhhdmUgZnVuY3Rpb24gdG8gcmVjb2duaXplIG1ldGFkYXRhLg0KPj4+ PiBDRj4+IEFncmVlZC4gVGhpcyBzcGVha3MgdG8gbXkgY29tbWVudCBhYm92ZSArIHRvIHRoZSBh ZHZhbnRhZ2VzIHNvbWUgb2YgdXMgaGF2ZSBtZW50aW9uZWQgdml6IGEgY29uc29saWRhdGVkIHBv bGljeS1iYXNlZCBzdGVlcmluZy9QRFAvU0ZDIGNoYWluIGNvbnRyb2xsZXIgZW50aXR5Lg0KPj4+ PiANCj4+Pj4gSG93IGRvIHdlIGhhbmRsZSB0aGVzZSBjYXNlcz8NCj4+Pj4gQW55IG5ldyBwcm9i bGVtcyBvciByZXF1aXJlbWVudHMgbWF5IG9jY3VyPw0KPj4+PiANCj4+Pj4gcmVnYXJkcywNCj4+ Pj4gDQo+Pj4+IFNodW5zdWtlDQo+Pj4+IA0KPj4+PiAoMjAxNC8wMi8yNSA4OjQ2KSwgQ2hyaXMg RnJlZGVyaWNrIHdyb3RlOg0KPj4+Pj4gWWVzLCBhZ3JlZWQgb24gdGhhdC4NCj4+Pj4+IA0KPj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21h aWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5 LCBGZWJydWFyeSAyNCwgMjAxNCA2OjQ1IFBNDQo+Pj4+PiBUbzogQ2hyaXMgRnJlZGVyaWNrOyDm nKzplpPkv4rku4sNCj4+Pj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNA aWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4+ IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+Pj4+PiBU aGFua3MsIENocmlzLg0KPj4+Pj4gDQo+Pj4+PiBJIGRvIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9m IGVmZmljaWVuY2llcyB3aGVuIHRoZSBmbG93IGxlYXJuZXIgKGNsYXNzaWZpZXIpIGFuZCBwb2xp Y3kgZXZhbHVhdG9yIChQRFApIGFyZSBjby1sb2NhdGVkLiAgIEhvd2V2ZXIsIGFyY2hpdGVjdHVy YWxseSwgSSB3b3VsZG4ndCBtYW5kYXRlIHRoYXQgdGhleSBiZSBjby1sb2NhdGVkLg0KPj4+Pj4g DQo+Pj4+PiAgICAgIFJvbg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNr QHNhbmR2aW5lLmNvbV0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjQsIDIwMTQgNToy NiBQTQ0KPj4+Pj4gVG86IFJvbiBQYXJrZXI7IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6 IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJl bWVudHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+IEFncmVlZC4NCj4+Pj4+IFRvIHJlc3RhdGUgdGhp cyBzbGlnaHRseSwgaWYgdGhlIFNGQyBzdGVlcmluZy9kZWNpc2lvbiBsb2N1cyBpcyBjYXBhYmxl IG9mIGV2YWx1YXRpbmcgbXVsdGlwbGUgb3J0aG9nb25hbCBwb2xpY3kgY29uZGl0aW9ucyB0aGVu IHRoaXMgaXNzdWUgaXMgb2J2aWF0ZWQ7IHN1YnNjcmliZXJzIGJlY29tZSBhbiBhZ2dyZWdhdGUg b2YgJ3doYXQgdGhleSBhcmUnICsgYXJlIG5vdCBzaW1wbHkgJ3dobyB0aGV5IGFyZScuDQo+Pj4+ PiBBcyBSb24gc3RhdGVzLCB0aGlzIGF3YXJlbmVzcyBtYXkgYmUgZGVyaXZlZCBmcm9tIExEQVAg bG9va3VwLCBSQURJVVMsIEd4LCBwcmUtcHJvdmlzaW9uZWQgcnVsZXMsIGV0Yy4NCj4+Pj4+IFRv IGlsbHVzdHJhdGUgdy8gYW4gZXhhbXBsZSwgd2UgbWlnaHQgc2F5IHNvbWV0aGluZyBsaWtlIHRo aXM6DQo+Pj4+PiBJZiBzdWJzY3JpYmVyIFggaXMgdXNpbmcgeW91dHViZSwgYW5kIGlzIG9uIGEg Y29uZ2VzdGVkIGNlbGwsIGFuZCBpcyBvbiBhbiBpUGhvbmUsIGFuZCBpcyBpbiB0aGUgIkdvbGQg VGllciIsIGFuZCwgYW5kLCBhbmQsIGFuZCwgZXRjLCB0aGVuIHRoZSBjaGFpbiBjb25zaXN0cyBv ZiBzZXJ2aWNlIGZ1bmN0aW9ucyBhLCBiLCBhbmQgYy4NCj4+Pj4+IFRoZXJlJ3Mgbm8gbmVlZCB0 byBlbnRlciBhIHN0YXRpYyBTRkMgcnVsZS9jaGFpbiBmb3Igc3Vic2NyaWJlciBYIChvciBhbnkg c3Vic2NyaWJlcikuIEluIGZhY3QsIGl0J3Mgbm90IGRlc2lyYWJsZSBhbnl3YXkgYmVjYXVzZSBh bGwgb2YgdGhlIGFib3ZlIGNvbmRpdGlvbnMgbWF5IGV2YWx1YXRlIHRvIFRydWUsIHNhdmUgb25l ICgiaXMgb24gYSBjb25nZXN0ZWQgY2VsbCIpLCBhbmQgdGhlIHJlc3VsdGFudCBjaGFpbiBtaWdo dCBiZSBhbHRlcmVkIChwZXJoYXBzIHRvIGJ5cGFzcyBhIHZpZGVvIG9wdGltaXphdGlvbiBzZXJ2 aWNlIGZ1bmN0aW9uKS4NCj4+Pj4+IFRoaXMgYWxzbyBnb2VzIHRvIHRoZSBlYXJsaWVyIGNvbW1l bnRzIFJvbiArIEkgbWFkZSBhYm91dCANCj4+Pj4+IGNvbnNvbGlkYXRpbmcgdGhlIGZsb3cgcmVj b2duaXRpb24gKyBkZWNpc2lvbi1tYWtpbmcgZW50aXR5IGluIGEgDQo+Pj4+PiBzaW5nbGUgKHN1 aXRhYmx5IHBvbGljeS1hd2FyZSkgbm9kZSB0byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgKyB0byAN Cj4+Pj4+IHNjYWxlIHByb3Blcmx5LiBUaHgsIC9jDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINCj4+Pj4+IFNlbnQ6IFN1bmRheSwgRmVicnVh cnkgMjMsIDIwMTQgMTA6MzkgUE0NCj4+Pj4+IFRvOiDmnKzplpPkv4rku4sNCj4+Pj4+IENjOiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBUUjogSS1EIEFjdGlvbjoNCj4+Pj4+IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVx dWlyZW1lbnRzLTAzLnR4dA0KPj4+Pj4gDQo+Pj4+PiBTaHVuc3VrZS1zYW4sDQo+Pj4+PiANCj4+ Pj4+IFdoaWxlIGEgdGhlb3JldGljYWwgY2FzZSBjYW4gYmUgbWFkZSBmb3Igb25lIG9yIG1vcmUg U0ZDcyBwZXIgc3Vic2NyaWJlciwgZm9yIHJlYXNvbnMgeW91IHN0YXRlLCBpdCBpc24ndCBwcmFj dGljYWwuICBCdXQsIHRoZXJlIGlzIGFub3RoZXIgd2F5IHRvIHZpZXcgdGhpcyBhc3BlY3Qgb2Yg dGhlIHByb2JsZW0uICBMZXQncyB0YWtlIHlvdXIgcGVyLXN1YnNjcmliZXIgY3VzdG9taXplZCBm aXJld2FsbCBhcyBhIGh5cG90aGV0aWNhbCBleGFtcGxlLiAgSWYgdGhlcmUgd2VyZSBvbmx5IG9u ZSBmaXJld2FsbCwgaW5zdGVhZCwgYW5kIGl0IHdhcyBjYXBhYmxlIG9mIGxvY2FsIHBvbGljeSBl dmFsdWF0aW9uIGJhc2VkIG9uIHN1YnNjcmliZXIsIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBi ZSB2YXN0bHkgcmVkdWNlZC4gICBPbmUgd2F5IGZvciB0aGF0IHRvIGhhcHBlbiB3b3VsZCBiZSB0 byBzaW1wbHkgdXNlIHRoZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgYWRkcmVzcyBmcm9tIHRoZSBw YWNrZXQgYW5kIHNvbWUgb3V0IG9mIGJhbmQgbG9va3VwIG1lY2hhbmlzbSBsaWtlIExEQVAgb3Ig UkFESVVTIGF0IHRoZSBmaXJld2FsbC4gICAgQW5vdGhlciBhcHByb2FjaCB0byBkZXRlcm1pbmUg d2hvIHRoZSBzdWJzY3JpYmVyIGlzIHdvdWxkIGJlIGZvciB0aGUgU0ZDIGNsYXNzaWZpZXIgdG8g YWRkIGEgZGlzdGluY3Qgc3Vic2NyaWJlciBpZCBhcyBtZXRhZGF0YSB0byB0aGUgc2VydmljZSBo ZWFkZXIgKGVnLCBhbiBJTVNJKSBhbmQgc3RpbGwgdXNlIExEQVAsIGV0Yy4gYXQgdGhlIGZpcmV3 YWxsLg0KPj4+Pj4gDQo+Pj4+PiBJZiB0aGUgcHJvYmxlbSBpcyBjaGFuZ2VkIHNsaWdodGx5IHNv IHRoYXQgdGhlIGZpcmV3YWxsIHBvbGljeSBpcyBwZXIgZ3JvdXAgb2Ygc3Vic2NyaWJlcnMsIHdo ZXJlIHRoZXJlIGFyZSBwZXJoYXBzIDEwcyBvZiBncm91cHMsIHRoZW4geWV0IGFub3RoZXIgYXBw cm9hY2ggaXMgdG8gbW9kZWwgdGhlIGZpcmV3YWxsIGFzIGEgZGlzdGluY3QgbG9naWNhbCBmaXJl d2FsbCBwZXIgZmlyZXdhbGwgcG9saWN5IHNldCAodGhleSBjb3VsZCBhbGwgcmVzaWRlIGluIHRo ZSBzYW1lIG1hY2hpbmUgb3IgVk0pIGFuZCB0byBjb29yZGluYXRlIHRoZSBjbGFzc2lmaWVyJ3Mg cG9saWN5IGFjY29yZGluZ2x5Lg0KPj4+Pj4gDQo+Pj4+PiAgICAgUm9uDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4+IE9uIEZlYiAyMywgMjAxNCwgYXQgMTA6MDQgUE0sICLmnKzplpPkv4rku4siIDxo b21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBIaSBN ZWQsDQo+Pj4+Pj4gDQo+Pj4+Pj4gSW4gdGVybXMgb2YgeW91ciBjb21tZW50LCBJIGFzc3VtZWQg c29tZSB1c2UgY2FzZXMgYWJvdXQgc2NhbGFiaWxpdHkgc28gdGhhdCB3ZSBjYW4gY29udGludWUg dGhlIGRpc2N1c3Npb24gYWJvdXQgc2NhbGFiaWxpdHkgY29uc2lkZXJhdGlvbnMuDQo+Pj4+Pj4g I0kgd29yayB3aXRoIEsuTmFpdG8sIGNvLWF1dGhvciBvZiByZXF1aXJlbWVudCBkcmFmdCBhbmQg dGhpbmsgc2NhbGFiaWxpdHkgaXMgb25lIG9mIGltcG9ydGFudCB0aGluZ3MgdG8gY29uc2lkZXIu DQo+Pj4+Pj4gDQo+Pj4+Pj4gQXNzdW1pbmcgdGhlIHVzZSBjYXNlcyBsaXN0ZWQgZm9sbG93aW5n LCB0aGUgbWFuYWdlbWVudCBtZWNoYW5pc20gb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbnMgbWln aHQgcmVxdWlyZSBoaWdoIHNjYWxhYmlsaXR5Lg0KPj4+Pj4+IA0KPj4+Pj4+IDEuIFRoZSBjYXNl IHRoYXQgdGhlIHR5cGVzIG9mIFNGIGluY3JlYXNlOg0KPj4+Pj4+IEkgYXNzdW1lZCB0aGF0IHRo ZSB1bml0IG9mIGFwcGx5aW5nIFNGQyB0byB0cmFmZmljIGlzIGZvbGxvd2luZzsNCj4+Pj4+PiAg IC0gZ3JvdXBpbmc6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFj aCBzZXJ2aWNlLA0KPj4+Pj4+ICAgICBlbnRlcnByaXNlIGN1c3RvbWVyIG9yIHJlZ2lvbiwNCj4+ Pj4+PiAgIC0gcGVyLXN1YnNjcmliZXI6IHRyYWZmaWMgaXMgYXBwbGllZCB3aXRoIHNwZWNpZmlj IFNGQyBmb3IgZWFjaOOAgA0KPj4+Pj4+ICAgICBzdWJzY3JpYmVyIChlLmcuIHBlciBJUCBhZGRy ZXNzLCBWTEFOIElEIGV0LmFsKSwNCj4+Pj4+PiAgIC0gcGVyLWZsb3c6IHRyYWZmaWMgaXMgYXBw bGllZCB3aXRoIHNwZWNpZmljIFNGQyBmb3IgZWFjaCBzdWJzY3JpYmVyLA0KPj4+Pj4+IOOAgOOA gGFuZCBvYmplY3RpdmUgKGUuZy4gcHJlIFVSTCwgYXBwbGljYXRpb24gZXQuYWwpLg0KPj4+Pj4+ IA0KPj4+Pj4+IFNvbWUgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgZW5vcm1vdXMgbnVt YmVyIG9mIHN1YnNjcmliZXJzLCBhbmQgdGhlIG51bWJlciBvZiBzdWJzY3JpYmVycyBpcyB1cCB0 byBzZXZlcmFsIHRlbnMgb3IgaHVuZHJlZHMgb2YgbWlsbGlvbi4gVGhlcmVmb3JlLCBpbiBjYXNl cyBvZiBwZXItc3Vic2NyaWJlciBhbmQgcGVyLWZsb3csIHRoZSBudW1iZXIgb2YgU0ZDcyBtaWdo dCBpbmNyZWFzZSBleHBsb3NpdmVseS4gUGVyLXN1YnNjcmliZXIgU0ZDcyB3b3VsZCBiZSBuZWVk ZWQgaW4gdGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBTRnMgZGVkaWNhdGVkIHRvIGVhY2gg dXNlcihlLmcuIHZDUEUgYXMgdXNlciBjdXN0b21pemVkKS4NCj4+Pj4+PiANCj4+Pj4+PiBBbHNv LCBpbiBjYXNlIG9mIGdyb3VwaW5nLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgZ3JvdXBzIHdob3Nl IHBvbGljaWVzIGFyZSBkaWZmZXJlbnQsIHN1Y2ggYXMgcGVyIGVudGVycHJpc2UgY3VzdG9tZXIg YW5kIHBlciByZWdpb24sIHRoZSBudW1iZXIgb2YgU0ZDcyB3b3VsZCBpbmNyZWFzZSAoZS5nLiBG aXJld2FsbHMgaGF2ZSBkaWZmZXJlbnQgcG9saWN5IGZvciBlYWNoIGVudGVycHJpc2UgY3VzdG9t ZXIpLg0KPj4+Pj4+IA0KPj4+Pj4+IDIuIFRoZSBjYXNlIHRoYXQgdGhlcmUgYXJlIHNvbWUgU0Zz IHRoYXQgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlOg0KPj4+Pj4+IEluIGNh c2UgdGhhdCB0aGVyZSBhcmUgU0ZzIHdpdGggdGhlIHNhbWUgZnVuY3Rpb24gaW4gdGhlIG5ldHdv cmsgYW5kIHRoZSBTRnMgbXVzdCBiZSBjbGFzc2lmaWVkIGZvciBlYWNoIGluc3RhbmNlLCB0aGUg Y29tYmluYXRpb24gb2YgU0ZzIG1pZ2h0IGluY3JlYXNlLg0KPj4+Pj4+IFRoZSBTRnMgdGhhdCBw cm9jZXNzIHN0YXRlZnVsIHRyYWZmaWMgYXJlIG5lZWRlZCB0byBiZSBkaWZmZXJlbnRpYXRlZCBw ZXIgaW5zdGFuY2UgKGUuZy4gRmlyZXdhbGwsIENvbnRlbnRzLUNhY2hlLCBhbmQgVmlkZW8tT3B0 aW1pemVyKS4NCj4+Pj4+PiANCj4+Pj4+PiBJTUhPLHJlcXVpcmVtZW50cyBmb3Igc2NhbGFiaWxp dHkgd2lsbCBhZmZlY3QgU0ZDIGFyY2hpdGVjdHVyZSBhbmQgaGVhZGVyIGZvcm1hdC4NCj4+Pj4+ PiANCj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gDQo+Pj4+Pj4gU2h1bnN1a2UNCj4+Pj4+PiANCj4+ Pj4+PiAoMjAxNC8wMi8xMiAxODo0OSksIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3Jv dGU6DQo+Pj4+Pj4+IERlYXIgYWxsLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhpcyBuZXcgdmVyc2lv biBpbnRlZ3JhdGVzIGlucHV0cyBmcm9tIE5UVCByZXByZXNlbnRhdGl2ZXMuDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBUaGUgZGlmZiBjYW4gYmUgdHJhY2tlZCBoZXJlOg0KPj4+Pj4+PiBodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50DQo+ Pj4+Pj4+IHMtMA0KPj4+Pj4+PiAxDQo+Pj4+Pj4+ICYNCj4+Pj4+Pj4gZGlmZnR5cGU9LS1odG1s JnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cw0KPj4+Pj4+ PiAtMDMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVkDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4gRGUgOiBJLUQtQW5u b3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgDQo+Pj4+ Pj4+IHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIEVudm95w6kgOiBtZXJjcmVkaSAx MiBmw6l2cmllcg0KPj4+Pj4+PiAyMDE0IDEwOjQ2IMOADQo+Pj4+Pj4+IDogaS1kLWFubm91bmNl QGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlvbjoNCj4+Pj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNm Yy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAgICAgICAgIFRp dGxlICAgICAgICAgICA6IFJlcXVpcmVtZW50cyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu Zw0KPj4+Pj4+PiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaHJpc3RpYW4gSmFjcXVlbmV0DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1YW5sb25nIEppYW5nDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbiBQYXJrZXINCj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2FybG9zIFBpZ25hdGFybw0KPj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBLZW5nbyBOYWl0bw0KPj4+Pj4+PiAgICAgRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+Pj4+ICAgICBQYWdl cyAgICAgICAgICAgOiAxNA0KPj4+Pj4+PiAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMi0x Mg0KPj4+Pj4+PiANCj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+ICAgICBUaGlzIGRvY3VtZW50 IGlkZW50aWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIFNlcnZpY2UgRnVuY3Rpb24NCj4+ Pj4+Pj4gICAgIENoYWluaW5nIChTRkMpLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2Fk YWlyLXNmYy1yZXF1aXJlbWVudA0KPj4+Pj4+PiBzLw0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnQNCj4+Pj4+Pj4gcy0wDQo+Pj4+Pj4+IDMNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSANCj4+Pj4+Pj4gb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlz dA0KPj4+Pj4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+Pj4+Pj4gSW50ZXJuZXQtRHJh ZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+Pj4+ Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IC0tDQo+Pj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+Pj4+PiDmnKzplpMg5L+K5LuLIChIb21tYSBTaHVuc3VrZSkNCj4+Pj4+PiAN Cj4+Pj4+PiDml6XmnKzpm7vkv6Hpm7voqbHmoKrlvI/kvJrnpL4NCj4+Pj4+PiDjg43jg4Pjg4jj g6/jg7zjgq/jgrXjg7zjg5Pjgrnjgrfjgrnjg4bjg6DnoJTnqbbmiYANCj4+Pj4+PiDou6LpgIHj grXjg7zjg5Pjgrnln7rnm6Tjg5fjg63jgrjjgqfjgq/jg4gNCj4+Pj4+PiDou6LpgIHjgrXjg7zj g5PjgrnliLblvqFEUA0KPj4+Pj4+IA0KPj4+Pj4+IOOAkjE4MC04NTg144CA5p2x5Lqs6YO95q2m 6JS16YeO5biC57eR55S6My05LTExDQo+Pj4+Pj4gVEVMOiAwNDIyLTU5LTM0ODYNCj4+Pj4+PiBF LU1BSUw6IGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanANCj4+Pj4+PiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gc2ZjIG1haWxp bmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGll dGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLQ0K Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IFNodW5zdWtlIEhv bW1hDQo+Pj4+IDxob21tYS5zaHVuc3VrZUBsYWIubnR0LmNvLmpwPg0KPj4+PiBURUw6ICs4MSAw NDIyIDU5IDM0ODYNCj4+Pj4gRkFYOiArODEgMDQyMiA2MCA3NDYwDQo+Pj4+IA0KPj4+PiBOVFQg TmV0d29yayBTZXJ2aWNlIFN5c3RlbSBMYWJzLg0KPj4+PiBNdXNhc2hpbm8gY2l0eSwgVG9reW8s IEphcGFuDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiANCj4+PiANCj4+PiAtLQ0KPj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBTaHVuc3VrZSBIb21tYQ0KPj4+IDxob21tYS5z aHVuc3VrZUBsYWIubnR0LmNvLmpwPg0KPj4+IFRFTDogKzgxIDA0MjIgNTkgMzQ4Ng0KPj4+IEZB WDogKzgxIDA0MjIgNjAgNzQ2MA0KPj4+IA0KPj4+IE5UVCBOZXR3b3JrIFNlcnZpY2UgU3lzdGVt IExhYnMuDQo+Pj4gTXVzYXNoaW5vIGNpdHksIFRva3lvLCBKYXBhbg0KPj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiBzZmNAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gDQo+ PiANCj4+IC0tDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBTaHVu c3VrZSBIb21tYQ0KPj4gPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+DQo+PiBURUw6ICs4 MSAwNDIyIDU5IDM0ODYNCj4+IEZBWDogKzgxIDA0MjIgNjAgNzQ2MA0KPj4gDQo+PiBOVFQgTmV0 d29yayBTZXJ2aWNlIFN5c3RlbSBMYWJzLg0KPj4gTXVzYXNoaW5vIGNpdHksIFRva3lvLCBKYXBh bg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBt YWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg== From nobody Wed Feb 26 08:16:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EA91A0231 for ; Wed, 26 Feb 2014 08:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 8u0kYy3MytD2 for ; Wed, 26 Feb 2014 08:16:23 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8191A02DC for ; Wed, 26 Feb 2014 08:15:44 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Wed, 26 Feb 2014 11:15:42 -0500 From: Dave Dolson To: Ron Parker , "Jim Guichard (jguichar)" Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: Ac8n10BUNXwyKPfWTqS2/pzRF93c/QAAFWmAAlfkV4AAAS3mgAAcTWSAAA3T7AAACnDhIP//0f2AgAAociCAAIZdgIAAOz2A///tKICAARZkgIAAVVSAgAAkgACAAArQAIAATj1g//+9ioCAAFH/cA== Date: Wed, 26 Feb 2014 16:15:42 +0000 Message-ID: References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PcWdpzc5b9fyWK_bu3WOqoY0Zdg Cc: Chris Frederick , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 16:16:28 -0000 VGhhdCBpbi1iYW5kIG1ldGhvZCBvZiBzZW5kaW5nIGRhdGEgaXMgaW50ZXJlc3RpbmcuDQoNCk15 IG1haW4gcG9pbnQgd2FzIHRoZSBvcnRob2dvbmFsaXR5IG9mIHBlci1wYWNrZXQgZm9yd2FyZGlu ZyB0YWdzIGFuZCB0aGUgbWV0YS1kYXRhIHRvIGNvbnZleSBwb2xpY3kgdHJlYXRtZW50LiBJIGRp ZCBub3QgbWVhbiB0byBpbXBseSBvbmUgbWV0YS1kYXRhIHBhcmFtZXRlciBpcyBhcHByb3ByaWF0 ZSBmb3IgYWxsIGVsZW1lbnRzLg0KDQpTaW5jZSB5b3VyIGlkZWEgZG9lcyBub3QgcHV0IHRoZSBt ZXRhLWRhdGEgaW4gZWFjaCBwYWNrZXQsIEkgc3VzcGVjdCB3ZSBhcmUgaW4gYWdyZWVtZW50IG9u IHRoZSBzZXBhcmF0aW9uIG9mIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gZnJvbSBwb2xpY3kga2V5 cy4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb24gUGFya2VyIFtt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0gDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDI2LCAyMDE0IDExOjAzIEFNDQpUbzogRGF2ZSBEb2xzb247IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpDQpDYzogQ2hyaXMgRnJlZGVyaWNrOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBTaHVuc3VrZSBIb21tYTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10g VFI6IEktRCBBY3Rpb246IGRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0K DQpEYXZlLA0KDQpJIGZpbmQgdGhlIGNvbnZleWFuY2Ugb2YgYSBwb2xpY3kga2V5IGZyb20gdGhl IGNsYXNzaWZpZXIgdG8gdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHZlcnkgYXR0cmFjdGl2ZS4gICAN Cg0KSG93ZXZlciwgSSBkb24ndCB0aGluayBhIGdsb2JhbCBrZXkgdGhhdCBpcyBpbnRlcnByZXRl ZCBlcXVhbGx5IGJ5IGFsbCBzZXJ2aWNlIGZ1bmN0aW9ucyBpcyBwcmFjdGljYWwuICAgU29tZSBz ZXJ2aWNlIGZ1bmN0aW9ucyBtYXkgaGF2ZSBvbmx5IGEgdmVyeSBzbWFsbCBxdWFudGl0eSBvZiBw b2xpY3kgc2V0cyB3aGlsZSBvdGhlcnMgbWF5IGJlIHZlcnkgZ3JhbnVsYXIuICAgICBXaXRoIGEg Z2xvYmFsIGtleSwgd2hlbiBhZGRpdGlvbmFsIHBvbGljeSBzZXRzIGFyZSBhZGRlZCB0byBzb21l IHNlcnZpY2UgZnVuY3Rpb24sIGFsbCBzZXJ2aWNlIGZ1bmN0aW9ucyB3b3VsZCBuZWVkIHRvIGtu b3cgaG93IHRvIHRyYW5zbGF0ZSB0aG9zZSBuZXcgZ2xvYmFsIGtleXMgaW50byBzb21ldGhpbmcg bG9jYWxseSBzaWduaWZpY2FudC4gICAgDQoNCkFuIGFsdGVybmF0aXZlLCBwdXNoaW5nIGEgc3Rh Y2sgb2YgcGVyLXNlcnZpY2UtZnVuY3Rpb24gcG9saWN5IGtleXMgb250byB0aGUgcGFja2V0IHNv IHRoYXQgZWFjaCBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBzZWUgaXRzIG93biBsb2NhbGx5IHNpZ25p ZmljYW50IHBvbGljeSBrZXksIGhhcyBpdHMgaXNzdWVzLCB0b28sIHNpbmNlIGl0IGlzIHRoZW9y ZXRpY2FsbHkgdW5ib3VuZGVkIGFuZCBhZGRzIG92ZXJoZWFkIHRvIGV2ZXJ5IHBhY2tldC4NCg0K QSBwb3NzaWJsZSB3b3JrYXJvdW5kIHRvIHRoZSBzdGFjayBvZiBwb2xpY3kga2V5cyBpcyB0byBz aWduYWwgdGhpcyBpbiBhIGNvbnRyb2wgcGxhbmUgZnJvbSB0aGUgY2xhc3NpZmllciB0byB0aGUg c2VydmljZSBmdW5jdGlvbnMuICAgQnV0LCBzaWduYWxpbmcgYXQgdGhlIG1pY3JvLWZsb3cgbGV2 ZWwgaXMgdmVyeSBpbXByYWN0aWNhbCBpbiB0ZXJtcyBvZiBzY2FsZSBhbmQgYWRkcyBzaWduaWZp Y2FudCBjb21wbGV4aXR5IHRvIGF2b2lkIHRoZSBmaXJzdCBwYWNrZXQgcmFjZSBjb25kaXRpb24g dGhhdCBjb3VsZCBhcmlzZS4gICBJbiBteSBvcGluaW9uLCB0aGUgY29udHJvbCBwbGFuZSBzaG91 bGQgb3BlcmF0ZSBhdCB0aGUgY2hhaW4gc2V0dXAgYW5kIG1haW50ZW5hbmNlIGxldmVsIGFuZCBu b3QgYXQgdGhlIG1pY3JvZmxvdyBsZXZlbC4NCg0KTGFzdGx5LCBhbiBhcHByb2FjaCB0aGF0IEkg dGhpbmsgY291bGQgd29yayBmb3IgYmlkaXJlY3Rpb25hbCBmbG93cyAodGhlIHZhc3QgbWFqb3Jp dHkgb2YgcHJhY3RpY2FsIHVzZSBjYXNlcywgSU1PKSBpcyB0byBoYXZlIGFuIGluYmFuZCBtZWNo YW5pc20gdG8gZGVsaXZlciBsb25nIGxpdmVkIG1ldGFkYXRhLiAgICBUaGUgc3RhY2sgb2YgcG9s aWN5IGtleXMgY291bGQgYmUgZGVsaXZlcmVkIGluYmFuZCBpbiB0aGUgZmlyc3QgTiBwYWNrZXRz IG9mIHRoZSBmbG93LiAgICBUaGUgcmV2ZXJzZSBmbG93IHdvdWxkIHBpZ2d5YmFjayBpbmJhbmQg YWNrbm93bGVkZ2VtZW50cyBmcm9tIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IHRoZSBsb25n IHRlcm0gbWV0YWRhdGEgaGFzIGJlZW4gcmVjZWl2ZWQuICAgIEF0IHRoYXQgcG9pbnQsIHRoZSBj bGFzc2lmaWVyIHdvdWxkIG5vIGxvbmdlciBhZGQgdGhlIGxvbmcgbGl2ZWQgbWV0YWRhdGEgdG8g dGhlIGZsb3cuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEYXZlIERvbHNvbiBbbWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tXSANClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMjYsIDIwMTQgMTA6NTAgQU0NClRvOiBSb24gUGFya2VyOyBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKQ0KQ2M6IENocmlzIEZyZWRlcmljazsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTsgU2h1bnN1a2UgSG9tbWE7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtz ZmNdIFRSOiBJLUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50 eHQNCg0KQWxzbywgZWFybGllciB3ZSBkaXNjdXNzZWQgdGhlIGJlbmVmaXRzIG9mIG9ydGhvZ29u YWwgdHJlYXRtZW50IG9mIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gdnMuIG1ldGEtZGF0YS4NCkku ZS4sIHNvbWUgcGFydCBvZiB0aGUgcHJvdG9jb2wgc2hvdWxkIGluZGljYXRlIHRoYXQgcGF0aCwg YW5kIGEgZGlmZmVyZW50IHBhcnQgb2YgdGhlIHByb3RvY29sIHNob3VsZCBpbmRpY2F0ZSB0aGUg dHJlYXRtZW50IG9yIHBvbGljeSBzZXQgdG8gYmUgdXNlZC4NCkVhcmxpZXIgaXQgd2FzIHN1Z2dl c3RlZCB0aGF0IHRoZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIHNob3VsZCBiZSBpbiBhIGZpeGVk LXNpemUgaGVhZGVyLg0KDQpTbywgaW4gdGhlIGxpbWl0LCB0aGVyZSBjb3VsZCBiZSBhIHNpbmds ZSAoYmktZGlyZWN0aW9uYWwpIGZvcndhcmRpbmcgcGF0aCBvdmVyIHdoaWNoIG1pbGxpb25zIG9m IGRpZmZlcmVudCBwb2xpY3kgdHJlYXRtZW50cyBhcmUgY29udmV5ZWQuDQpFLmcuLCBvbmUgZm9y d2FyZGluZyBwYXRoIGZvciBlYWNoIGRpcmVjdGlvbiAocmVhbGx5IHR3byBwYXRocyksIHdpdGgg c3Vic2NyaWJlciBpZGVudGlmaWVyIGluIHRoZSBtZXRhLWRhdGEuIA0KDQpCZW5lZml0czoNCi0g Zm9yd2FyZGluZyBlbGVtZW50cyBhcmUgYWdub3N0aWMgYWJvdXQgdGhlIG1ldGEtZGF0YSwga2Vl cGluZyB0aGUgZm9yd2FyZGluZyB0YWJsZXMgYXMgc21hbGwgYXMgcG9zc2libGUgYW5kIHVzaW5n IGZpeGVkLXNpemUgaGVhZGVycyBmb3Igb3B0aW1hbCBwZXJmb3JtYW5jZQ0KLSBTRnMgYXJlIGFn bm9zdGljIGFib3V0IHRoZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLCB1c2luZyBvbmx5IHRoZSBy ZWxldmFudCBtZXRhLWRhdGEuDQotIHRoZSBtZXRhLWRhdGEgaXMgbm90IHJlcXVpcmVkIGluIGV2 ZXJ5IHBhY2tldC4gRS5nLiwgaXQgY291bGQgYmUgc2VudCB3aXRoIHRoZSBmaXJzdCBwYWNrZXQg b2YgYSBsYXllcjQgY29ubmVjdGlvbiwgb3IgcGVyaGFwcyBvdXQgb2YgYmFuZC4NCg0KDQoNCi1E YXZlDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMjYsIDIwMTQgMTA6MjEgQU0NClRvOiBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKQ0KQ2M6IENocmlzIEZyZWRlcmljazsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTsgU2h1bnN1a2UgSG9tbWE7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJ LUQgQWN0aW9uOiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCg0KSSBh Z3JlZSB3aXRoIEppbS4NCg0KV2UgaGF2ZSBhbHNvIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJl IGF0IGxlYXN0IDIgYXBwcm9hY2hlcyB0byBkaWZmZXJlbnRpYXRlZCBwb2xpY3kgKip3aXRoaW4q KiBhIHNlcnZpY2UgZnVuY3Rpb24uICAgVGhlIGZpcnN0IGlzIHRoYXQgdGhlIHNlcnZpY2UgZnVu Y3Rpb24gaXMgcmVzcG9uc2libGUgZm9yIGRldGVybWluaW5nIHdoaWNoIHBvbGljaWVzIHRvIGFw cGx5IGluIGEgbWFubmVyIHRoYXQgaXMgcHJpdmF0ZSB0byBpdCAocGVyaGFwcyB1c2luZyBSQURJ VVMsIG9yIExEQVAsIG9yIHNvbWUgb3RoZXIgZXh0ZXJuYWwgbG9va3VwIG1lY2hhbmlzbSkuICAg IFRoaXMgYXBwcm9hY2ggbWF5LCBpbiBzb21lIGNhc2VzLCBiZW5lZml0IGZyb20gYSBzdWJzY3Jp YmVyIGlkZW50aXR5IGJlaW5nIHBhc3NlZCBpbiB0aGUgaW5iYW5kIG1ldGFkYXRhLg0KDQpUaGUg c2Vjb25kLCB3aGljaCBpcyB3ZWxsIHN1aXRlZCB3aGVuIHRoZSBudW1iZXIgb2YgZGlzdGluY3Qg cG9saWN5IHNldHMgaXMgc21hbGwgKGUuZy4sIGNvbnRlbnQtZmlsdGVyLWFkdWx0LCBjb250ZW50 LWZpbHRlci1jaGlsZCksIGlzIHRvIG1vZGVsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGFzIGhhdmlu ZyBtdWx0aXBsZSBsb2dpY2FsIGluc3RhbmNlcyBvZiBpdHNlbGYsIGVhY2ggaW1wbHlpbmcgYSBk aXN0aW5jdCBwb2xpY3kgc2V0LiAgIEluIHRoaXMgYXBwcm9hY2gsIFNGQ3MgYXJlIGJ1aWx0IHN1 Y2ggdGhhdCBhbnkgZ2l2ZW4gY2hhaW4gd291bGQgaW5jbHVkZSBhdCBtb3N0IG9uZSBvZiB0aGUg bG9naWNhbCBpbnN0YW5jZXMuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2Nv LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjYsIDIwMTQgOTo0MiBBTQ0KVG86IFJv biBQYXJrZXINCkNjOiBTaHVuc3VrZSBIb21tYTsgQ2hyaXMgRnJlZGVyaWNrOyBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBUUjog SS1EIEFjdGlvbjogZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQoNClJp Z2h0IGFuZCB0aGUgcG9pbnQgYmVpbmcgd2hhdCB5b3Ugd2FudCB0byBkbyBpcyBzaGFyZSBTRkNz IGFjcm9zcyBzdWJzY3JpYmVycyBhbmQgaW1wbGVtZW50IHdpdGhpbiB0aGUgU0ZDIGFueSBkaWZm ZXJlbnRpYXRpb24gaW4gdGVybXMgb2YgcG9saWN5IGZvciBzdWJzY3JpYmVycyB0aGF0IGNvbnN1 bWUgdGhlIHNhbWUgc2V0IG9mIHNlcnZpY2VzLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4g T24gRmViIDI2LCAyMDE0LCBhdCA3OjMyIEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gRXZlbiBpZiBzdWJzY3JpYmVycyBjYW4g c2VsZiBjb25maWd1cmUgdGhlaXIgc2VydmljZXMgdmlhIGEgcG9ydGFsLCB0aGUgbnVtYmVyIG9m IGRpc3RpbmN0IGNvbWJpbmF0aW9ucyB0aGF0IGFyaXNlIHdpbGwgc3RpbGwgYmUgZmluaXRlLiAg VGhhdCBpcywgaW4gYSBwb3B1bGF0aW9uIG9mIDEwMDAwMDAwMCBzdWJzY3JpYmVycywgc3VyZWx5 IHNvbWUgd2lsbCBlbmQgdXAgd2l0aCBlcXVpdmFsZW50IHNlcnZpY2VzPw0KPiANCj4gICBSb24N Cj4gDQo+PiBPbiBGZWIgMjYsIDIwMTQsIGF0IDI6MjUgQU0sICJTaHVuc3VrZSBIb21tYSIgPGhv bW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPj4gDQo+PiBIaSBDaHJpcywgUm9u LA0KPj4gDQo+PiBUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuDQo+PiANCj4+IEkgdW5kZXJzdG9v ZCB0aGF0IHlvdSBzYWlkLg0KPj4gQW5kIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgbWV0aG9k IHVzaW5nIG1ldGFkYXRhIGlzIG9uZSBvZiB0aGUgbWV0aG9kcyBmb3IgcmVjb2duaXppbmcgc3Vi c2NyaWJlcnMuDQo+PiBCdXQgdGhpcyBwcm9ibGVtIGlzIGltcGxlbWVudGF0aW9uIG1hdHRlcnMs IHNvIGl0IGlzIG5vdCBhdCB0aGUgc3RhZ2UgZm9yIGRpc2N1c3Npb24geWV0LCBJIHRoaW5rLg0K Pj4gDQo+PiBXaGF0IEkgd2FudCB0byBzYXkgaXMgdGhhdCB0aGVyZSBhcmUgcmVxdWVzdHMgZm9y IGRpc3RpbmN0IHNlcnZpY2VzIHBlciBzdWJzY3JpYmVyLCBzbyB0aGF0IFNGQyBhcmNoaXRlY3R1 cmUgc2hvdWxkIGJlIHNjYWxhYmxlLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBTaHVuc3Vr ZQ0KPj4gDQo+PiANCj4+ICgyMDE0LzAyLzI1IDIzOjQ5KSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ PiBFeHBhbmRpbmcgb24gQ2hyaXMnIGNvbW1lbnRzLCBJIGRvbid0IHRoaW5rIHRoZSBwcmFjdGlj YWwgbGltaXRhdGlvbnMgYXJlIHdydCB0aGUgbnVtYmVyIG9mIGZ1bGx5LXF1YWxpZmllZCA1LXR1 cGxlcywgYnV0IHJhdGhlciB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IHRyZWF0bWVudCBzZXF1ZW5j ZXMgdGhhdCBhcmlzZSBmcm9tIHRob3NlIGZsb3dzLiAgIE9mIHRoZSAxMDAncyBvZiBtaWxsaW9u cyBvZiBmbG93cyB0aGF0IG1pZ2h0IGJlIHRyYWNrZWQgYnkgYSBoaWdoIGVuZCBjbGFzc2lmaWVy LCBwZXJoYXBzIHRoZSBudW1iZXIgb2YgdW5pcXVlIHNlcXVlbmNlcyB0aGF0IGFyaXNlIGFyZSBp biB0aGUgMTAwMCdzLiAgICBJZiBhcHBseWluZyBhIGZpeGVkLWxpbmUgb3IgbW9iaWxlIHNlcnZp Y2UgcHJvdmlkZXIgcGVyc3BlY3RpdmUsIHRoZSBudW1iZXIgb2YgY2hhaW5zIHdvdWxkIGJlIHBy b3BvcnRpb25hbCB0byB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IGVuZC10by1lbmQgc2VydmljZSBw bGFucyBvZmZlcmVkIGFuZCB0aGVuIG11bHRpcGxpZWQgYnkgdGhlIGZsb3ctYXdhcmUgc3Vic2V0 dGluZyB0aGF0IGNhbiBiZSBtYW5hZ2VkIGJ5IHRoZSBjbGFzc2lmaWVyIChpLmUuLCBzdWJzY3Jp YmVyIGlzIHN1YmplY3QgdG8gc2VydmljZSBmdW5jdGlvbiBBIHRoZW4gQiB0aGVuIEMgYnV0IEIg b25seSBuZWVkcyBUQ1AvODAgdHJhZmZpYywgQSBvbmx5IG5lZWRzIFVEUCB0cmFmZmljLCAuLi4p Lg0KPj4+IA0KPj4+ICAgUm9uDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiBDaHJpcyBGcmVkZXJpY2sgW21haWx0bzpjZnJlZGVyaWNrQHNhbmR2 aW5lLmNvbV0NCj4+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNSwgMjAxNCA5OjQ0IEFNDQo+ Pj4gVG86IFNodW5zdWtlIEhvbW1hOyBSb24gUGFya2VyDQo+Pj4gQ2M6IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBUUjog SS1EIEFjdGlvbjogDQo+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0 DQo+Pj4gDQo+Pj4gSGkgU2h1bnN1a2Utc2FuLA0KPj4+IEkgcmVjb2duaXplIHRoYXQgdWx0aW1h dGVseSwgdGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiBhbmQgbm90IHNvbWV0aGlu ZyB0byBiZSBtYW5kYXRlZCBhcyBhIGhhcmQgJ3J1bGUnLiBJIGp1c3Qgd2FudGVkIHRvIGhpZ2hs aWdodCB3aGF0IGlzIHBvc3NpYmxlICsgd2hhdCB3ZSBiZWxpZXZlIHRvIGJlIGJlc3QgcHJhY3Rp Y2VzIGluIHRoaXMgYXJlYSwgYmFzZWQgb24gb3VyIGV4cGVyaWVuY2UuDQo+Pj4gVGhhdCBzYWlk LCB5ZXMsIEkgYmVsaWV2ZSB0aGF0IGluIHByYWN0aWNhbCAocmVhbC13b3JsZCkgdGVybXMsIGl0 IG1ha2VzIHNlbnNlIHRvIGRlZW1waGFzaXplIHRoZSAnKHJlKWNsYXNzaWZpY2F0aW9uJyByb2xl IG9mIFNGcyBpbiBtb3N0IGNhc2VzLCBmb3IgcmVhc29ucyBJJ3ZlIHN0YXRlZCBwcmV2aW91c2x5 IChxdWVzdGlvbnMgb2YgbWV0YWRhdGEgc2hhcmluZyBiZXR3ZWVuIFNGcywgaXNzdWVzIHJlbGF0 ZWQgdG8gcmV0YWluaW5nIGludGVncml0eSBvZiBjaGFpbnMvYnJlYWtpbmcgZmxvd3MsIGV0Yy4p Lg0KPj4+IFRvIHlvdXIgY29tbWVudCBhYm91dCBzY2FsaW5nIHRoZSBTRkMgQ29udHJvbGxlciwg SSB3b3VsZCBqdXN0IHNheSB0aGF0IHRoZXJlIGFyZSBjb21tZXJjaWFsbHkgZGVwbG95ZWQgU0ZD IENvbnRyb2xsZXJzIHRvZGF5IHRoYXQgZG8gdGhpcywgaS5lLiBzaXQgaW5saW5lIGluIGNvbnN1 bWVyIG5ldHdvcmtzLCByZWNlaXZlL2luc3BlY3QgbWlsbGlvbnMgb2YgY29uY3VycmVudCBiaWRp cmVjdGlvbmFsIGZsb3dzLCArIG1ha2UgcmVhbC10aW1lIFNGQyBzdGVlcmluZyBhbmQgc2VxdWVu Y2luZyBkZWNpc2lvbnMgYmFzZWQgb24gZmxvdywgc3Vic2NyaWJlciwgc2Vzc2lvbiwgYW5kIG5l dHdvcmsgY29uZGl0aW9ucy4NCj4+PiBPYnZpb3VzbHksIGRpZmZlcmVuY2VzIGluIHZlbmRvciBj YXBhYmlsaXRpZXMsIGFzIHdlbGwgYXMgDQo+Pj4gYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgdml6 IGNvbnNvbGlkYXRpbmcgdnMuIGRpc3RyaWJ1dGluZyBkaWZmZXJlbnQgDQo+Pj4gU0ZDIGZ1bmN0 aW9ucyBsaWtlIGZsb3cgY2xhc3NpZmljYXRpb24sIFBEUC9TRkMgQ29udHJvbGxlciwgDQo+Pj4g c3RlZXJpbmcvbGIsIGV0YywgYWxsIHdpbGwgaGF2ZSBhbiBpbXBhY3QgaGVyZS4gQmVzdCwgL2MN Cj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IFNodW5zdWtl IEhvbW1hIFttYWlsdG86aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcF0NCj4+PiBTZW50OiBU dWVzZGF5LCBGZWJydWFyeSAyNSwgMjAxNCA3OjI1IEFNDQo+Pj4gVG86IENocmlzIEZyZWRlcmlj azsgUm9uIFBhcmtlcg0KPj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNA aWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW3NmY10gVFI6IEktRCBBY3Rpb246IA0KPj4+IGRy YWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTAzLnR4dA0KPj4+IA0KPj4+IEhpIENocmlz LA0KPj4+IA0KPj4+IERvIHlvdSBtZWFuIHRoYXQsIGZvciByZXRhaW5pbmcgaW50ZWdyaXR5IG9m IGNoYWlucywgbWFuYWdlbWVudCBvZiBzdWJzY3JpYmVycyBzaG91bGQgYmUgcHJvdmlkZWQgbm90 IGJ5IFNGcywgYnV0IGJ5IFNGQyBjb250cm9sbGVyPw0KPj4+IA0KPj4+IElmIHNvLCB0aGUgcHJv YmxlbSBpcyB0aGF0IHRoZSBudW1iZXIgb2YgY2hhaW5zIHRoYXQgU0ZDIGNvbnRyb2xsZXIgbXVz dCBtYW5hZ2UgaXMgbGFyZ2UsIGFuZCBpdCBpcyB0aGUgc2FtZSBwcm9ibGVtIEkgc2FpZCwgSSB0 aGluay4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IA0KPj4+IFNodW5zdWtlDQo+Pj4gDQo+Pj4g KDIwMTQvMDIvMjUgMTQ6MTcpLCBDaHJpcyBGcmVkZXJpY2sgd3JvdGU6DQo+Pj4+IEhpIFNodW5z dWtlLXNhbiwNCj4+Pj4gSSBhY2tub3dsZWRnZSB0aGUgY29tbWVudHMgYWJvdXQgdGhlc2UgYmVp bmcgaW1wbGVtZW50YXRpb24gDQo+Pj4+IG1hdHRlcnMsIGJ1dCBJJ3ZlIG9mZmVyZWQgc29tZSB0 aG91Z2h0cyBpbmxpbmUgd2l0aCB5b3VyIG1haWwgDQo+Pj4+IGJlbG93LiBUaHgsIC9jDQo+Pj4+ IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBTaHVuc3VrZSBI b21tYSBbbWFpbHRvOmhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanBdDQo+Pj4+IFNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMjQsIDIwMTQgOTowMCBQTQ0KPj4+PiBUbzogQ2hyaXMgRnJlZGVyaWNr OyBSb24gUGFya2VyDQo+Pj4+IENjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNA aWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+PiBk cmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4gDQo+Pj4+IEhpIFJv biwgQ2hyaXMsDQo+Pj4+IA0KPj4+PiBUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuDQo+Pj4+IA0K Pj4+PiBJIHRoaW5rIHRoYXQgeW91ciBwb2ludHMgYXJlIGZvbGxvd2luZzoNCj4+Pj4gaW4gY2Fz ZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBhcyB1c2VyIGN1c3RvbWl6ZWQsIHBlci1zdWJzY3Jp YmVyIFNGQ3Mgc2hvdWxkbid0IGJlIG1hZGUsIGJ1dCB0aGUgU0ZzIHNob3VsZCByZWNvZ25pemUg c3Vic2NyaWJlcnMgYnkgSVAgYWRkcmVzcyBvciBtZXRhZGF0YS4NCj4+Pj4gQ0Y+PiBNeSBwb2lu dCB3YXMgdGhhdCBJIGRvbid0IHNlZSBpdCBhcyBkZXNpcmFibGUgdG8gaGF2ZSBzcGVjaWZpYyBw ZXItc3Vic2NyaWJlciBTRkMgcnVsZXMgKGFzIGluIHN0YXRpYyBydWxlcywgbGlrZSBzdWJzY3Jp YmVyX0NocmlzPVNGQ19hX2JfYyksIHdpdGggYSBydWxlIGZvciBldmVyeSBzdWIsIGluIHRoYXQg c2Vuc2UuIEJldHRlciBpcyBhIHNjZW5hcmlvIHdoZXJlIHRoZSBTRkMgY2hhaW4gY29udHJvbGxl ciBpcyBzdWJzY3JpYmVyLWF3YXJlICsgYWJsZSB0byBldmFsdWF0ZSBtdWx0aXBsZSBvcnRob2dv bmFsIGZsb3cgKyBzdWJzY3JpYmVyIGNvbmRpdGlvbnMgaW4gcmVhbCB0aW1lLCBhbmQgZm9ybXVs YXRlIGEgY2hhaW4gb24gdGhlIGJhc2lzIG9mIHRob3NlIGR5bmFtaWMgY29uZGl0aW9ucy4NCj4+ Pj4gDQo+Pj4+IE9mIGNvdXJzZSwgaXQgaXMgb25lIG9mIHRoZSBzb2x1dGlvbnMuDQo+Pj4+IEhv d2V2ZXIsIGluIHRoaXMgY2FzZSwgSSB0aGluayB0aGF0IFNGcyBhcyB1c2VyIGN1c3RvbWl6ZWQg bWlnaHQgYmUgcmVxdWlyZWQgdG8gaGF2ZSBhIGZ1bmN0aW9uIHRvIHJlY29nbml6ZSBlYWNoIHN1 YnNjcmliZXIuDQo+Pj4+IENGPj4gSSB3YXNuJ3QgYWN0dWFsbHkgdGhpbmtpbmcgaW4gdGVybXMg b2YgU0YgKHJlKWNsYXNzaWZpY2F0aW9uOyBJJ3ZlIHByZXZpb3VzbHkgY29tbWVudGVkIG9uIHdo eSBJIHRoaW5rIHRoYXQgaWRlYSBpcyBzb21ld2hhdCBmcmF1Z2h0IChpLmUuIGJlY2F1c2UgbW9k aWZpY2F0aW9uIG9mIHRoZSBmbG93IHBhdGggYnkgYSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGhpbiB0 aGUgY2hhaW4gY291bGQgcmVzdWx0IGluIGEgJ2JyZWFraW5nJyBvZiB0aGUgY2hhaW4gb3IgZmxv dy4gSWYgdGhlcmUgaXMgbm90IGJpZGlyZWN0aW9uYWwgc3ltbWV0cnkgaW4gdGhlIGZsb3cgYW5k IHNlcnZpY2UgZnVuY3Rpb24gZWxlbWVudHMgaW4gdGhlIGNoYWluIGNhbiBtYWtlIHJvdXRpbmcg ZGVjaXNpb25zLCB0aGVuIHRoZXJlJ3Mgc29tZSBtZXRhZGF0YSBjb3JyZWxhdGlvbiB0byB3b3Jr IG91dCwgYXQgbWluaW11bSkuIEkgZG8gYWdyZWUgdGhhdCB0aGUgU0ZDIGNoYWluIGNvbnRyb2xs ZXIgd291bGQgbmVlZCB0byBiZSBzdWJzY3JpYmVyLWF3YXJlIHRob3VnaC4NCj4+Pj4gDQo+Pj4+ IE9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHRoYXQgdGhlcmUgYXJlIGNhc2VzIHdoZW4gdGhl IGZ1bmN0aW9uIGNhbid0IGJlIGFkb3B0ZWQsIHN1Y2ggbGlrZSBTRnMgYXJlIGN1cnJlbnQgZXF1 aXBtZW50IHRoYXQgZG9uJ3QgaGF2ZSBmdW5jdGlvbiB0byByZWNvZ25pemUgbWV0YWRhdGEuDQo+ Pj4+IENGPj4gQWdyZWVkLiBUaGlzIHNwZWFrcyB0byBteSBjb21tZW50IGFib3ZlICsgdG8gdGhl IGFkdmFudGFnZXMgc29tZSBvZiB1cyBoYXZlIG1lbnRpb25lZCB2aXogYSBjb25zb2xpZGF0ZWQg cG9saWN5LWJhc2VkIHN0ZWVyaW5nL1BEUC9TRkMgY2hhaW4gY29udHJvbGxlciBlbnRpdHkuDQo+ Pj4+IA0KPj4+PiBIb3cgZG8gd2UgaGFuZGxlIHRoZXNlIGNhc2VzPw0KPj4+PiBBbnkgbmV3IHBy b2JsZW1zIG9yIHJlcXVpcmVtZW50cyBtYXkgb2NjdXI/DQo+Pj4+IA0KPj4+PiByZWdhcmRzLA0K Pj4+PiANCj4+Pj4gU2h1bnN1a2UNCj4+Pj4gDQo+Pj4+ICgyMDE0LzAyLzI1IDg6NDYpLCBDaHJp cyBGcmVkZXJpY2sgd3JvdGU6DQo+Pj4+PiBZZXMsIGFncmVlZCBvbiB0aGF0Lg0KPj4+Pj4gDQo+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogUm9uIFBhcmtlciBb bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+Pj4+PiBTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDI0LCAyMDE0IDY6NDUgUE0NCj4+Pj4+IFRvOiBDaHJpcyBGcmVkZXJpY2s7 IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNm Y0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+ Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+ IFRoYW5rcywgQ2hyaXMuDQo+Pj4+PiANCj4+Pj4+IEkgZG8gdGhpbmsgdGhlcmUgYXJlIGxvdHMg b2YgZWZmaWNpZW5jaWVzIHdoZW4gdGhlIGZsb3cgbGVhcm5lciAoY2xhc3NpZmllcikgYW5kIHBv bGljeSBldmFsdWF0b3IgKFBEUCkgYXJlIGNvLWxvY2F0ZWQuICAgSG93ZXZlciwgYXJjaGl0ZWN0 dXJhbGx5LCBJIHdvdWxkbid0IG1hbmRhdGUgdGhhdCB0aGV5IGJlIGNvLWxvY2F0ZWQuDQo+Pj4+ PiANCj4+Pj4+ICAgICAgUm9uDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IENocmlzIEZyZWRlcmljayBbbWFpbHRvOmNmcmVkZXJp Y2tAc2FuZHZpbmUuY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAxNCA1 OjI2IFBNDQo+Pj4+PiBUbzogUm9uIFBhcmtlcjsg5pys6ZaT5L+K5LuLDQo+Pj4+PiBDYzogbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBS RTogW3NmY10gVFI6IEktRCBBY3Rpb246DQo+Pj4+PiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVp cmVtZW50cy0wMy50eHQNCj4+Pj4+IA0KPj4+Pj4gQWdyZWVkLg0KPj4+Pj4gVG8gcmVzdGF0ZSB0 aGlzIHNsaWdodGx5LCBpZiB0aGUgU0ZDIHN0ZWVyaW5nL2RlY2lzaW9uIGxvY3VzIGlzIGNhcGFi bGUgb2YgZXZhbHVhdGluZyBtdWx0aXBsZSBvcnRob2dvbmFsIHBvbGljeSBjb25kaXRpb25zIHRo ZW4gdGhpcyBpc3N1ZSBpcyBvYnZpYXRlZDsgc3Vic2NyaWJlcnMgYmVjb21lIGFuIGFnZ3JlZ2F0 ZSBvZiAnd2hhdCB0aGV5IGFyZScgKyBhcmUgbm90IHNpbXBseSAnd2hvIHRoZXkgYXJlJy4NCj4+ Pj4+IEFzIFJvbiBzdGF0ZXMsIHRoaXMgYXdhcmVuZXNzIG1heSBiZSBkZXJpdmVkIGZyb20gTERB UCBsb29rdXAsIFJBRElVUywgR3gsIHByZS1wcm92aXNpb25lZCBydWxlcywgZXRjLg0KPj4+Pj4g VG8gaWxsdXN0cmF0ZSB3LyBhbiBleGFtcGxlLCB3ZSBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2Ug dGhpczoNCj4+Pj4+IElmIHN1YnNjcmliZXIgWCBpcyB1c2luZyB5b3V0dWJlLCBhbmQgaXMgb24g YSBjb25nZXN0ZWQgY2VsbCwgYW5kIGlzIG9uIGFuIGlQaG9uZSwgYW5kIGlzIGluIHRoZSAiR29s ZCBUaWVyIiwgYW5kLCBhbmQsIGFuZCwgYW5kLCBldGMsIHRoZW4gdGhlIGNoYWluIGNvbnNpc3Rz IG9mIHNlcnZpY2UgZnVuY3Rpb25zIGEsIGIsIGFuZCBjLg0KPj4+Pj4gVGhlcmUncyBubyBuZWVk IHRvIGVudGVyIGEgc3RhdGljIFNGQyBydWxlL2NoYWluIGZvciBzdWJzY3JpYmVyIFggKG9yIGFu eSBzdWJzY3JpYmVyKS4gSW4gZmFjdCwgaXQncyBub3QgZGVzaXJhYmxlIGFueXdheSBiZWNhdXNl IGFsbCBvZiB0aGUgYWJvdmUgY29uZGl0aW9ucyBtYXkgZXZhbHVhdGUgdG8gVHJ1ZSwgc2F2ZSBv bmUgKCJpcyBvbiBhIGNvbmdlc3RlZCBjZWxsIiksIGFuZCB0aGUgcmVzdWx0YW50IGNoYWluIG1p Z2h0IGJlIGFsdGVyZWQgKHBlcmhhcHMgdG8gYnlwYXNzIGEgdmlkZW8gb3B0aW1pemF0aW9uIHNl cnZpY2UgZnVuY3Rpb24pLg0KPj4+Pj4gVGhpcyBhbHNvIGdvZXMgdG8gdGhlIGVhcmxpZXIgY29t bWVudHMgUm9uICsgSSBtYWRlIGFib3V0IA0KPj4+Pj4gY29uc29saWRhdGluZyB0aGUgZmxvdyBy ZWNvZ25pdGlvbiArIGRlY2lzaW9uLW1ha2luZyBlbnRpdHkgaW4gYSANCj4+Pj4+IHNpbmdsZSAo c3VpdGFibHkgcG9saWN5LWF3YXJlKSBub2RlIHRvIHJlZHVjZSB0aGUgY29tcGxleGl0eSArIHRv IA0KPj4+Pj4gc2NhbGUgcHJvcGVybHkuIFRoeCwgL2MNCj4+Pj4+IA0KPj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4gU2VudDogU3VuZGF5LCBGZWJy dWFyeSAyMywgMjAxNCAxMDozOSBQTQ0KPj4+Pj4gVG86IOacrOmWk+S/iuS7iw0KPj4+Pj4gQ2M6 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVj dDogUmU6IFtzZmNdIFRSOiBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQtYm91Y2FkYWlyLXNmYy1y ZXF1aXJlbWVudHMtMDMudHh0DQo+Pj4+PiANCj4+Pj4+IFNodW5zdWtlLXNhbiwNCj4+Pj4+IA0K Pj4+Pj4gV2hpbGUgYSB0aGVvcmV0aWNhbCBjYXNlIGNhbiBiZSBtYWRlIGZvciBvbmUgb3IgbW9y ZSBTRkNzIHBlciBzdWJzY3JpYmVyLCBmb3IgcmVhc29ucyB5b3Ugc3RhdGUsIGl0IGlzbid0IHBy YWN0aWNhbC4gIEJ1dCwgdGhlcmUgaXMgYW5vdGhlciB3YXkgdG8gdmlldyB0aGlzIGFzcGVjdCBv ZiB0aGUgcHJvYmxlbS4gIExldCdzIHRha2UgeW91ciBwZXItc3Vic2NyaWJlciBjdXN0b21pemVk IGZpcmV3YWxsIGFzIGEgaHlwb3RoZXRpY2FsIGV4YW1wbGUuICBJZiB0aGVyZSB3ZXJlIG9ubHkg b25lIGZpcmV3YWxsLCBpbnN0ZWFkLCBhbmQgaXQgd2FzIGNhcGFibGUgb2YgbG9jYWwgcG9saWN5 IGV2YWx1YXRpb24gYmFzZWQgb24gc3Vic2NyaWJlciwgdGhlIG51bWJlciBvZiBTRkNzIHdvdWxk IGJlIHZhc3RseSByZWR1Y2VkLiAgIE9uZSB3YXkgZm9yIHRoYXQgdG8gaGFwcGVuIHdvdWxkIGJl IHRvIHNpbXBseSB1c2UgdGhlIHNvdXJjZS9kZXN0aW5hdGlvbiBJUCBhZGRyZXNzIGZyb20gdGhl IHBhY2tldCBhbmQgc29tZSBvdXQgb2YgYmFuZCBsb29rdXAgbWVjaGFuaXNtIGxpa2UgTERBUCBv ciBSQURJVVMgYXQgdGhlIGZpcmV3YWxsLiAgICBBbm90aGVyIGFwcHJvYWNoIHRvIGRldGVybWlu ZSB3aG8gdGhlIHN1YnNjcmliZXIgaXMgd291bGQgYmUgZm9yIHRoZSBTRkMgY2xhc3NpZmllciB0 byBhZGQgYSBkaXN0aW5jdCBzdWJzY3JpYmVyIGlkIGFzIG1ldGFkYXRhIHRvIHRoZSBzZXJ2aWNl IGhlYWRlciAoZWcsIGFuIElNU0kpIGFuZCBzdGlsbCB1c2UgTERBUCwgZXRjLiBhdCB0aGUgZmly ZXdhbGwuDQo+Pj4+PiANCj4+Pj4+IElmIHRoZSBwcm9ibGVtIGlzIGNoYW5nZWQgc2xpZ2h0bHkg c28gdGhhdCB0aGUgZmlyZXdhbGwgcG9saWN5IGlzIHBlciBncm91cCBvZiBzdWJzY3JpYmVycywg d2hlcmUgdGhlcmUgYXJlIHBlcmhhcHMgMTBzIG9mIGdyb3VwcywgdGhlbiB5ZXQgYW5vdGhlciBh cHByb2FjaCBpcyB0byBtb2RlbCB0aGUgZmlyZXdhbGwgYXMgYSBkaXN0aW5jdCBsb2dpY2FsIGZp cmV3YWxsIHBlciBmaXJld2FsbCBwb2xpY3kgc2V0ICh0aGV5IGNvdWxkIGFsbCByZXNpZGUgaW4g dGhlIHNhbWUgbWFjaGluZSBvciBWTSkgYW5kIHRvIGNvb3JkaW5hdGUgdGhlIGNsYXNzaWZpZXIn cyBwb2xpY3kgYWNjb3JkaW5nbHkuDQo+Pj4+PiANCj4+Pj4+ICAgICBSb24NCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+Pj4gT24gRmViIDIzLCAyMDE0LCBhdCAxMDowNCBQTSwgIuacrOmWk+S/iuS7iyIg PGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+IEhp IE1lZCwNCj4+Pj4+PiANCj4+Pj4+PiBJbiB0ZXJtcyBvZiB5b3VyIGNvbW1lbnQsIEkgYXNzdW1l ZCBzb21lIHVzZSBjYXNlcyBhYm91dCBzY2FsYWJpbGl0eSBzbyB0aGF0IHdlIGNhbiBjb250aW51 ZSB0aGUgZGlzY3Vzc2lvbiBhYm91dCBzY2FsYWJpbGl0eSBjb25zaWRlcmF0aW9ucy4NCj4+Pj4+ PiAjSSB3b3JrIHdpdGggSy5OYWl0bywgY28tYXV0aG9yIG9mIHJlcXVpcmVtZW50IGRyYWZ0IGFu ZCB0aGluayBzY2FsYWJpbGl0eSBpcyBvbmUgb2YgaW1wb3J0YW50IHRoaW5ncyB0byBjb25zaWRl ci4NCj4+Pj4+PiANCj4+Pj4+PiBBc3N1bWluZyB0aGUgdXNlIGNhc2VzIGxpc3RlZCBmb2xsb3dp bmcsIHRoZSBtYW5hZ2VtZW50IG1lY2hhbmlzbSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlucyBt aWdodCByZXF1aXJlIGhpZ2ggc2NhbGFiaWxpdHkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gMS4gVGhlIGNh c2UgdGhhdCB0aGUgdHlwZXMgb2YgU0YgaW5jcmVhc2U6DQo+Pj4+Pj4gSSBhc3N1bWVkIHRoYXQg dGhlIHVuaXQgb2YgYXBwbHlpbmcgU0ZDIHRvIHRyYWZmaWMgaXMgZm9sbG93aW5nOw0KPj4+Pj4+ ICAgLSBncm91cGluZzogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBl YWNoIHNlcnZpY2UsDQo+Pj4+Pj4gICAgIGVudGVycHJpc2UgY3VzdG9tZXIgb3IgcmVnaW9uLA0K Pj4+Pj4+ICAgLSBwZXItc3Vic2NyaWJlcjogdHJhZmZpYyBpcyBhcHBsaWVkIHdpdGggc3BlY2lm aWMgU0ZDIGZvciBlYWNo44CADQo+Pj4+Pj4gICAgIHN1YnNjcmliZXIgKGUuZy4gcGVyIElQIGFk ZHJlc3MsIFZMQU4gSUQgZXQuYWwpLA0KPj4+Pj4+ICAgLSBwZXItZmxvdzogdHJhZmZpYyBpcyBh cHBsaWVkIHdpdGggc3BlY2lmaWMgU0ZDIGZvciBlYWNoIHN1YnNjcmliZXIsDQo+Pj4+Pj4g44CA 44CAYW5kIG9iamVjdGl2ZSAoZS5nLiBwcmUgVVJMLCBhcHBsaWNhdGlvbiBldC5hbCkuDQo+Pj4+ Pj4gDQo+Pj4+Pj4gU29tZSBvZiB0aGUgc2VydmljZSBwcm92aWRlcnMgaGF2ZSBlbm9ybW91cyBu dW1iZXIgb2Ygc3Vic2NyaWJlcnMsIGFuZCB0aGUgbnVtYmVyIG9mIHN1YnNjcmliZXJzIGlzIHVw IHRvIHNldmVyYWwgdGVucyBvciBodW5kcmVkcyBvZiBtaWxsaW9uLiBUaGVyZWZvcmUsIGluIGNh c2VzIG9mIHBlci1zdWJzY3JpYmVyIGFuZCBwZXItZmxvdywgdGhlIG51bWJlciBvZiBTRkNzIG1p Z2h0IGluY3JlYXNlIGV4cGxvc2l2ZWx5LiBQZXItc3Vic2NyaWJlciBTRkNzIHdvdWxkIGJlIG5l ZWRlZCBpbiB0aGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBzb21lIFNGcyBkZWRpY2F0ZWQgdG8gZWFj aCB1c2VyKGUuZy4gdkNQRSBhcyB1c2VyIGN1c3RvbWl6ZWQpLg0KPj4+Pj4+IA0KPj4+Pj4+IEFs c28sIGluIGNhc2Ugb2YgZ3JvdXBpbmcsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBncm91cHMgd2hv c2UgcG9saWNpZXMgYXJlIGRpZmZlcmVudCwgc3VjaCBhcyBwZXIgZW50ZXJwcmlzZSBjdXN0b21l ciBhbmQgcGVyIHJlZ2lvbiwgdGhlIG51bWJlciBvZiBTRkNzIHdvdWxkIGluY3JlYXNlIChlLmcu IEZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBwb2xpY3kgZm9yIGVhY2ggZW50ZXJwcmlzZSBjdXN0 b21lcikuDQo+Pj4+Pj4gDQo+Pj4+Pj4gMi4gVGhlIGNhc2UgdGhhdCB0aGVyZSBhcmUgc29tZSBT RnMgdGhhdCBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5zdGFuY2U6DQo+Pj4+Pj4gSW4g Y2FzZSB0aGF0IHRoZXJlIGFyZSBTRnMgd2l0aCB0aGUgc2FtZSBmdW5jdGlvbiBpbiB0aGUgbmV0 d29yayBhbmQgdGhlIFNGcyBtdXN0IGJlIGNsYXNzaWZpZWQgZm9yIGVhY2ggaW5zdGFuY2UsIHRo ZSBjb21iaW5hdGlvbiBvZiBTRnMgbWlnaHQgaW5jcmVhc2UuDQo+Pj4+Pj4gVGhlIFNGcyB0aGF0 IHByb2Nlc3Mgc3RhdGVmdWwgdHJhZmZpYyBhcmUgbmVlZGVkIHRvIGJlIGRpZmZlcmVudGlhdGVk IHBlciBpbnN0YW5jZSAoZS5nLiBGaXJld2FsbCwgQ29udGVudHMtQ2FjaGUsIGFuZCBWaWRlby1P cHRpbWl6ZXIpLg0KPj4+Pj4+IA0KPj4+Pj4+IElNSE8scmVxdWlyZW1lbnRzIGZvciBzY2FsYWJp bGl0eSB3aWxsIGFmZmVjdCBTRkMgYXJjaGl0ZWN0dXJlIGFuZCBoZWFkZXIgZm9ybWF0Lg0KPj4+ Pj4+IA0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiANCj4+Pj4+PiBTaHVuc3VrZQ0KPj4+Pj4+IA0K Pj4+Pj4+ICgyMDE0LzAyLzEyIDE4OjQ5KSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3 cm90ZToNCj4+Pj4+Pj4gRGVhciBhbGwsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGlzIG5ldyB2ZXJz aW9uIGludGVncmF0ZXMgaW5wdXRzIGZyb20gTlRUIHJlcHJlc2VudGF0aXZlcy4NCj4+Pj4+Pj4g DQo+Pj4+Pj4+IFRoZSBkaWZmIGNhbiBiZSB0cmFja2VkIGhlcmU6DQo+Pj4+Pj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnQN Cj4+Pj4+Pj4gcy0wDQo+Pj4+Pj4+IDENCj4+Pj4+Pj4gJg0KPj4+Pj4+PiBkaWZmdHlwZT0tLWh0 bWwmc3VibWl0PUdvISZ1cmwyPWRyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzDQo+Pj4+ Pj4+IC0wMw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+PiBNZWQNCj4+Pj4+Pj4g DQo+Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+Pj4+PiBEZSA6IEktRC1B bm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSANCj4+ Pj4+Pj4gcGFydCBkZSBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1lcmNyZWRp IDEyIGbDqXZyaWVyDQo+Pj4+Pj4+IDIwMTQgMTA6NDYgw4ANCj4+Pj4+Pj4gOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQgQWN0aW9uOg0KPj4+Pj4+PiBkcmFmdC1ib3VjYWRhaXIt c2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gICAgICAgICAg VGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nDQo+Pj4+Pj4+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWly DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQN Cj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVhbmxvbmcgSmlhbmcNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uIFBhcmtlcg0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDYXJsb3MgUGlnbmF0YXJvDQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEtlbmdvIE5haXRvDQo+Pj4+Pj4+ICAgICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wMy50eHQNCj4+Pj4+Pj4gICAgIFBh Z2VzICAgICAgICAgICA6IDE0DQo+Pj4+Pj4+ICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAy LTEyDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+Pj4gICAgIFRoaXMgZG9jdW1l bnQgaWRlbnRpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgU2VydmljZSBGdW5jdGlvbg0K Pj4+Pj4+PiAgICAgQ2hhaW5pbmcgKFNGQykuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4g DQo+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOg0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3Vj YWRhaXItc2ZjLXJlcXVpcmVtZW50DQo+Pj4+Pj4+IHMvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDMN Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudA0KPj4+Pj4+PiBzLTANCj4+Pj4+Pj4gMw0KPj4+ Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIA0KPj4+Pj4+PiBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBs aXN0DQo+Pj4+Pj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+Pj4+PiBJbnRlcm5ldC1E cmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciANCj4+ Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+Pj4+Pj4g DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4gDQo+Pj4+ Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPj4+Pj4+IOacrOmWkyDkv4rku4sgKEhvbW1hIFNodW5zdWtlKQ0KPj4+Pj4+ IA0KPj4+Pj4+IOaXpeacrOmbu+S/oembu+ipseagquW8j+S8muekvg0KPj4+Pj4+IOODjeODg+OD iOODr+ODvOOCr+OCteODvOODk+OCueOCt+OCueODhuODoOeglOeptuaJgA0KPj4+Pj4+IOi7oumA geOCteODvOODk+OCueWfuuebpOODl+ODreOCuOOCp+OCr+ODiA0KPj4+Pj4+IOi7oumAgeOCteOD vOODk+OCueWItuW+oURQDQo+Pj4+Pj4gDQo+Pj4+Pj4g44CSMTgwLTg1ODXjgIDmnbHkuqzpg73m rabolLXph47luILnt5HnlLozLTktMTENCj4+Pj4+PiBURUw6IDA0MjItNTktMzQ4Ng0KPj4+Pj4+ IEUtTUFJTDogaG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcA0KPj4+Pj4+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBzZmMgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNA aWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0t DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gU2h1bnN1a2Ug SG9tbWENCj4+Pj4gPGhvbW1hLnNodW5zdWtlQGxhYi5udHQuY28uanA+DQo+Pj4+IFRFTDogKzgx IDA0MjIgNTkgMzQ4Ng0KPj4+PiBGQVg6ICs4MSAwNDIyIDYwIDc0NjANCj4+Pj4gDQo+Pj4+IE5U VCBOZXR3b3JrIFNlcnZpY2UgU3lzdGVtIExhYnMuDQo+Pj4+IE11c2FzaGlubyBjaXR5LCBUb2t5 bywgSmFwYW4NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzZmMg bWFpbGluZyBsaXN0DQo+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+IA0KPj4+IA0KPj4+IC0tDQo+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFNodW5zdWtlIEhvbW1hDQo+Pj4gPGhvbW1h LnNodW5zdWtlQGxhYi5udHQuY28uanA+DQo+Pj4gVEVMOiArODEgMDQyMiA1OSAzNDg2DQo+Pj4g RkFYOiArODEgMDQyMiA2MCA3NDYwDQo+Pj4gDQo+Pj4gTlRUIE5ldHdvcmsgU2VydmljZSBTeXN0 ZW0gTGFicy4NCj4+PiBNdXNhc2hpbm8gY2l0eSwgVG9reW8sIEphcGFuDQo+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAN Cj4+IA0KPj4gLS0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFNo dW5zdWtlIEhvbW1hDQo+PiA8aG9tbWEuc2h1bnN1a2VAbGFiLm50dC5jby5qcD4NCj4+IFRFTDog KzgxIDA0MjIgNTkgMzQ4Ng0KPj4gRkFYOiArODEgMDQyMiA2MCA3NDYwDQo+PiANCj4+IE5UVCBO ZXR3b3JrIFNlcnZpY2UgU3lzdGVtIExhYnMuDQo+PiBNdXNhc2hpbm8gY2l0eSwgVG9reW8sIEph cGFuDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QN Cj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2Zj IG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0K From nobody Wed Feb 26 08:52:08 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC47F1A0681 for ; Wed, 26 Feb 2014 08:52:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19hwvHfQBFxr for ; Wed, 26 Feb 2014 08:51:57 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id A87261A065A for ; Wed, 26 Feb 2014 08:51:55 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Wed, 26 Feb 2014 08:51:54 -0800 From: Ron Parker To: Dave Dolson Thread-Topic: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.txt Thread-Index: AQHPMQ0jkfmYOs/xB0KvSO1WB83EVJrDwdKygAHA4ID//4+EYIAAhyOAgAAlJICAADdIgIAAd4eAgAAmpID//3oy0IABnfKA///POEAAFVOxAAAPntoA//+WE4CAAIXEgP//gUgA//+EAGo= Date: Wed, 26 Feb 2014 16:51:53 +0000 Message-ID: <03B48B99-8BAF-4699-8F7D-634D854FF5A8@affirmednetworks.com> References: <20140212094549.31390.39152.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F4BFE3CC3@PUEXCB1B.nanterre.francetelecom.fr>, <530AB6ED.5000006@lab.ntt.co.jp> <682D5BD6-63F7-4697-BE6F-7F15876649A6@affirmednetworks.com> <802F0FD88084CC4D82A0663874219D1A18898EBF@wtl-exchp-2.sandvine.com> <802F0FD88084CC4D82A0663874219D1A18898FD6@wtl-exchp-2.sandvine.com> <530BF90B.7040508@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A18899122@wtl-exchp-2.sandvine.com> <530C8BAF.3040208@lab.ntt.co.jp> <802F0FD88084CC4D82A0663874219D1A188992C8@wtl-exchp-2.sandvine.com> , <530D9719.2090304@lab.ntt.co.jp>, <1F79037F-7F1C-4D25-9029-BA57EC377594@affirmednetworks.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TGpYasxjULREOn1sF7KRVThz0T0 Cc: Chris Frederick , "Jim Guichard \(jguichar\)" , "mohamed.boucadair@orange.com" , Shunsuke Homma , "sfc@ietf.org" Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-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: Wed, 26 Feb 2014 16:52:05 -0000 Absolutely, the service header has 2 aspects -- conveyance of information u= sed for steering (ie chain id) and conveyance of other helpful information = (ie metadata).=20 Ron > On Feb 26, 2014, at 11:15 AM, "Dave Dolson" wrote: >=20 > That in-band method of sending data is interesting. >=20 > My main point was the orthogonality of per-packet forwarding tags and the= meta-data to convey policy treatment. I did not mean to imply one meta-dat= a parameter is appropriate for all elements. >=20 > Since your idea does not put the meta-data in each packet, I suspect we a= re in agreement on the separation of forwarding information from policy key= s. >=20 >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 > Sent: Wednesday, February 26, 2014 11:03 AM > To: Dave Dolson; Jim Guichard (jguichar) > Cc: Chris Frederick; mohamed.boucadair@orange.com; Shunsuke Homma; sfc@ie= tf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.tx= t >=20 > Dave, >=20 > I find the conveyance of a policy key from the classifier to the service = functions very attractive. =20 >=20 > However, I don't think a global key that is interpreted equally by all se= rvice functions is practical. Some service functions may have only a very= small quantity of policy sets while others may be very granular. With = a global key, when additional policy sets are added to some service functio= n, all service functions would need to know how to translate those new glob= al keys into something locally significant. =20 >=20 > An alternative, pushing a stack of per-service-function policy keys onto = the packet so that each service function can see its own locally significan= t policy key, has its issues, too, since it is theoretically unbounded and = adds overhead to every packet. >=20 > A possible workaround to the stack of policy keys is to signal this in a = control plane from the classifier to the service functions. But, signalin= g at the micro-flow level is very impractical in terms of scale and adds si= gnificant complexity to avoid the first packet race condition that could ar= ise. In my opinion, the control plane should operate at the chain setup a= nd maintenance level and not at the microflow level. >=20 > Lastly, an approach that I think could work for bidirectional flows (the = vast majority of practical use cases, IMO) is to have an inband mechanism t= o deliver long lived metadata. The stack of policy keys could be deliver= ed inband in the first N packets of the flow. The reverse flow would pig= gyback inband acknowledgements from the service functions that the long ter= m metadata has been received. At that point, the classifier would no lon= ger add the long lived metadata to the flow. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com]=20 > Sent: Wednesday, February 26, 2014 10:50 AM > To: Ron Parker; Jim Guichard (jguichar) > Cc: Chris Frederick; mohamed.boucadair@orange.com; Shunsuke Homma; sfc@ie= tf.org > Subject: RE: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.tx= t >=20 > Also, earlier we discussed the benefits of orthogonal treatment of forwar= ding information vs. meta-data. > I.e., some part of the protocol should indicate that path, and a differen= t part of the protocol should indicate the treatment or policy set to be us= ed. > Earlier it was suggested that the forwarding information should be in a f= ixed-size header. >=20 > So, in the limit, there could be a single (bi-directional) forwarding pat= h over which millions of different policy treatments are conveyed. > E.g., one forwarding path for each direction (really two paths), with sub= scriber identifier in the meta-data.=20 >=20 > Benefits: > - forwarding elements are agnostic about the meta-data, keeping the forwa= rding tables as small as possible and using fixed-size headers for optimal = performance > - SFs are agnostic about the forwarding information, using only the relev= ant meta-data. > - the meta-data is not required in every packet. E.g., it could be sent w= ith the first packet of a layer4 connection, or perhaps out of band. >=20 >=20 >=20 > -Dave >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Wednesday, February 26, 2014 10:21 AM > To: Jim Guichard (jguichar) > Cc: Chris Frederick; mohamed.boucadair@orange.com; Shunsuke Homma; sfc@ie= tf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.tx= t >=20 > I agree with Jim. >=20 > We have also pointed out that there are at least 2 approaches to differen= tiated policy **within** a service function. The first is that the servic= e function is responsible for determining which policies to apply in a mann= er that is private to it (perhaps using RADIUS, or LDAP, or some other exte= rnal lookup mechanism). This approach may, in some cases, benefit from a= subscriber identity being passed in the inband metadata. >=20 > The second, which is well suited when the number of distinct policy sets = is small (e.g., content-filter-adult, content-filter-child), is to model th= e service function as having multiple logical instances of itself, each imp= lying a distinct policy set. In this approach, SFCs are built such that a= ny given chain would include at most one of the logical instances. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, February 26, 2014 9:42 AM > To: Ron Parker > Cc: Shunsuke Homma; Chris Frederick; mohamed.boucadair@orange.com; sfc@ie= tf.org > Subject: Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-03.tx= t >=20 > Right and the point being what you want to do is share SFCs across subscr= ibers and implement within the SFC any differentiation in terms of policy f= or subscribers that consume the same set of services. >=20 > Sent from my iPhone >=20 >> On Feb 26, 2014, at 7:32 AM, "Ron Parker" wrote: >>=20 >> Even if subscribers can self configure their services via a portal, the = number of distinct combinations that arise will still be finite. That is, = in a population of 100000000 subscribers, surely some will end up with equi= valent services? >>=20 >> Ron >>=20 >>> On Feb 26, 2014, at 2:25 AM, "Shunsuke Homma" wrote: >>>=20 >>> Hi Chris, Ron, >>>=20 >>> Thank you for your reply. >>>=20 >>> I understood that you said. >>> And I agree with you that the method using metadata is one of the metho= ds for recognizing subscribers. >>> But this problem is implementation matters, so it is not at the stage f= or discussion yet, I think. >>>=20 >>> What I want to say is that there are requests for distinct services per= subscriber, so that SFC architecture should be scalable. >>>=20 >>> Regards, >>>=20 >>> Shunsuke >>>=20 >>>=20 >>> (2014/02/25 23:49), Ron Parker wrote: >>>> Expanding on Chris' comments, I don't think the practical limitations = are wrt the number of fully-qualified 5-tuples, but rather the number of di= stinct treatment sequences that arise from those flows. Of the 100's of m= illions of flows that might be tracked by a high end classifier, perhaps th= e number of unique sequences that arise are in the 1000's. If applying a= fixed-line or mobile service provider perspective, the number of chains wo= uld be proportional to the number of distinct end-to-end service plans offe= red and then multiplied by the flow-aware subsetting that can be managed by= the classifier (i.e., subscriber is subject to service function A then B t= hen C but B only needs TCP/80 traffic, A only needs UDP traffic, ...). >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Chris Frederick [mailto:cfrederick@sandvine.com] >>>> Sent: Tuesday, February 25, 2014 9:44 AM >>>> To: Shunsuke Homma; Ron Parker >>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: RE: [sfc] TR: I-D Action:=20 >>>> draft-boucadair-sfc-requirements-03.txt >>>>=20 >>>> Hi Shunsuke-san, >>>> I recognize that ultimately, this is an implementation decision and no= t something to be mandated as a hard 'rule'. I just wanted to highlight wha= t is possible + what we believe to be best practices in this area, based on= our experience. >>>> That said, yes, I believe that in practical (real-world) terms, it mak= es sense to deemphasize the '(re)classification' role of SFs in most cases,= for reasons I've stated previously (questions of metadata sharing between = SFs, issues related to retaining integrity of chains/breaking flows, etc.). >>>> To your comment about scaling the SFC Controller, I would just say tha= t there are commercially deployed SFC Controllers today that do this, i.e. = sit inline in consumer networks, receive/inspect millions of concurrent bid= irectional flows, + make real-time SFC steering and sequencing decisions ba= sed on flow, subscriber, session, and network conditions. >>>> Obviously, differences in vendor capabilities, as well as=20 >>>> architectural decisions viz consolidating vs. distributing different=20 >>>> SFC functions like flow classification, PDP/SFC Controller,=20 >>>> steering/lb, etc, all will have an impact here. Best, /c >>>>=20 >>>> -----Original Message----- >>>> From: Shunsuke Homma [mailto:homma.shunsuke@lab.ntt.co.jp] >>>> Sent: Tuesday, February 25, 2014 7:25 AM >>>> To: Chris Frederick; Ron Parker >>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: Re: [sfc] TR: I-D Action:=20 >>>> draft-boucadair-sfc-requirements-03.txt >>>>=20 >>>> Hi Chris, >>>>=20 >>>> Do you mean that, for retaining integrity of chains, management of sub= scribers should be provided not by SFs, but by SFC controller? >>>>=20 >>>> If so, the problem is that the number of chains that SFC controller mu= st manage is large, and it is the same problem I said, I think. >>>>=20 >>>> Regards, >>>>=20 >>>> Shunsuke >>>>=20 >>>> (2014/02/25 14:17), Chris Frederick wrote: >>>>> Hi Shunsuke-san, >>>>> I acknowledge the comments about these being implementation=20 >>>>> matters, but I've offered some thoughts inline with your mail=20 >>>>> below. Thx, /c >>>>>=20 >>>>> -----Original Message----- >>>>> From: Shunsuke Homma [mailto:homma.shunsuke@lab.ntt.co.jp] >>>>> Sent: Monday, February 24, 2014 9:00 PM >>>>> To: Chris Frederick; Ron Parker >>>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>>> Subject: Re: [sfc] TR: I-D Action: >>>>> draft-boucadair-sfc-requirements-03.txt >>>>>=20 >>>>> Hi Ron, Chris, >>>>>=20 >>>>> Thank you for your reply. >>>>>=20 >>>>> I think that your points are following: >>>>> in case that there are some SFs as user customized, per-subscriber SF= Cs shouldn't be made, but the SFs should recognize subscribers by IP addres= s or metadata. >>>>> CF>> My point was that I don't see it as desirable to have specific p= er-subscriber SFC rules (as in static rules, like subscriber_Chris=3DSFC_a_= b_c), with a rule for every sub, in that sense. Better is a scenario where = the SFC chain controller is subscriber-aware + able to evaluate multiple or= thogonal flow + subscriber conditions in real time, and formulate a chain o= n the basis of those dynamic conditions. >>>>>=20 >>>>> Of course, it is one of the solutions. >>>>> However, in this case, I think that SFs as user customized might be r= equired to have a function to recognize each subscriber. >>>>> CF>> I wasn't actually thinking in terms of SF (re)classification; I'= ve previously commented on why I think that idea is somewhat fraught (i.e. = because modification of the flow path by a service function within the chai= n could result in a 'breaking' of the chain or flow. If there is not bidire= ctional symmetry in the flow and service function elements in the chain can= make routing decisions, then there's some metadata correlation to work out= , at minimum). I do agree that the SFC chain controller would need to be su= bscriber-aware though. >>>>>=20 >>>>> On the other hand, I think that there are cases when the function can= 't be adopted, such like SFs are current equipment that don't have function= to recognize metadata. >>>>> CF>> Agreed. This speaks to my comment above + to the advantages some= of us have mentioned viz a consolidated policy-based steering/PDP/SFC chai= n controller entity. >>>>>=20 >>>>> How do we handle these cases? >>>>> Any new problems or requirements may occur? >>>>>=20 >>>>> regards, >>>>>=20 >>>>> Shunsuke >>>>>=20 >>>>> (2014/02/25 8:46), Chris Frederick wrote: >>>>>> Yes, agreed on that. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Monday, February 24, 2014 6:45 PM >>>>>> To: Chris Frederick; =1B$BK\4V=3DS2p=1B(B >>>>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: RE: [sfc] TR: I-D Action: >>>>>> draft-boucadair-sfc-requirements-03.txt >>>>>>=20 >>>>>> Thanks, Chris. >>>>>>=20 >>>>>> I do think there are lots of efficiencies when the flow learner (cla= ssifier) and policy evaluator (PDP) are co-located. However, architectura= lly, I wouldn't mandate that they be co-located. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Chris Frederick [mailto:cfrederick@sandvine.com] >>>>>> Sent: Monday, February 24, 2014 5:26 PM >>>>>> To: Ron Parker; =1B$BK\4V=3DS2p=1B(B >>>>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: RE: [sfc] TR: I-D Action: >>>>>> draft-boucadair-sfc-requirements-03.txt >>>>>>=20 >>>>>> Agreed. >>>>>> To restate this slightly, if the SFC steering/decision locus is capa= ble of evaluating multiple orthogonal policy conditions then this issue is = obviated; subscribers become an aggregate of 'what they are' + are not simp= ly 'who they are'. >>>>>> As Ron states, this awareness may be derived from LDAP lookup, RADIU= S, Gx, pre-provisioned rules, etc. >>>>>> To illustrate w/ an example, we might say something like this: >>>>>> If subscriber X is using youtube, and is on a congested cell, and is= on an iPhone, and is in the "Gold Tier", and, and, and, and, etc, then the= chain consists of service functions a, b, and c. >>>>>> There's no need to enter a static SFC rule/chain for subscriber X (o= r any subscriber). In fact, it's not desirable anyway because all of the ab= ove conditions may evaluate to True, save one ("is on a congested cell"), a= nd the resultant chain might be altered (perhaps to bypass a video optimiza= tion service function). >>>>>> This also goes to the earlier comments Ron + I made about=20 >>>>>> consolidating the flow recognition + decision-making entity in a=20 >>>>>> single (suitably policy-aware) node to reduce the complexity + to=20 >>>>>> scale properly. Thx, /c >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>>>>> Sent: Sunday, February 23, 2014 10:39 PM >>>>>> To: =1B$BK\4V=3DS2p=1B(B >>>>>> Cc: mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] TR: I-D Action: >>>>>> draft-boucadair-sfc-requirements-03.txt >>>>>>=20 >>>>>> Shunsuke-san, >>>>>>=20 >>>>>> While a theoretical case can be made for one or more SFCs per subscr= iber, for reasons you state, it isn't practical. But, there is another way= to view this aspect of the problem. Let's take your per-subscriber custom= ized firewall as a hypothetical example. If there were only one firewall, = instead, and it was capable of local policy evaluation based on subscriber,= the number of SFCs would be vastly reduced. One way for that to happen w= ould be to simply use the source/destination IP address from the packet and= some out of band lookup mechanism like LDAP or RADIUS at the firewall. = Another approach to determine who the subscriber is would be for the SFC cl= assifier to add a distinct subscriber id as metadata to the service header = (eg, an IMSI) and still use LDAP, etc. at the firewall. >>>>>>=20 >>>>>> If the problem is changed slightly so that the firewall policy is pe= r group of subscribers, where there are perhaps 10s of groups, then yet ano= ther approach is to model the firewall as a distinct logical firewall per f= irewall policy set (they could all reside in the same machine or VM) and to= coordinate the classifier's policy accordingly. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>>> On Feb 23, 2014, at 10:04 PM, "=1B$BK\4V=3DS2p=1B(B" wrote: >>>>>>>=20 >>>>>>> Hi Med, >>>>>>>=20 >>>>>>> In terms of your comment, I assumed some use cases about scalabilit= y so that we can continue the discussion about scalability considerations. >>>>>>> #I work with K.Naito, co-author of requirement draft and think scal= ability is one of important things to consider. >>>>>>>=20 >>>>>>> Assuming the use cases listed following, the management mechanism o= f Service Function Chains might require high scalability. >>>>>>>=20 >>>>>>> 1. The case that the types of SF increase: >>>>>>> I assumed that the unit of applying SFC to traffic is following; >>>>>>> - grouping: traffic is applied with specific SFC for each service, >>>>>>> enterprise customer or region, >>>>>>> - per-subscriber: traffic is applied with specific SFC for each=1B= $B!!=1B(B >>>>>>> subscriber (e.g. per IP address, VLAN ID et.al), >>>>>>> - per-flow: traffic is applied with specific SFC for each subscrib= er, >>>>>>> =1B$B!!!!=1B(Band objective (e.g. pre URL, application et.al). >>>>>>>=20 >>>>>>> Some of the service providers have enormous number of subscribers, = and the number of subscribers is up to several tens or hundreds of million.= Therefore, in cases of per-subscriber and per-flow, the number of SFCs mig= ht increase explosively. Per-subscriber SFCs would be needed in the case th= at there are some SFs dedicated to each user(e.g. vCPE as user customized). >>>>>>>=20 >>>>>>> Also, in case of grouping, if there are multiple groups whose polic= ies are different, such as per enterprise customer and per region, the numb= er of SFCs would increase (e.g. Firewalls have different policy for each en= terprise customer). >>>>>>>=20 >>>>>>> 2. The case that there are some SFs that must be classified for eac= h instance: >>>>>>> In case that there are SFs with the same function in the network an= d the SFs must be classified for each instance, the combination of SFs migh= t increase. >>>>>>> The SFs that process stateful traffic are needed to be differentiat= ed per instance (e.g. Firewall, Contents-Cache, and Video-Optimizer). >>>>>>>=20 >>>>>>> IMHO,requirements for scalability will affect SFC architecture and = header format. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Shunsuke >>>>>>>=20 >>>>>>> (2014/02/12 18:49), mohamed.boucadair@orange.com wrote: >>>>>>>> Dear all, >>>>>>>>=20 >>>>>>>> This new version integrates inputs from NTT representatives. >>>>>>>>=20 >>>>>>>> The diff can be tracked here: >>>>>>>> http://www.ietf.org/rfcdiff?url1=3Ddraft-boucadair-sfc-requirement >>>>>>>> s-0 >>>>>>>> 1 >>>>>>>> & >>>>>>>> difftype=3D--html&submit=3DGo!&url2=3Ddraft-boucadair-sfc-requirem= ents >>>>>>>> -03 >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la=20 >>>>>>>> part de internet-drafts@ietf.org Envoye : mercredi 12 fevrier >>>>>>>> 2014 10:46 A >>>>>>>> : i-d-announce@ietf.org Objet : I-D Action: >>>>>>>> draft-boucadair-sfc-requirements-03.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts= directories. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : Requirements for Service Function Chaini= ng >>>>>>>> Authors : Mohamed Boucadair >>>>>>>> Christian Jacquenet >>>>>>>> Yuanlong Jiang >>>>>>>> Ron Parker >>>>>>>> Carlos Pignataro >>>>>>>> Kengo Naito >>>>>>>> Filename : draft-boucadair-sfc-requirements-03.txt >>>>>>>> Pages : 14 >>>>>>>> Date : 2014-02-12 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This document identifies the requirements for the Service Funct= ion >>>>>>>> Chaining (SFC). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirement >>>>>>>> s/ >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirement >>>>>>>> s-0 >>>>>>>> 3 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please note that it may take a couple of minutes from the time=20 >>>>>>>> of submission until the htmlized version and diff are available at= tools.ietf.org. >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> I-D-Announce mailing list >>>>>>>> I-D-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> ******************************************** >>>>>>> =1B$BK\4V=1B(B =1B$B=3DS2p=1B(B (Homma Shunsuke) >>>>>>>=20 >>>>>>> =1B$BF|K\EE?.EEOC3t<02q>>>>>> =1B$B%M%C%H%o!<%/%5!<%S%9%7%9%F%`8&5f=3Dj=1B(B >>>>>>> =1B$BE>Aw%5!<%S%94pHW%W%m%8%'%/%H=1B(B >>>>>>> =1B$BE>Aw%5!<%S%9@)8f=1B(BDP >>>>>>>=20 >>>>>>> =1B$B")=1B(B180-8585=1B$B!!El5~ETIpB"Ln;TNPD.=1B(B3-9-11 >>>>>>> TEL: 0422-59-3486 >>>>>>> E-MAIL: homma.shunsuke@lab.ntt.co.jp >>>>>>> ******************************************** >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>=20 >>>>>=20 >>>>> -- >>>>> ---------------------------------- >>>>> Shunsuke Homma >>>>> >>>>> TEL: +81 0422 59 3486 >>>>> FAX: +81 0422 60 7460 >>>>>=20 >>>>> NTT Network Service System Labs. >>>>> Musashino city, Tokyo, Japan >>>>> ---------------------------------- >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>>=20 >>>> -- >>>> ---------------------------------- >>>> Shunsuke Homma >>>> >>>> TEL: +81 0422 59 3486 >>>> FAX: +81 0422 60 7460 >>>>=20 >>>> NTT Network Service System Labs. >>>> Musashino city, Tokyo, Japan >>>> ---------------------------------- >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>>=20 >>> -- >>> ---------------------------------- >>> Shunsuke Homma >>> >>> TEL: +81 0422 59 3486 >>> FAX: +81 0422 60 7460 >>>=20 >>> NTT Network Service System Labs. >>> Musashino city, Tokyo, Japan >>> ---------------------------------- >> _______________________________________________ >> 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